Higher level API for creating flat buffers about flatbuffers HOT 3 CLOSED

You'll have to give a more concrete example of how what you're trying to serialize does not fit with the schema structure, and what kind of code we could generate to fix that.

I would think that most tree-shaped FlatBuffers are constructed from internal data that is similarly tree-shaped, so a pre-order traversal of it would allow it to be serialized without any additional bookkeeping.

Do note that the FlatBuffers API has been designed for maximum efficiency first. The goals is to construct buffers with zero additional copying and allocation. It's not hard to make a friendlier API, for example, Protocol Buffers API gives you more flexibility in the order of serialization. But it also constructs an entire tree of objects.

from flatbuffers.

Ideally, you could specify the root object and flatbuffers would do the rest.

But to be more concrete...
Table A has String B. So we need to create B, store its offset, start A and add the string offset to A. This is always the same pattern and it should be easy to automate this step.

Storing vectors of tables are worse, because you need to maintain a list of offsets before you can add it the vector to another table. So, we need to allocate a list of offsets somewhere anyway.

from flatbuffers.

On Mon, Aug 25, 2014 at 2:21 PM, greenrobot [email protected]
wrote:

Ideally, you could specify the root object and flatbuffers would do the
rest.

How would this work? Would FlatBuffers generate object definitions for you?
Or would it magically map any supplied objects to the schema?

But to be more concrete...
Table A has String B. So we need to create B, store its offset, start A
and add the string offset to A. This is always the same pattern and it
should be easy to automate this step.

In the case of a table with strings and scalars, I could generate a
CreateA() function that takes all those elements, and hides the
CreateString step. This is definitely on the todo list.

But in the general case, i.e. a table A that owns a B that owns a C this is
not possible, unless you put B and C in temporary objects (incurring
allocation and copying).

Storing vectors of tables are worse, because you need to maintain a list
of offsets before you can add it the vector to another table. So, we need
to allocate a list of offsets somewhere anyway.

This is indeed clumsy. But there's no cheap way to pass all that object
data to a function in such a way that we can abstract the vector
construction in its entirety. What there should be though, is functions
that take an array, so that at least you don't have to write your own loop.

from flatbuffers.