5822c1c8dd
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. |
||
|---|---|---|
| .bazelci | ||
| .github | ||
| android | ||
| bazel | ||
| benchmarks | ||
| CMake | ||
| conan | ||
| dart | ||
| docs | ||
| examples/go-echo | ||
| go | ||
| goldens | ||
| grpc | ||
| include | ||
| java | ||
| js | ||
| kotlin | ||
| lobster | ||
| lua | ||
| mjs | ||
| net/FlatBuffers | ||
| nim | ||
| php | ||
| python | ||
| reflection | ||
| rust | ||
| samples | ||
| scripts | ||
| snap | ||
| src | ||
| swift | ||
| tests | ||
| ts | ||
| .bazelignore | ||
| .bazelrc | ||
| .clang-format | ||
| .clang-tidy | ||
| .editorconfig | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| BUILD.bazel | ||
| build_defs.bzl | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| composer.json | ||
| conanfile.py | ||
| CONTRIBUTING.md | ||
| extensions.bzl | ||
| FlatBuffers.podspec | ||
| Formatters.md | ||
| LICENSE | ||
| MODULE.bazel | ||
| package.json | ||
| Package.swift | ||
| pnpm-lock.yaml | ||
| README.md | ||
| SECURITY.md | ||
| swift.swiftformat | ||
| tsconfig.json | ||
| tsconfig.mjs.json | ||
| typescript.bzl | ||
FlatBuffers
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.
Quick Start
-
Build the compiler for flatbuffers (
flatc)Use
cmaketo 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
flatccompiler to take your schema and generate language-specific code:./flatc --cpp --rust monster.fbsWhich generates
monster_generated.handmonster_generated.rsfiles. -
Serialize data
Use the generated code, as well as the
FlatBufferBuilderto 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
Rustexample reading the data written byC++.
Documentation
Go to our landing page to browse our documentation.
Supported operating systems
- Windows
- macOS
- Linux
- Android
- And any others with a recent C++ compiler (C++ 11 and newer)
Supported programming languages
Code generation and runtime libraries for many popular languages.
- C
- C++ - snapcraft.io
- C# - nuget.org
- Dart - pub.dev
- Go - go.dev
- Java - Maven
- JavaScript - NPM
- Kotlin
- Lobster
- Lua
- PHP
- Python - PyPI
- Rust - crates.io
- Swift - swiftpackageindex
- TypeScript - NPM
- Nim
Versioning
FlatBuffers does not follow traditional SemVer versioning (see rationale) but rather uses a format of the date of the release.
Contribution
- FlatBuffers Issues Tracker to submit an issue.
- stackoverflow.com with
flatbufferstag for any questions regarding FlatBuffers.
To contribute to this project, see CONTRIBUTING.
Community
Security
Please see our Security Policy for reporting vulnerabilities.
Licensing
Flatbuffers is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.