Question about C++ and C runtime code compatibility.

[lucasjinreal]

Hello, wanna ask, can I copy the runtime file to my project, replace roiginal flatfbuffer dep in my C++ project?

my schema is generated with flatbuffer in c++.

I want my runtime to be small enought with flatbuffer.

[mikkelfj]

Hi, uhnfortunately that is not possible. You will have to generate new C interfacing code and write new application logic. However, your data and the high level logic of your application should be able to easily adapt. So all FlatBuffer binary data files will remain compatible.

The FlatCC project probably has more runtime code files before compilation because it has a lot of code to support many different platforms (the portable library), but it should compile down to a reasonably small size. My guess is that the C++ project is also reasonably small after compilation.

Memory usage is a different matter. FlatCC provides a lot of control over that, but it is also a lot of work if you do not use the standard solution.

[lucasjinreal]

@mikkelfj thank u for the explornation. What should I do, If I want flatbuffer dep smallest? (c++ code sometimes a little bit larger than c compiled lib size)

[mikkelfj]

There is no simple answer to that. I don't know the size of C++ vs. C but I don't think the difference is very large - except the way the builder allocates memory. I suggest you create a very small project in both C and C++ and compare the results with different compiler settings. Also, create a project that only reads flatbuffers and one that also builds flatbuffers since you might not need a builder in all your code. You can use https://github.com/dvidelabs/flatcc/tree/master/samples/monster as a starting point. It is used in the official tutorial, but keep in mind that it has been updated in C++ with new features since the flatcc version was created. (Note that the similar monster_test.fbs project in the test folder is much larger and much less comparable than monster.fbs).

Both C and C++ relies heavily on inline functions. In C it is hidden behind a lot of generated macros, but the effect is the same. All these disappear into only what is necessary, both for C and C++. However, if use -O3 optimization, it may use more space than -O2 or less agressive optimization. Then there is the runtime build library in C, which is found in builder.c. I am not sure if C++ has something similar, but is probably in the form of some static functions in C++header.

For C, the runtime library is only used for building buffers. It is not needed at all for reading buffers. Reading buffers only require inline functions, so if your application only has a few simple operations, the code would be small, or it could be large if you have many calls and do not disable function inlining.

[lucasjinreal]

@mikkelfj Hi, since they have tiny difference, then must have one be optimized. I will choose it.

Another concern is that currently I am using flatbuffer as 3rd lib and using cmake auto include it, this will include all unused code as well not just runtime..

what should to do if I want just these runtime deps?

[lucasjinreal]

in other words, can I just copy a single header file to support flatbuffer APIs just for runtime usage? My hardware are extremlly small and very limited storage size.

[mikkelfj]

In C++ I think a single header would be enough (at least it used to be). In C you will need a lot of header files in include/flatcc. flatcc also generates a header file per schema file and a few common header files. But most of them will disappear when compiled even if they look like a lot. So if you need space before compilation, C++ would probably be smaller, but after, you need to test.

[mikkelfj]

The projects in the samples folder compile to between 54 and 74 KB binary executable in release build with clang x64 compiler on MacOS. The only dependency is then the C runtime library.