Cista is a simple, high-performance, zero-copy C++ serialization & reflection library.

Overview

Simple C++ Serialization & Reflection.

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

Single header - no dependencies. No macros. No source code generation.

  • Raw performance - use your native structs. Supports modification/resizing of deserialized data!
  • Supports complex and cyclic data structures including cyclic references, recursive data structures, etc.
  • Save 50% memory: serialize directly to the filesystem if needed, no intermediate buffer required.
  • Fuzzing-checked though continuous fuzzing using LLVMs LibFuzzer.
  • Comes with a serializable high-performance hash map and hash set implementation based on Google's Swiss Table.
  • Reduce boilerplate code: automatic derivation of hash and equality functions.
  • Built-in optional automatic data structure versioning through recursive type hashing.
  • Optional check sum to prevent deserialization of corrupt data.
  • Compatible with Clang, GCC, and MSVC

The underlying reflection mechanism can be used in other ways, too!

Examples:

Download the latest release and try it out.

Simple example writing to a buffer:

(buf); assert(deserialized->j.b_ == data::string{"test"}); ">
namespace data = cista::raw;
struct my_struct {  // Define your struct.
  int a_{0};
  struct inner {
      data::string b_;
  } j;
};

std::vector<unsigned char> buf;
{  // Serialize.
  my_struct obj{1, {data::string{"test"}}};
  buf = cista::serialize(obj);
}

// Deserialize.
auto deserialized = cista::deserialize
   (buf);

   assert(deserialized->j.b_ == data::string{
   "test"});
  

Advanced example writing a hash map to a memory mapped file:

(mmap, positions); } // Deserialize. auto b = cista::mmap("data", cista::mmap::protection::READ); auto positions = cista::deserialize (b); ">
namespace data = cista::offset;
constexpr auto const MODE =  // opt. versioning + check sum
    cista::mode::WITH_VERSION | cista::mode::WITH_INTEGRITY;

struct pos { int x, y; };
using pos_map =  // Automatic deduction of hash & equality
    data::hash_map
    
     ,
                   data::hash_set
     
      >;

{  
      // Serialize.
  
      auto positions =
      pos_map{{{{
      1, 
      2}, {
      3, 
      4}}, {
      "hello", 
      "cista"}},
              {{{
      5, 
      6}, {
      7, 
      8}}, {
      "hello", 
      "world"}}};
  cista::buf mmap{cista::mmap{
      "data"}};
  cista::serialize
      
       (mmap, positions);
}


       // Deserialize.

       auto b = cista::mmap(
       "data", cista::mmap::protection::READ);

       auto positions = cista::deserialize
       
        (b);
       
      
     
    
   

Benchmarks

Have a look at the benchmark repository for more details.

Library Serialize Deserialize Fast Deserialize Traverse Deserialize & Traverse Size
Cap’n Proto 105 ms 0.002 ms 0.0 ms 356 ms 353 ms 50.5M
cereal 239 ms 197.000 ms - 125 ms 322 ms 37.8M
Cista++ offset 72 ms 0.053 ms 0.0 ms 132 ms 132 ms 25.3M
Cista++ raw 3555 ms 68.900 ms 21.5 ms 112 ms 133 ms 176.4M
Flatbuffers 2349 ms 15.400 ms 0.0 ms 136 ms 133 ms 63.0M

Use Cases

Reader and writer should have the same pointer width. Loading data on systems with a different byte order (endianess) is supported. Examples:

  • Asset loading for all kinds of applications (i.e. game assets, GIS data, large graphs, etc.)
  • Transferring data over network
  • shared memory applications

Currently, only C++17 software can read/write data. But it should be possible to generate accessors for other programming languages, too.

Alternatives

If you need to be compatible with other programming languages or require protocol evolution (downward compatibility) you should look for another solution:

Documentation

Contribute

Feel free to contribute (bug reports, pull requests, etc.)!

