FlatSharp: Using FlatSharp in Unity throw compilation error.

This is published now. Thanks for all of your help and suggestions! I’m going to close out this issue, but feel free to reach out if you need anything else!

Thanks for the offer; that’s very kind! I’m honestly just really happy that people find the project useful.

I have one final preview before I’m ready to release version 5.1 on Nuget, if you wouldn’t mind trying it: https://ci.appveyor.com/project/jamescourtney/flatsharp/builds/38279284/artifacts

Thanks again!

New preview building here: https://ci.appveyor.com/project/jamescourtney/flatsharp/builds/38266904/artifacts. Let me know how it works for you.

But why the aggressive mode is the default but not lazy? I think lazy deserialization is the core concept of FlatBuffer.

Lazy is a key concept! However, that’s different than pretty much every other .NET serializer, which does things greedily. The point of confusion people may have with lazy is this:

byte[] buffer = ByteArrayPool.Take();
await File.Read("foo.txt", buffer);
T item = someSerializer.Parse(buffer); // item implicitly references buffer, but this is not obvious to the programmer
ByteArrayPool.Return(buffer);

So, in this case, the item would become invalid as soon as that buffer was reused to read a different file. This wouldn’t be obvious at all to the programmer and would likely take awhile to track down, which is why I chose to make Greedy the default; it might not be the best performing option, but it does behave in a way that people are accustomed to.

Is it possible to parse the data to the existing without returning a new instance?

Not with FlatSharp, sorry. The reason for this is that when you deserialize a T, you get back a subclass of T that has properties overridden. This is what I was talking about above when I said I didn’t like ParseFrom. If you have thoughts about how to work around this, please let me know.

Is it possible to make the writer to allocate memory if needed? so we don’t need to pass a larger buffer into it.

Ideally, you pool your buffers so that you only occasionally need to expand them and allocate something new, right? It’s also not required to call GetMaxSize. You can instead just try to serialize. If it runs out of space, FlatSharp will throw a BufferTooSmallException that tells you what size it thinks it needs. Expanding buffers isn’t something FlatSharp can do, because it just sees a Span<byte> that it is writing into, which is not a resizable type.

What you describe already exists.

FlatSharp is greedy by default. Greedy is the simplest mode. If you want Flatsharp to be lazy, all you have to do is tell it.

https://github.com/jamescourtney/FlatSharp/wiki/Deserialization-Modes https://github.com/jamescourtney/FlatSharp/wiki/FBS-Annotations-(FlatSharp-5.X)#fs_serializer

Preview build available here: https://ci.appveyor.com/project/jamescourtney/flatsharp/builds/38223116/artifacts

You shouldn’t use FlatBufferSerializer from a Unity project. FlatBufferSerializer works by creating and compiling code at runtime using Roslyn. The point of the FlatSharp.Compiler project is to do all of this work at build time.

The main page indicates which projects you should reference. Don’t use the FlatSharp package if you are targeting Unity. All you need is FlatSharp.Compiler and FlatSharp.Runtime.

Using a serializer from an FBS files works like this:

table MyTable (fs_serializer) { Int:int; }

Then, from your project, you do:

MyTable table = MyTable { Int = 3 };
byte[] buffer = new byte[1024];
MyTable.Serializer.Write(buffer, table);

The samples folder in this project contains lots of resources that can help you. This one in particular should be useful.

You are so great! The World will be better because of you! Let us feedback to you after trying that!