flatbuffers::FlatBufferBuilder builder(1024);
// Create Person.
WritePerson0(builder);
// Create Group.
WritePerson(builder);
// Getting ready to the write buffer to a file.
uint8_t *buf = builder.GetBufferPointer();
int size = builder.GetSize();
// Writing to a file.
std::ofstream writer("fb_bytes.bin", std::ios::binary);
writer.write((char*)buf, size);
writer.close();
Now I am writing 2
Persons like this
When I am trying to access this, how should I access the second entry
I am doing this, but you can see that this is not possible for every case
with open("fb_bytes.bin", "rb") as f:
buf = f.read()
foo = Client.Person.Person.GetRootAs(buf)
print(foo.Name().decode('utf-8'), end = ", ")
print(str(foo.Age()), end = ", ")
print(str(foo.Weight()))
buf = buf[48:]
foo0 = Client.Person.Person.GetRootAs(buf1)
print(foo0.Name().decode('utf-8'), end = ", ")
print(str(foo0.Age()), end = ", ")
print(str(foo0.Weight()))
I checked the size using
len() by writing only one Person and thus sliced the buf
But I want to automate this fot n number of
Persons
@aardappel am I doing something wrong while writing to file? The file is being written as I want I just have an issue while reading it, how can I know the size of the message which is being written.
if you have serialized other objects which are not reachable from that root, you can't access them.. you'd have to invent a new root type that includes them both somehow
also, if you run such code, you should get asserts indicating the problem.. if you're not getting asserts, make sure you have them on during development (debug mode)
like I said above, use a vector of objects
Both functions look like this, just different values
auto pName = builder.CreateString("BiasdasdgFoot");
auto pAge = 91;
auto pWeight = 123.5;
auto Person = CreatePerson(builder, pName, pAge, pWeight, Gender_Male);
// builder.FinishSizePrefixed(Person);
builder.Finish(Person);
Whole file: https://pastebin.com/sF9QJ3uZ
But then how can we create multiple
Can't I just keep creating
Person without using vector?Can't I just keep creating
Person and keep appending to the file?
Maybe I am not able to explain my use case properly.
What I understood is, we can only use
In my code I am not getting any errors because
Finish once.In my code I am not getting any errors because
asserts are off.
please read what I typed above again
and turn asserts on
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=DEBUG
Building like this will turn on asserts?
Now I am clearing the buffer using
builder.Clear() and reusing it.
Although I need to explore more to understand things better, I am off to a good start. I might even try contributing to the project.
guys, i need to use flatbuffer with grpc , when i use flatc --grpc --cpp ./greeter.fbs in /grpc/samples/greeters, only 3 files added, greeter_generated.grpc.fb.cc greeter_generated.grpc.fb.h greeter_generated.h, and file greeter.grpc.fb.h not found which is used in server.cpp . any one can help ?
for now you may have to rename them manually to make it build, or fix the code/Makefile
I like the FlatBuffers IDL and want to use it with a custom wire format. I figured, using the intermediate representation is a good start. Is there a way to use some code generation infrastructure from
flatc for this use case, maybe by writing a plugin for it?
@kai:nasnotfound.de you're in luck,
flatc is able to write out a binary version of a parsed schema.. using FlatBuffers itself! This data is perfect for writing external code generators. You can easily read this data in any language that FlatBuffers already supports. The option is --bfbs I believe, and the schema for the data is in reflection/ .. see also some github issues where we talk more about using this for external code generators @dbaileychess
@bodie I'm the author of flatcc, the C implementation of FlatBuffers. This tool generates code for schema specific JSON parsers, and are rather fast compared to most JSON parser, and faster than flatc's JSON parser that dynamically looks up in the schema, but does not require code generation and compilation. I have not made a direct comparison to simdjson, and I am not sure if I recall correctly, but if it is based on technology covered in the blog by Daniel Lemire, then this is legit very fast. There are some tradeoffs where a schema can make things faster than a normal JSON parser, but also some SIMD techniques that are not feasible in a parser like flatcc JSON where it must build a valid buffer and do certain validation checks. There are some benchmark numbers based on a now rather old 2014 core i7 macbook pro 2.2Ghz machine on the flatcc site. Also, I'm not sure how simd parsing works with things now running more on more on ARM, although it should be possible to also do interesting stuff on that platform.