Issues
  • Custom type size calculations are too early during serialization

    Custom type size calculations are too early during serialization

    Hi!

    During serialization, the size of a type provided is calculated by sizeof(value), here: https://github.com/felixguendling/cista/blob/707ef83b3302104a2aeac5714ff9148ac2e94dc4/include/cista/serialization.h#L194-L196

    This is too early IMO to calculate size and alignment when working with custom type.

    For example, let's consider these structs:

    struct Simple { std::vector<int> data; } simple; template <typename Ctx> void serialize(Ctx& c, Simple const* el, offset_t const pos) { c.write(pos, el->data[0]); }

    struct Complex { Simple simple1; Simple simple2; Simple simple3; } complex; template <typename Ctx> void serialize(Ctx& c, Complex const* el, offset_t const pos) { c.write(pos, (int)42); }

    When serialized, they will create 0x20 and 0x60 bytes respectiviely (std::vector from MVSC 2017 15.9.0) for cista::byte_buf as a result of sizeof(Simple) and sizeof(Complex) - this cannot be easily overloaded in custom serialization since Context is already given (alocated) and it could only grow.

    opened by ChemistAion 23
  • Ser/Des-ialize does not rebuild ptrs etc. - an another day with namespaces

    Ser/Des-ialize does not rebuild ptrs etc. - an another day with namespaces

    Please take a look on this example: https://wandbox.org/permlink/l2iEAmTpiCWFtLb6

    Works like a charm, i.e.: CISTA::vector<CISTA::ptr<ElementTest>> paths_ pointers are perfectly rebuild during deserialization. No issue...

    Exactly same stuff under latest VS 17.2.6 with all features beyond C++20 enabled gives me two things:

    • static_assert need for a custom serializer for ElementTest - whereas wandbox not;
    • after ser/des empty fn provided for ElementTest, paths_ still points to memory before serialization;

    I am still investigating this...

    opened by ChemistAion 16
  • Bug with inheritance and static data members

    Bug with inheritance and static data members

    The following program

    #include <iostream>
    #include "cista.h"
    
    struct a {
        static int x;
        int z;
        CISTA_PRINTABLE(a)
    };
    
    struct b : public a {
        int y;
        CISTA_PRINTABLE(b)
    };
    
    int main() {
      b instance;
      std::cout << instance;
      // "{1, 2, 100, hello}"
    }
    
    int a::x = 42;
    

    yields the following error for me:

    ~/Downloads $ clang++-9 -std=c++2a bah.cc -o bah                                                                                                                  16:27:20
    In file included from bah.cc:2:
    ./cista.h:2149:11: error: cannot decompose class type 'b': both it and its base class 'a' have non-static data members
        auto& [p1, p2] = t;
              ^
    ./cista.h:3734:58: note: in instantiation of function template specialization 'cista::to_tuple<const b>' requested here
        std::apply([&](auto&&... args) { (fn(args), ...); }, to_tuple(t));
                                                             ^
    bah.cc:12:5: note: in instantiation of function template specialization 'cista::for_each_field<const b, (lambda at bah.cc:12:5)>' requested here
        CISTA_PRINTABLE(b)
        ^
    ./cista.h:6381:14: note: expanded from macro 'CISTA_PRINTABLE'
        ::cista::for_each_field(o, [&](auto&& f) {                              \
                 ^
    1 error generated.
    

    I would like to use cista in a project where there is a lot of inheritance and static members, so this is a problem. I don't know enough about [] binding and templating to know if there is a way to work around this, or if it's a more fundamental limitation.

    opened by edmcman 8
  • How to make cista::get_if<Type> works?

    How to make cista::get_if works?

    I have this little fellow here:

    using Variant = CISTA::variant
    	<
    	bool,
    	std::int64_t
    	>;
    
    Variant test{ true };
    
    auto result = cista::get_if<bool>(test);
    

    ...and I am getting (on VS2019/VS2022prev, both C++20): "Error C2563 mismatch in formal parameter list" "Error C2568 '==': unable to resolve function overload" on: https://github.com/felixguendling/cista/blob/23875effbc4f3441304137515991dbcfbc52caed/include/cista/containers/variant.h#L380

    I know that I could address bool by its index in Variant - namely 0, but how to make it happen with Type directly? I am trying to make this through cista::get_if implementations... test-case "variant_test.cc" helps me not.

    [C2563] https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c2563?f1url=%3FappId%3DDev16IDEF1%26l%3DEN-US%26k%3Dk(C2563)%26rd%3Dtrue&view=msvc-160

    [C2568] https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c2568?f1url=%3FappId%3DDev16IDEF1%26l%3DEN-US%26k%3Dk(C2568)%26rd%3Dtrue&view=msvc-160

    opened by ChemistAion 8
  • cista::variant serialization of cista::unique_ptr with T=cista::container of the variant itself

    cista::variant serialization of cista::unique_ptr with T=cista::container of the variant itself

    Hi! I know, I know... how this issue summary sounds :) so let's go to an example. I have cista representation of JSON structure like this (cista::mode is NONE default):

    namespace CISTA = cista::offset;
    
    using Null = std::monostate;
    
    struct MetaArray;
    struct MetaObject;
    
    using MetaValue = CISTA::variant
    	<
    	Null,
    	CISTA::string,
    	std::int64_t,
    	std::uint64_t,
    	double,
    	bool,
    	CISTA::unique_ptr<MetaArray>,
    	CISTA::unique_ptr<MetaObject>
    	>;
    
    struct MetaArray : public CISTA::vector<MetaValue> {};
    
    struct MetaObject : public CISTA::hash_map<CISTA::string, MetaValue> {};
    

    Building it works (starting at MetaObject level) with no problem -> after this silly change #96 Serialization of MetaObject or directly MetaValue breaks at: https://github.com/felixguendling/cista/blob/23875effbc4f3441304137515991dbcfbc52caed/include/cista/reflection/to_tuple.h#L472 with (VS2019/VS2022prev output): "Error C3448 the number of identifiers must match the number of array elements or members in a structured binding declaration"

    Same for both std::vector<>/void cista::serialize(...) approaches

    opened by ChemistAion 7
  • Cista::Variant serialization issue above C++17

    Cista::Variant serialization issue above C++17

    Hi Felix!

    It's been a while since my last interaction with Cista.... so many new features since, my congrats!

    To the point... :) I have switched lately my project to the VS "/std:c++latest" and "/std:c++20" (both: 2019 and 2022 preview) and since that I noticed that this serialize(...) usage: https://github.com/felixguendling/cista/blob/23875effbc4f3441304137515991dbcfbc52caed/include/cista/serialization.h#L324-L326 produces hard error: "Error C1001 Internal compiler error".

    I know, I know that Cista is C++17 project... but since everything else just works(!) and only this one(!) particular error occurs (even during clean single-header build/tests) I though it is worth mentioning here.

    FYI: I did all the preliminary use-case analysis, all of them - even simple tryout of cista::variant serialization leads to "this".

    I will investigate it further on my own (right now)... but I'm silently counting on your help here - even it is outside the target (C++17).

    opened by ChemistAion 7
  • `deserialize` doesn't work with `const char*` in non-CAST mode

    `deserialize` doesn't work with `const char*` in non-CAST mode

    deserialize(CharT *in, CharT *out) only works with const char* in CAST mode. If I try setting the mode to non-CAST, deserialization_context requires the input to be char* and check only works with uint8_t.

    Is it possible to make the API work with both const char* and const uint8_t* in all modes?

    opened by dm3 5
  • cista::variant<>

    cista::variant<>

    Hi, the library looks great but it seems there is no support for unions. Unions are needed for polymorphism.

    I tried

    	struct my_struct {  // Define your struct.
    		int a_{0};
    		union inner {
    			int b_{0};
    			char d_;
    		} j;
    	};
    

    and the main error using VS2019 is C2672: 'arity': no matching overloaded function found and using latest GCC is cista.h:1290:31: error: no matching function for call to ‘arity(const main()::my_struct::inner&)’.

    Maybe std::variant would help in this case instead of plain union.

    enhancement 
    opened by cflaviu 5
  • Custom serialization of std::map

    Custom serialization of std::map

    Hi Felix,

    I want to serialize an ordered map. Because the library doesn't provide such container I would use std::map.

    using ordered_map = std::map<std::uint32_t, cista::offset::hash_set<int>>;

    The documentation doesn't cover such topic and I'm asking:

    1. I think this serialization and deserialization of needs raw mode instead of offset mode (and offset mode just for mapped value). How the custom serialization and deseriation functions would look like? I would be a good point in documentation the custom serialization and deserialization of a std::map.

    2. Is it possible to include such map in a structure serializing and deserializing the entire structure? Eg.

    struct my_data
    {
        ordered_map map;
        cista::offset::vector<int> array;
    };
    
    1. If this is possible, how the serialization and deserialization functions would look like?

    Regards Flaviu

    opened by cflaviu 4
  • Is the output data compatible across other compilers and OS?

    Is the output data compatible across other compilers and OS?

    Hello

    First of all Cista is great, good work, you have my gratitude I have a small dumb question. Im curious about the compatibility of the data produced by Cista. Is there any known limitations of being used in different environment?

    opened by devildevilson 4
  • Tuple fix

    Tuple fix

    Fixes cista::get for cista::tuple with identical types. Enables structured bindings for cista::tuple.

    Originally, I was trying to make

    struct s { cista::tuple<int, int, int> t_; };

    serialize by "default". It is not in standard layout due to the tuple implementation, so to_tuple_works always evaluates to false. It should serialize just fine in practice if the static_assert is disabled :). I think there is no possibility to catch this edge case in to_tuple_works, or is there?

    opened by julianharbarth 3
  • smart pointer for deserializing and storing values from different aligned and unaligned sources

    smart pointer for deserializing and storing values from different aligned and unaligned sources

    std::variant<
      unique_ptr<T> /* aus T const& angelegt und kopiert */,
      T const* /* pointer aus bereits alignedtem speicher gespeichert */,
      aligned_buf /* unaligned pointer musste kopiert werden */
    >
    
    enhancement 
    opened by felixguendling 0
  • Memory usage using cista::variant

    Memory usage using cista::variant

    I'm trying to use cista for a protocol with messages (structures) having between 8 and 88 bytes. I used cista::offset::vector<cista::variant<msg1, msg2, etc.>>.

    Having a vector containing 10 messages of 8 bytes, what would be the memory used? I guess the serialized buffer will have approximately the same size.

    opened by cflaviu 12
  • mmap with mmap::protection::MODIFY throws exception

    mmap with mmap::protection::MODIFY throws exception

    I try to run this simple code and I get exception 'std::runtime_error': what(): open file mode not supported from file "cista/targets/file.h" line 31 verify(read || write, "open file mode not supported");

    I use Windows with msys2(mingw64).

        namespace data = cista::offset;
        constexpr auto const MODE = cista::mode::WITH_VERSION | cista::mode::WITH_INTEGRITY;
    
        struct pos {
            int x, y;
        };
    
        using vec = data::vector<pos>;
    
        {
            vec positions{{1, 2}, {3, 4}, {5, 6}, {7, 8}};
            cista::buf mmap{cista::mmap{"data"}};
            cista::serialize<MODE>(mmap, positions);
        }
    
        auto b = cista::mmap("data", cista::mmap::protection::MODIFY);
        auto positions = cista::deserialize<vec, MODE>(b);
        positions->push_back({5, 5});
    
        for(auto pos : *positions) {
            std::cout << pos.x << " " << pos.y << std::endl;
        }
    

    And question. I need load data from disk and modify it, but I don't need to sync data always with disk. Should I serialize data from disk, copy it to memory and, after changing it, serialize it back? Or should I just use mmap::modify? I do not fully understand how much mmap costs and what is more efficient"

    opened by BinaryCat17 3
  • Support for std::u16string.

    Support for std::u16string.

    Could it be possible to add support for more basic string types like std::wstring, std::u16string, std::u32string. Pretty much it, i would add this my self but im confused as to how the string gets turned to bytes. Is it safe to just add more genric_string defines for std::u16string?

    opened by Gringoniceguy 9
  • Using cista array with big array size cause seg fault

    Using cista array with big array size cause seg fault

    In my application I have several big data structures, that I want to dump to the disk, and I can compute size of data in compile time. So Im using cista::array, but seem like there is a bug and Im receiving the invalid address error. Ive attached the example in the hastebin

    The error Ive got look like this

    * thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address (fault address: 0x7ffffdda5d70)
        frame #0: 0x00005555555578a0 a.out`unsigned long cista::type_hash<cista_serializator>() at cista.h:4482:8
       4479
       4480 template <typename T>
       4481 hash_t type_hash() {
    -> 4482   auto done = std::map<hash_t, unsigned>{};
       4483   return type_hash(T{}, BASE_HASH, done);
       4484 }
       4485
    
    Process 61576 launched: 'a.out' (x86_64)
    (lldb) bt
    * thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address (fault address: 0x7ffffdda5d70)
      * frame #0: 0x00005555555578a0 a.out`unsigned long cista::type_hash<cista_serializator>() at cista.h:4482:8
        frame #1: 0x0000555555557242 a.out`void cista::serialize<(cista::mode)6, cista::buf<std::vector<unsigned char, std::allocator<unsigned char> > >, cista_serializator>(t=0x00007fffffffe480, value=0x00007ffff582d010) at cista.h:4814:40
        frame #2: 0x0000555555556f31 a.out`std::vector<unsigned char, std::allocator<unsigned char> > cista::serialize<(el=0x00007ffff582d010)6, cista_serializator>(cista_serializator&) at cista.h:4845:18
        frame #3: 0x0000555555556401 a.out`main(argc=1, argv=0x00007fffffffe608) at main.cpp:41:45
        frame #4: 0x00007ffff7ab2152 libc.so.6`__libc_start_main + 242
        frame #5: 0x00005555555562ae a.out`_start + 46
    

    OS: Linux x86_64, compiler: gcc version 10.2.0 (GCC), compile command: g++ -std=c++17 -I. -g main.cpp, Ive tried cista::offset and cista::raw, but no luck

    opened by devildevilson 4
  • GCC 9.2 - `vector::to_vec` linkage error

    GCC 9.2 - `vector::to_vec` linkage error

    Not sure what's exactly causing the issue, but once I nest templates deep enough the following happens upon trying to call the cista::offset::to_vec(std::vector<double>) macro:

    my.cpp: In function `cista::basic_vector<double, cista::offset_ptr<double, void>, false, unsigned int>::basic_vector()':
    /usr/local/cista/include/cista/containers/vector.h:21: undefined reference to `cista::offset_ptr<double, void>::offset_ptr(decltype(nullptr))'
    my.cpp: In function `cista::basic_vector<double, cista::offset_ptr<double, void>, false, unsigned int>::basic_vector(cista::basic_vector<double, cista::offset_ptr<double, void>, false, unsigned int> const&)':
    /usr/local/cista/include/cista/containers/vector.h:47: undefined reference to `cista::offset_ptr<double, void>::offset_ptr(decltype(nullptr))'
    collect2: error: ld returned 1 exit status
    

    Error disappears once I create and call to_vec function instead of the to_vec macro:

    inline auto to_vec(const std::vector<double> &vs) {
      message::data::vector<double> v;
      v.reserve(std::size(vs));
      std::copy(std::cbegin(vs), std::cend(vs), std::back_inserter(v));
      return v;
    }
    

    If I make the above function a template, i.e. to_vec<double>(std::vector), the link error comes back.

    opened by dm3 5
