FlatBuffers: Memory Efficient Serialization Library


logo FlatBuffers

Build Status Build status Join the chat at https://gitter.im/google/flatbuffers Discord Chat Twitter Follow

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.

Go to our landing page to browse our documentation.

Supported operating systems

  • Windows
  • MacOS X
  • Linux
  • Android
  • And any others with a recent C++ compiler.

Supported programming languages

  • C++
  • C#
  • C
  • Dart
  • Go
  • Java
  • JavaScript
  • Lobster
  • Lua
  • PHP
  • Python
  • Rust
  • TypeScript

and more in progress...


To contribute to this project, see CONTRIBUTING.


Flatbuffers is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

  • Feature RFC: Flatbuffers support for Optional types.

    Feature RFC: Flatbuffers support for Optional types.

    Note: This top comment is heavily edited. It was kept up with the current state until this issue closed.


    Flatbuffers should allow users to choose to use optional types. There has been some interest in distinguishing between default values (which are not stored in the binary) and some notion of None which the user controls.

    Here are some links to previous interest in this idea:

    • #333
    • #3777
    • https://groups.google.com/forum/#!topic/flatbuffers/1hrNtBI0BQI
    • https://github.com/google/flatbuffers/issues/5875#issuecomment-619737916

    Currently, a user can control a field's presence in the binary by specifying "force_defaults" and checking "IsFieldPresent" which is a bit of a hack. This proposal should define proper Flatbuffers optional types, which should be a better way of doing this. Use of this feature is only advisable for new fields, since changing default values is in general backwards-incompatible.

    How do we represent this in the schema file?

    We will specify it like so

    table Monster { mana: int = null; }

    This visually implies that optional types are at odds with default values and is "consistent" since the value to the right of the equals sign is what we interpret non-presence to mean.

    Change to Schema Grammar:

    field_decl = ident : type [ = (scalar | null) ] metadata ;

    ~We can add a field tag, e.g. "optional" or "no_default", that triggers this behavior. Hopefully no one is using those tags. Maybe we can make it specifiable to flatc, an "--optional-field-keyword-tag" flag, just in case people are using it and can't stop.~

    How do we represent this in the binary?

    We are going with option (A).

    (A) Non-Presence means None

    Instead of omitting zero-like values, the generated code must store them. Non-presence for optional fields no longer means "whatever the default is," now it means None. You can interpret it as "the default value is None". This also means we cannot specify both specify a non-null default and mark the field as optional.


    • This seems more intuitive.
    • It aligns with the "force_defaults" + "IsFieldPresent" hacky manual approximation of this feature.
    • If Nones are more common than zero-likes then this will have smaller binaries.


    • @aardappel thinks this is harder to implement

      "making presence an indicator would require we pass this special field status down to the field construction code to override the current val == default check, which means slowdown, codegen and runtime changes in all languages.. whereas my "least likely to be used default" trick requires no changes"

    ~(B) Some Sentinel value means None~

    In this scenario, zero-like values are still not stored. Instead we choose some "sentinel" value which we interpret to be None (e.g. int can use int_min and float can use some kind of Nan).


    • @aardappel thinks this is easier to implement

      "it requires the schema parser to set default values for you, and no changes anywhere else"

    • If zero-likes are more common than None then this will have smaller binaries


    • Someone might want to use the sentinel value (Hyrum's law).
      • This can be mitigated by publishing the sentinels and letting users decide whether they need the sentinels.
    • This probably won't work for fields representing raw bits.

    How do we represent this in every language API?

    We'll need to change the type signature of all generated code (building/reading/mutating/object/etc) around the optional type to signal its optional-ness. I think we should use the language's local standard for optional types. Suggestions:

    • Python: Optional[T].
    • Rust: Option<T>.
    • C++17 has std::optional<T> but its not obvious what to use for earlier versions. T* would work.
    • Java: Optional shows up in Java 1.8 and triggers autoboxing, so idk :/

    The exact generated-API for a language should be discussed in the PR implementing this feature in that language.

    Out of scope

    (I'll add links if you make issues for these feature requests)

    • Syntactic types
    • Default values for strings and tables


    | task | owner | done |---|---|---| | Change flatc to support schemas with optional types and cause an error if they're used in unsupported languages | @CasperN | #6026 ✅ | Implement optional type API in C++ | @vglavnyy | #6155 ✅ | Implement optional type API in Java | @paulovap | #6212 ✅ | Implement optional type API in Rust | @CasperN | #6034 ✅ | Implement optional type API in Swift | @mustiikhalil | #6038 ✅ | Implement optional type API in lobster | @aardappel | ✅ | Implement optional type API in Kotlin | @paulovap | #6115 ✅ | Implement optional type API in Python | @rw? | Implement optional type API in Go | @rw? | Implement optional type API in C | @mikkelfj | ✅ | Implement optional type API in C# | @dbaileychess | #6217 ✅ | Implement optional type API in Typescript/javacscript | @krojew | #6215 ✅ | Php, Dart, etc ... | ? | Update documentation to advertise this feature | @cneo | #6270 ✅


    • added todo list
    • added points from the discussion to each section.
    • added out of scope section
    • Decision: go with (A) and use = null syntax in schema file (cross out alternatives)
    • Updated TODO list, finished parser, Rust in progress
    • Change to schema grammar, link to swift PR, Note at top
    • Added more languages to the TODO
    • Lobster support 🦞
    • Kotlin and C support
    • Java, C#, TS/JS support and docs, issue closed, no longer editing.
    opened by CasperN 136
  • Fixed array length

    Fixed array length

    This change ports the pull request #3987 by daksenik and idoroshev to the most recent commit and adds support for generation of JSON schema, Java, C# and Python.

    opened by svenk177 101
  • Support for Rust programming language

    Support for Rust programming language

    This pull request include an implementation of the Flatbuffers runtime for the Rust programming language and Rust code generation via the flatc binary.

    Code is well documented and currently passes a full suite of tests. I do however still need to add a sample and do more benchmark testing. In the meantime I want to get this on the projects radar to discuss.


    opened by josephDunne 76
  • [Swift] Swift implementation 🎉🎉

    [Swift] Swift implementation 🎉🎉

    Good afternoon,

    @mzaks and I hope with this PR we would be able to add an official implementation for swift, it's heavily inspired by the C++ and C# implementations. There are some elements that are still missing such as the code generator and also documentation for the code base, however I found that we can implement those after getting an initial review for the swift code base, and if it lives up to the standards.

    The FlatBuffer class uses apples underlaying UnsafeMutableRawPointer which allows is to write directly to the memory, and lefts a lot of heavy weight from our shoulders, since this implementation comes which the following function storeBytes with takes a value and it's Bytes representation and just adds it to the buffer. UnsafeMutableRawPointer the name is a bit misleading since it's actually safe to use if everything writing the bytes is well structured. and since we don't really allow the user to get to the underlying adding and pushing to the buffer and only allowing them to do so through the builder it would be completely safe to use it.

    The FlatBuffersBuilder class uses the same underlying logic as C++ and C#, but unlike C# it relies on generics to actually add bytes and elements into the buffer. we took a different approach regarding adding the structs into the buffer, since swift uses the storeBytes to actually store the struct into the buffer, and since FlatBuffers do not allow string in Structs we took that into our advantage.

    struct Vec2: Writeable {
        var _x: Float32
        var _y: Float32
        var _z: Float32
        var _c: Color2
         init(x: Float32, y: Float32, z: Float32, color: Color2) { _c = color; _x = x; _y = y; _z = z }
         static func createVec2(_ bb: FlatBuffersBuilder, v: Vec2) -> Offset<UOffset> {
            return bb.create(struct: v)

    the following struct will be able to be directly inserted into the buffer, and we will be implementing a reader struct that will read the Writable struct as shown below. This will have the same concept as the builder Objects in c++. The readers were implemented to follow the C# way of fetching elements from the buffer.

    struct Vec2_Read: Readable {
        private var __p: Struct
        init(_ fb: FlatBuffer, o: Int32) { __p = Struct(bb: fb, position: o) }
        var c: Color2 { return Color2(rawValue: __p.readBuffer(of: Int32.self, at: 12)) ?? .red }
        var x: Float32 { return __p.readBuffer(of: Float32.self, at: 0)}
        var y: Float32 { return __p.readBuffer(of: Float32.self, at: 4)}
        var z: Float32 { return __p.readBuffer(of: Float32.self, at: 8)}

    All the test case are passing, and they were created by the flatc code generator for both C++ and C#, and the basic implementation of swift was verified against those two since the code generator isn't implemented yet.

    what's missing: 1- Code Generator 2- Documentation 3- Benchmarking

    when merging this PR we would be closing the following issues, Closes #5504. and I will be rebasing the commit before merging for sure

    opened by mustiikhalil 75
  • Tracking issue: Rust buffer verification

    Tracking issue: Rust buffer verification

    This is a tracking issue to document design and implementation of a verifier system for Rust Flatbuffers. I'm thinking that we can clone the logic from the C++ codebase.

    The benefit is twofold:

    1. Verifiers let users check if data is valid, thereby providing a security check for unknown data.
    2. If a buffer is verified, we can justify using more unsafe pointer access in Rust, thereby removing bounds checking.

    Anyone have thoughts on this? @aardappel

    enhancement rust 
    opened by rw 69
  • Non smart pointers --gen-object-api version

    Non smart pointers --gen-object-api version

    It is needed to allow the users to assign one struct to another.

    I also added implementation for operator= for unions, now you can do: union1 = union2; or union1 = supportedStruct;

    It is also needed for the upcoming (in the (near) future) Qt support.

    opened by bog-dan-ro 68
  • [TS/JS] New gen TS code gen

    [TS/JS] New gen TS code gen

    Modernize TS/JS code gen by doing a reworked TS only code gen.


    • [x] Split output into modules (files)
    • [x] Devise a sensible alias/prefix for flatbuffers imports to not collide with user symbols
    • [x] Track needed imports
    • [x] Alias imported symbols if same name from different namespaces
    • [x] Do not generate extra ;
    • [x] Fix wrong static method generation
    • [x] Drop flatbuffers namespace completely
    • [x] var to let or const
    • [x] Remove ns wrapping/prefixing
    • [x] Fix object API
    • [x] Remove obsolete generator options
    • [x] Fix and verify JavaScriptFlexBuffersTest.js
    • [x] Remove jsdoc type annotations


    • [ ] Decide what to do about Compiler.md, JavaScriptUsage.md, Tutorial.md and javascript_sample.sh

    TODO (undecided)

    • [ ] Resolve closer relative paths in imports
    • [ ] Avoid unused imports
    • [ ] Proper indentation
    • [ ] Const correctness
    • [ ] noImplicitAny compliant generated source
    c++ javascript typescript codegen documentation json CI 
    opened by bjornharrtell 66
  • FlatBuffers 2.0 tracking issue

    FlatBuffers 2.0 tracking issue

    This issue is to keep track of the FlatBuffers 2.0 release, which is intended to be "soon", but also "when its done".

    2.0 you ask? Wasn't the last one 1.12 ? Yes, because:

    • We're going to attempt to adhere as best we can to "Semantic Versioning" from now on. Past releases were simply 1.0 thru 1.12 with no regard for how many breaking changes were in a release. Generally, every release so far has been breaking for at least 1 language, but we have not expressed that. If we continue our habit of occasionally breaking APIs, the release after this one may thus have to be 3.0 instead of 2.1, but we'll see. Our version architect is @krojew
    • We actually do seem to have more breaking changes than usual, with especially Rust getting a big overhaul, but also Swift, Python and others. So 2.0 seems appropriate.

    What are we waiting for? We are waiting for some of these larger breaking changes to "settle down". This thread will link those issues, once all are merged we'll get the release going.

    Also worth mentioning: we are attempting to work towards a structure where FlatBuffers development is more "distributed", with clear individual maintainers for each language, that may at some point may make language package releases and such independently of the main FlatBuffers releases. But this will take time.

    opened by aardappel 60
  • [Python] (scalar) vector reading speedup via numpy

    [Python] (scalar) vector reading speedup via numpy

    Reading vectors with generated Python code is slow. There have been other efforts to speed this up but they appear to have stagnated.

    This PR attempts to make a minimal change that covers a use case I personally hit a lot (copying over large vectors that represent nested flatbuffers). There may be other small changes that could drastically speed up other use cases that are not included here since I am unaware of them :)

    What's the change?

    This PR adds support for accessing a scalar vector as a numpy array of the corresponding type. This is much faster than copying large vectors element-by-element.

    • Update the Table class in Python to have a GetVectorAsNumpy method which returns a zero-copy view (in numpy terminology) into a scalar vector cast as the correct type.
    • Update the python-code-generation code (idl_gen_python.cpp) to generate a method which wraps GetVectorAsNumpy in generated code. This method is named <field name>AsNumpy, which can be compared to the generated name of the method to get the length of a vector, <field name>Length. Attempting to use this method if numpy is not installed will result in an error, but otherwise numpy is optional.
    • Update appveyor CI to run Python tests.
    • Update python docs appropriately.

    See also

    • #4090 Byte data from flatbuffer vector into a Python NumPy array
      • This PR can probably close that issue?
    • #4144 Reading and Writing Binary blobs is incredibly slow with the default API!
      • This PR can probably close that issue?
    • #4152 Python: Add numpy array accessors for vectors [WIP]
      • The PR here and that PR seem to accomplish similar things, but I haven't read enough details to say whether or not the PR here completely supersedes that one.
    • #284 Python: Support Cython build
    • #304 Python: Speedup with cython extension (closed by author due to lack of time)
    opened by kbrose 53
  • Port FlatBuffers to Python.

    Port FlatBuffers to Python.

    Implement code generation and runtime library for Python 2 and 3, derived from the Go implementation. Additionally, the test suite verifies:

    the exact bytes in the Builder buffer during many scenarios, vtable deduplication, and table construction, via a fuzzer derived from the Go implementation.

    opened by rw 50
  • TypeScript support

    TypeScript support

    Thank you for submitting a PR!

    Please make sure you include the names of the affected language(s) in your PR title. This helps us get the correct maintainers to look at your issue.

    If you make changes to any of the code generators, be sure to run cd tests && sh generate_code.sh (or equivalent .bat) and include the generated code changes in the PR. This allows us to better see the effect of the PR.

    If your PR includes C++ code, please adhere to the Google C++ Style Guide, and don't forget we try to support older compilers (e.g. VS2010, GCC 4.6.3), so only some C++11 support is available.

    Include other details as appropriate.


    opened by krojew 48
  • [C++] Add BuildFlatBuffers.cmake to the distribution

    [C++] Add BuildFlatBuffers.cmake to the distribution

    Unable to compile .fbs files from CMake when using FlatBuffers via vcpkg, as necessary convenience functions are in BuildFlatBuffers.cmake, which isn't included to the port distribution.

    See related issue for vcpkg, where it was said it's an upstream issue

    opened by r4nx 0
  • [TS] Use TextEncoder and TextDecoder

    [TS] Use TextEncoder and TextDecoder

    TextEncoder and TextDecoder are well supported these days, see https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder#browser_compatibility and https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder#browser_compatibility.

    opened by bjornharrtell 0
  • Compilation issue msys2

    Compilation issue msys2


    In the build action:

    /d/a/Surelog/Surelog/third_party/flatbuffers/src/util.cpp:219:29: error: ‘realpath’ was not declared in this scope 114 219 | char *abs_path_temp = realpath(filepath.c_str(), nullptr); 115 |

    opened by alaindargelas 0
  • [TS] Upgrade TS/node deps and other improvements

    [TS] Upgrade TS/node deps and other improvements

    • Upgraded dependencies
    • Native module resolution (removal of esm dependency)
    • Improved TS typing

    WIP, should be rebased after https://github.com/google/flatbuffers/pull/7396 is merged.

    python c++ javascript typescript codegen json 
    opened by bjornharrtell 0
  • flatc --python --grpc: error when adding input or output path [python, grpc, flatbuffer v2.0.0, gRPC v1.35.0]

    flatc --python --grpc: error when adding input or output path [python, grpc, flatbuffer v2.0.0, gRPC v1.35.0]

    When I have the message .fbs files and the gRPC service .fbs files in one folder and call flatc in that folder with the following command everything works fine.

    flatc --python --grpc *.fbs

    But when I move the message .fbs files into another folder (~/messagefolder) and call flatc with the -I argument

    flatc --python --grpc -I ~/messagefolder *.fbs

    I get this error:

    flatc: error: Unable to generate GRPC interface forPython

    Additionally, if I just add an output folder like this:

    flatc --python --grpc -o ~/outputfolder *.fbs

    I get the same error.

    If I try all of the above flatc calls with --cpp instead of --python everything works fine.

    opened by mhoellmann 0
  • v2.0.0(May 10, 2021)

    A summary of what is in this release since 1.12.0:

    • Support for optional scalars in most languages.
    • Rust Verifier, Object API and FlexBuffers support, and many API improvements.
    • Overhaul of TypeScript support.
    • gRPC for many languages brought up to date.
    • C++ compile time field reflection.
    • JS FlexBuffers support.
    • Kotlin FlexBuffers and platform support.
    • Swift Object API and many Swift performance improvements.
    • Lua supports LuaJIT and many more fixes.
    • Python FlexBuffers support.
    • Many other fixes and smaller improvements, 371 commits since 1.12.0

    Note, "2.0" doesn't signify any kind of major overhaul of FlatBuffers, it is merely trying to be more semver compatible, and this release does have breaking changes for some languages much like all releases before it.

    Source code(tar.gz)
    Source code(zip)
    Linux.flatc.binary.clang++-9.zip(1.04 MB)
    Mac.flatc.binary.zip(968.25 KB)
    Windows.flatc.binary.zip(1006.77 KB)
  • v1.12.0(Mar 12, 2020)

    A summary of what is in this release since 1.11.0:

    • An official Swift port! (including gRPC support).
    • A Kotlin port!
    • Object API and native JSON support for C#.
    • Object API and gRPC support for Python.
    • Object API for Go.
    • FlexBuffers for Java.
    • Many other fixes and smaller improvements, 247 commits since 1.11.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows.zip(902.07 KB)
  • v1.11.0(Apr 24, 2019)

    A summary of what is in this release since 1.10.0:

    • More accurate C++ float handling, NaN handling, limit checking.
    • Java optimization: faster object accessors, faster UTF8 conversion.
    • A lot of Rust port improvements.
    • Vector of union JSON parsing.
    • Parser can now work from binary schemas.
    • Python: numpy vector support.
    • Packaging: Snap & RPM support.
    • Many improvements to our CI, added Bazel CI, dockerized language tests.
    • Many other fixes and smaller improvements, 169 commits since 1.10.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(596.76 KB)
  • v1.10.0(Oct 3, 2018)

    A summary of what is in this release since 1.9.0:

    • Rust support!
    • Dart support!
    • Lua support!
    • Lobster support!
    • C++: Improved / more correct verifier, compare operator in generated code, new/improved move operators for many data types, string_view support.
    • Java & C# support vectors of unions.
    • Many other fixes and smaller improvements, 145 commits since 1.9.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(539.51 KB)
  • v1.9.0(Apr 5, 2018)

    A summary of what is in this release since 1.8.0:

    • Further optimized C++ memory usage for FlatBufferBuilder: from 3 to 1 dynamic allocations (!)
    • GRPC support in Java & Maven.
    • Build files for Bazel and Conan.
    • Prefixed size support for Java/C#/Python.
    • Typescript docs.
    • Many other fixes and improvements, 80 commits since 1.8.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(421.96 KB)
  • v1.8.0(Nov 20, 2017)

    A summary of what is in this release since 1.7.0:

    • Vtable trimming in all language implementations: can reduce binary size 10-20%!
    • Mini-reflection tables (in C++) for debug-print, etc.
    • Improved .proto conversion.
    • Vectors of unions now also supported in JS/TS/PHP/C.
    • Improved namespace handling.
    • Boolean types in FlexBuffers.
    • Python Numpy vector support.
    • Nested FlatBuffer JSON parsing.
    • C++98 (stlport) support for core FlatBuffers and FlexBuffers.
    • JSON Schema output support.
    • Many other fixes and improvements, 90 commits since 1.7.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(391.39 KB)
  • v1.7.1(Jun 20, 2017)

    This is a bug fix release.

    • Calling CreateVector in C++ on a vector of Offset types with an explicit template parameter (of that Offset type) of could cause the wrong specialization to be selected in 1.7.0. This should affect very few people, but safer to use 1.7.1 just in-case. flatc from 1.7.0 is compatible with 1.7.1.
    Source code(tar.gz)
    Source code(zip)
  • v1.7.0(Jun 17, 2017)

    A summary of what is in this release since 1.6.0:

    • Typescript support!
    • Improved GRPC API with proper zero-copy path. BREAKS API
    • Fixed many issues with ReleaseBufferPointer functionality BREAKS API
    • FlexBuffers: nested in FlatBuffer accessors, (nested) parsing from JSON, JSON output.
    • Vectors of unions and unions of structs/strings (C++ only so far).
    • Several speed optimizations for larger data types in C++ FlatBufferBuilder.
    • Schema registry functionality.
    • Improvements to the object API.
    • Improved docs: C# API, vector of structs.
    • Many other fixes and improvements, 116 commits since 1.6.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(374.72 KB)
  • v1.6.0(Feb 15, 2017)

  • v1.5.0(Jan 3, 2017)

    A summary of what is in this release since 1.4.0:

    • GRPC support for Go.
    • C# accessors now based on structs (generates less garbage).
    • Improved object API (e.g. choice of pointer types, external references).
    • Flatc can test for conformity against older schema.
    • In-place binary search lookups for C# and Java.
    • Documentation improvements.
    • Many other fixes and improvements, 133 commits since 1.4.0
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(239.70 KB)
  • v1.4.0(Aug 16, 2016)

    A summary of what is in this release since 1.3.0:

    • Support for GRPC!
    • C++ now has an object API: read & write to generated C++ objects.
    • Mutation support in Go & JS.
    • Many improvements in name space handling and general code generation.
    • Libfuzzer based tests.
    • Documentation for C in the main project.
    • Many other fixes and improvements, 300 commits since 1.3
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(206.77 KB)
  • v1.3.0(Feb 3, 2016)

    A summary of what is in this release since 1.2.0:

    • Support for PHP!
    • Much improved documentation: a tutorial shared by all languages.
    • API improvements for Python, C#, and others.
    • C++ code can now be built with GCC as low as 4.4, and doesn't rely on exceptions anymore.
    • JSON parser can now skip unknown fields.
    • Benchmark code available in benchmark branch.
    • Many other fixes and improvements, 140+ commits since 1.2
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(179.12 KB)
  • v1.2.0(Oct 28, 2015)

    A summary of what is in this release since 1.1.0:

    • Support for JavaScript and Python!
    • A much improved C# and Go API and implementation.
    • Simple mutable FlatBuffers functionality (C++/Java/C#).
    • New reflection functionality: binary schemas, and more dynamic read/mutate (C++, relflection.h).
    • Much improved .proto parsing.
    • Many other fixes and improvements, 200+ commits since 1.1
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(158.76 KB)
  • v1.1.0(Apr 1, 2015)

    A summary of what is in this release since 1.0.0:

    • An extensive overhaul to the Java API.
    • Out-of-the-box support for C# and Go.
    • An optional verifier to make FlatBuffers practical in untrusted scenarios.
    • .proto parsing for easier migration from Protocol Buffers.
    • Optional manual assignment of field IDs.
    • Dictionary functionality through binary search on a key field.
    • Bug fixes and other improvements thanks to 200+ commits from 28 contributors.
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(107.33 KB)
  • v1.0.3(Oct 22, 2014)

    This is an interim release before 1.1.0, with important bug fixes and a few new features:

    • C# is now supported.
    • flatc is able to convert .proto files to FlatBuffer schemas for easier migration from Protocol Buffers.
    • Java FlatBuffers functionality is now more friendly, with better generated code for tables and vectors in particular.
    • Support for required fields.
    • C++ enums are now strongly typed.
    • Option to generate dependent includes in C++ ... and many smaller fixes.
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(91.12 KB)
  • v1.0.2(Sep 3, 2014)

    This is an interim release before 1.1.0, with important bug fixes and a few new features:

    • Schemas can now include other schemas directly.
    • Schemas can refer to types from unrelated namespaces.
    • JSON parsing & writing supports unicode escape codes (\u).
    • Enum value prefixing in C++ is now an option.
    Source code(tar.gz)
    Source code(zip)
    flatc_windows_exe.zip(79.31 KB)
  • v1.0.1(Aug 18, 2014)

    This is an interim release before 1.1.0, with important bug fixes and a few new features:

    • Initial support for the Go programming language.
    • Verification functionality allows safe access of buffers from untrusted sources.
    • File identification allows convenient magic-number sanity checks when a FlatBuffer is used as a file format.
    • Ability to manually assign field id's in the schema.
    • Improved enum parsing functionality in JSON.
    • bit_flags for enums.
    • Nested FlatBuffer support.
    • Vector iterators.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jun 17, 2014)

Google ❤️ Open Source
Your binary serialization library

Bitsery Header only C++ binary serialization library. It is designed around the networking requirements for real-time data delivery, especially for ga

Mindaugas Vinkelis 729 Aug 8, 2022
Cap'n Proto serialization/RPC system - core tools and C++ library

Cap'n Proto is an insanely fast data interchange format and capability-based RPC system. Think JSON, except binary. Or think Protocol Buffers, except

Cap'n Proto 9.1k Aug 3, 2022
A C++11 library for serialization

cereal - A C++11 library for serialization cereal is a header-only C++11 serialization library. cereal takes arbitrary data types and reversibly turns

iLab @ USC 3.2k Aug 5, 2022
Simple C++ 20 Serialization Library that works out of the box with aggregate types!

BinaryLove3 Simple C++ 20 Serialization Library that works out of the box with aggregate types! Requirements BinaryLove3 is a c++20 only library.

RedSkittleFox 13 Jun 29, 2022
Zmeya is a header-only C++11 binary serialization library designed for games and performance-critical applications

Zmeya Zmeya is a header-only C++11 binary serialization library designed for games and performance-critical applications. Zmeya is not even a serializ

Sergey Makeev 96 Jul 4, 2022
CppSerdes is a serialization/deserialization library designed with embedded systems in mind

A C++ serialization/deserialization library designed with embedded systems in mind

Darren V Levine 79 Jul 30, 2022
Header-only library for automatic (de)serialization of C++ types to/from JSON.

fuser 1-file header-only library for automatic (de)serialization of C++ types to/from JSON. how it works The library has a predefined set of (de)seria

null 49 Jun 4, 2022
C++17 library for all your binary de-/serialization needs

blobify blobify is a header-only C++17 library to handle binary de-/serialization in your project. Given a user-defined C++ struct, blobify can encode

Tony Wasserka 241 Aug 7, 2022
Yet another JSON/YAML/BSON serialization library for C++.

ThorsSerializer Support for Json Yaml Bson NEW Benchmark Results Conformance mac linux Performance max linux For details see: JsonBenchmark Yet anothe

Loki Astari 277 Aug 2, 2022
Cista is a simple, high-performance, zero-copy C++ serialization & reflection library.

Simple C++ Serialization & Reflection. Cista++ is a simple, open source (MIT license) C++17 compatible way of (de-)serializing C++ data structures. Si

Felix Gündling 926 Aug 8, 2022
Microsoft 2.4k Aug 7, 2022
Fast Binary Encoding is ultra fast and universal serialization solution for C++, C#, Go, Java, JavaScript, Kotlin, Python, Ruby, Swift

Fast Binary Encoding (FBE) Fast Binary Encoding allows to describe any domain models, business objects, complex data structures, client/server request

Ivan Shynkarenka 591 Aug 2, 2022
Yet Another Serialization

YAS Yet Another Serialization - YAS is created as a replacement of boost.serialization because of its insufficient speed of serialization (benchmark 1

niXman 558 Aug 4, 2022
Binary Serialization

Binn Binn is a binary data serialization format designed to be compact, fast and easy to use. Performance The elements are stored with their sizes to

null 365 Aug 5, 2022
An implementation of the MessagePack serialization format in C / msgpack.org[C]

CMP CMP is a C implementation of the MessagePack serialization format. It currently implements version 5 of the MessagePack Spec. CMP's goal is to be

Charlie Gunyon 281 Aug 5, 2022
MPack - A C encoder/decoder for the MessagePack serialization format / msgpack.org[C]

Introduction MPack is a C implementation of an encoder and decoder for the MessagePack serialization format. It is: Simple and easy to use Secure agai

Nicholas Fraser 376 Jul 27, 2022
Serialization framework for Unreal Engine Property System that just works!

DataConfig Serialization framework for Unreal Engine Property System that just works! Unreal Engine features a powerful Property System which implemen

null 67 Aug 5, 2022
Yet Another Serialization

YAS Yet Another Serialization - YAS is created as a replacement of boost.serialization because of its insufficient speed of serialization (benchmark 1

niXman 455 Sep 7, 2021
universal serialization engine

A Universal Serialization Engine Based on compile-time Reflection iguana is a modern, universal and easy-to-use serialization engine developed in c++1

qicosmos 625 Aug 3, 2022