commit | 5822c1c8ddc69bf54ee659603c4d7754eb609b4c | [log] [tgz] |
---|---|---|
author | Adam Oleksy <adam.oleksy@gmail.com> | Sun May 18 07:01:09 2025 +0200 |
committer | GitHub <noreply@github.com> | Sat May 17 22:01:09 2025 -0700 |
tree | 43efebbee618623140d38c2f1380a29fe24fae59 | |
parent | 609c72ca1a7526f444a109bc04f861ad578e833d [diff] |
Fix dereference operator of VectorIterator to structures (#8425) For Vector or Array of structures the dereference operator of an iterator returns the pointer to the structure. However, IndirectHelper, which is used in the implementation of this operator, is instantiated in the way that the IndirectHelper::Read returns structure by value. This is because, Vector and Array instantiate IndirectHelper with const T*, but VectorIterator instantiates IndirectHelper with T. There are three IndirectHelper template definition: first for T, second for Offset<T> and the last one for const T*. Those have different IndirectHelper:Read implementations and (more importantly) return type. This is the reason of mismatch in VectorIterator::operator* between return type declaration and what was exactly returned. That is, for Array<T,...> where T is scalar the VectorIterator is instantiated as VectorIterator<T, T>, dereference operator returns T and its implementation uses IndirectHelper<T> which Read function returns T. When T is not scalar, then VectorIterator is instantiated as VectorIterator<T, const T *>, dereference operator returns const T * and its implementation uses IndirectHelper<T> which Read function returns T. The fix is done as follows: * implement type trait is_specialization_of_Offset and is_specialization_of_Offset64, * change partial specialization of IndirectHelper with const T * that it is instantiated by T and enabled only if T is not scalar and not specialization of Offset or Offset64, * remove type differentiation (due to scalar) from Array.. The above makes the IndirectHelper able to correctly instantiate itself basing only on T. Thus, the instantiation in VectorIterator correctly instantiate IndirectHelper::Read function, especially the return type.
FlatBuffers is a cross platform serialization library architected for maximum memory efficiency. It allows you to directly access serialized data without parsing/unpacking it first, while still having great forwards/backwards compatibility.
Build the compiler for flatbuffers (flatc
)
Use cmake
to create the build files for your platform and then perform the compilation (Linux example).
cmake -G "Unix Makefiles" make -j
Define your flatbuffer schema (.fbs
)
Write the schema to define the data you want to serialize. See monster.fbs for an example.
Generate code for your language(s)
Use the flatc
compiler to take your schema and generate language-specific code:
./flatc --cpp --rust monster.fbs
Which generates monster_generated.h
and monster_generated.rs
files.
Serialize data
Use the generated code, as well as the FlatBufferBuilder
to construct your serialized buffer. (C++
example)
Transmit/store/save Buffer
Use your serialized buffer however you want. Send it to someone, save it for later, etc...
Read the data
Use the generated accessors to read the data from the serialized buffer.
It doesn't need to be the same language/schema version, FlatBuffers ensures the data is readable across languages and schema versions. See the Rust
example reading the data written by C++
.
Go to our landing page to browse our documentation.
Code generation and runtime libraries for many popular languages.
FlatBuffers does not follow traditional SemVer versioning (see rationale) but rather uses a format of the date of the release.
flatbuffers
tag for any questions regarding FlatBuffers.To contribute to this project, see CONTRIBUTING.
Please see our Security Policy for reporting vulnerabilities.
Flatbuffers is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.