Releases(v0.10)
  • v0.10(Feb 8, 2022)

    What's Changed

    • add bitset container by @felixguendling in https://github.com/felixguendling/cista/pull/114
    • Fix pretty printers by @julianharbarth in https://github.com/felixguendling/cista/pull/119
    • bitset pretty printer by @felixguendling in https://github.com/felixguendling/cista/pull/120
    • add byte_buf to memory_holder variant by @pablohoch in https://github.com/felixguendling/cista/pull/122
    • fix popcnt for win32 msvc by @felixguendling in https://github.com/felixguendling/cista/pull/124
    • New tuple by @julianharbarth in https://github.com/felixguendling/cista/pull/127
    • make variant ctor constexpr by @felixguendling in https://github.com/felixguendling/cista/pull/125

    Full Changelog: https://github.com/felixguendling/cista/compare/v0.9...v0.10

    Source code(tar.gz)
    Source code(zip)
    cista.h(200.11 KB)
  • v0.9(Nov 16, 2021)

    What's Changed

    • cista members by @felixguendling in https://github.com/felixguendling/cista/pull/112 enabling to support reflection/serialization (also CISTA_COMPARABLE, CISTA_PRINTABLE, etc.) by adding a auto cista_members() constexpr { return std::tie(m1_, m_2, ...); } function returning all members as a std::tie().
    • Pretty Printers for Cista by @julianharbarth in https://github.com/felixguendling/cista/pull/107 to support pretty printing data of cista types in GDB-based debuggers including the Clion debugger UI

    Full Changelog: https://github.com/felixguendling/cista/compare/0.8...v0.8

    Source code(tar.gz)
    Source code(zip)
    cista.h(187.46 KB)
  • 0.8(Oct 13, 2021)

    What's Changed

    • ARM support (32bit / 64bit)
    • Tuple data structure
    • member_index utility
    • noexcept where possible
    • mingw support
    • fix hashing for empty strings
    • fix mmap move for Windows
    • fix serialization of empty vectors

    New Contributors

    • @sfahnens made their first contribution in https://github.com/felixguendling/cista/pull/75
    • @pablohoch made their first contribution in https://github.com/felixguendling/cista/pull/81
    • @cflaviu made their first contribution in https://github.com/felixguendling/cista/pull/94
    • @julianharbarth made their first contribution in https://github.com/felixguendling/cista/pull/108

    Full Changelog: https://github.com/felixguendling/cista/compare/v0.7...0.8

    Source code(tar.gz)
    Source code(zip)
    cista.h(216.79 KB)
  • v0.7(Mar 9, 2020)

    • New serializable sum type cista::variant<T...> (similar to std::variant) with type hash and hashing support.
    • CMake option CISTA_HASH with supported values FNV1A (default), XXH3, WYHASH and WYHASH_FASTEST
    • Win32 support including Contiunous Integration
    • CMake install target
    • Endian conversion bugfix (floating point types)
    Source code(tar.gz)
    Source code(zip)
    cista.h(194.00 KB)
  • v0.6(Nov 19, 2019)

  • v0.5(Nov 6, 2019)

    New features:

    • Serializable high-performance hash map and hash set implementation based on Google's Swiss Table technique. By default, hash and equality are generated automatically.
    • Optional feature: Automatic data structure versioning based on generated type-hashes
    • Optional feature: checksum to prevent deserialization of corrupt data (data integrity check)
    • Memory mapped file target for serialization (~6x speed-up for practical serialization test)
    • Big endian support
    • More ways to index values (indexed_vector<T>, indexed<T>) to be able to point to them
    • Updated documentation

    Development: fuzzing (also integrated into CI)

    Source code(tar.gz)
    Source code(zip)
    cista.h(178.01 KB)
  • v0.3(Dec 23, 2018)

  • v0.2(Dec 16, 2018)

    offset_ptr: stores the offset as difference between this and the object it points to. Serializing this allows to skip the deserialization step and just use a reinterpret_cast<T>(buf.begin()). This is useful for example in situations with shared memory.

    Source code(tar.gz)
    Source code(zip)
  • v0.1(Dec 12, 2018)

Owner
Felix Gündling
PostDoc (computer science, algorithms group) at Technische Universität Darmstadt. C++ enthusiast. Swimmer.
Felix Gündling
Microsoft 2.4k Jul 29, 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
Use to copy a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures.

ntfsDump Use to copy a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures. Similar to https://github.com/P

null 41 Jul 17, 2022
Simple Binary Encoding (SBE) - High Performance Message Codec

Simple Binary Encoding (SBE) SBE is an OSI layer 6 presentation for encoding and decoding binary application messages for low-latency financial applic

Real Logic 2.7k Aug 5, 2022
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 727 Jul 30, 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
FlatBuffers: Memory Efficient Serialization Library

FlatBuffers FlatBuffers is a cross platform serialization library architected for maximum memory efficiency. It allows you to directly access serializ

Google 18.4k Aug 2, 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 242 Jul 23, 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 276 Jul 28, 2022
A high performance C++14 library for effortlessly reading and writing UBJSON

UbjsonCpp A high performance C++14 library for effortlessly reading and writing UBJSON This library implements UBJSON Draft 12 and Value semmantics Ab

Ibrahim Timothy Onogu 21 Aug 2, 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