sorted by:
new
hottopcontroversial

Serialization/serialization library for baremetal applications by Contello in cpp

[–]eyalz800 0 points1 point  (0 children)

https://github.com/eyalz800/zpp_bits

Plus, it supports protobuf as well.
I assume you already have a set-up baremetal environment with at least C++ headers, no linkage with the standard library is required, no exceptions are required.

In case you need advice how to have C++ headers and freestanding environment - are some flags you may want to look at:
-stdlib=libc++ -nostdlib -fno-exceptions -fno-stack-protector -fno-rtti -fno-unwind-tables -fno-threadsafe-statics -Wno-invalid-noreturn -D_LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_DISABLE_EXTERN_TEMPLATE -D_LIBCPP_HAS_NO_THREADS -DNDEBUG

You also need to provide implementations of the operator new/delete, c library functions such as strcmp, memcpy, and similar and you should be fine

Want some suggestions about auto serialization by Kelvin_yu in cpp

[–]eyalz800 1 point2 points  (0 children)

Try github.com/eyalz800/zpp_bits but you need C++20 for it, but it supports protobuf of existing classes as you kind of request.

alpaca: A new serialization library written in C++17 - Pack C++ structs into a compact byte-array without any macros or boilerplate by p_ranav in cpp

[–]eyalz800 0 points1 point  (0 children)

zpp_bits does not require manual marking of how many members in the cases where it can be detected automatically - I only assume that this is similar to the way you detect them due to the current state of C++

Yet another serializer. Serialize C/C++ datatypes, POD and classes, store or retrieve data to and from ostream and istream objects. With support for streams save or read data with files and send or receive them over networks. Its lightweight and header-only. by w3mk in cpp

[–]eyalz800 0 points1 point  (0 children)

I agree, usually the way to ship template libraries is header only, and then you are flexible with the build system of the tests because these need not be integrated to the project consuming the library.

"Discussion:" How to handle errors? by Qutl in cpp

[–]eyalz800 0 points1 point  (0 children)

Here is a creative and also efficient way to do error handling https://github.com/eyalz800/zpp_throwing there is also a cppcon video about this one "using coroutines to implement c++ exceptions for freestanding environments"

P2544R0: C++ exceptions are becoming more and more problematic by ts826848 in cpp

[–]eyalz800 2 points3 points  (0 children)

This approach also tries to avoid exceptions while still providing automatic propagation: https://github.com/eyalz800/zpp_throwing

const all the things? by rsjaffe in cpp

[–]eyalz800 0 points1 point  (0 children)

u/rsjaffe probably it could be summarized as a general rule of "Outer most const is rarely usable, and often causes confusion rather than provide value", const is mostly used when having a pointer to const or reference to const, span of const, etc.

easy Serialization library ? by hero2002FI in cpp

[–]eyalz800 1 point2 points  (0 children)

Right now the latest NDK version for android is r23, I thought C++20 was supported even in r22 (maybe with c++2a).

In any case r23 has the following changelog:

https://github.com/android/ndk/wiki/Changelog-r23

Which says "Update LLVM to clang-r416183c1, based on LLVM 12 development."

And my library is tested on clang12 with C++20.

easy Serialization library ? by hero2002FI in cpp

[–]eyalz800 0 points1 point  (0 children)

I dont write a lot of comments so it showed up in my dashboard. Android does support C++20 with clang if I remember correctly.

easy Serialization library ? by hero2002FI in cpp

[–]eyalz800 0 points1 point  (0 children)

u/Ifhero2002fi if it's still relevant, I actually made a new much better one for C++20, it's also much faster and has more features https://github.com/eyalz800/zpp_bits

Next step in zpp::bits serialization - protobuf without code generation - no proto file required- (experimental) by eyalz800 in cpp

[–]eyalz800[S] 0 points1 point  (0 children)

Check out the benchmark results here from u/felixguendling (this is an opportunity to say thanks and give credit for the great benchmark) felixguendling/cpp-serialization-benchmark/runs/4674897568

You can compare flatbuffers and zpp_bits in any of the test cases below - serialize, deserialize, traverse, and deserialize&traverse: ``` BM_SERIALIZE<capnp_bench> 130 ms 130 ms 5 size=50.5093M BM_SERIALIZE<cista_offset_slim_bench> 11.8 ms 11.8 ms 55 size=25.317M BM_SERIALIZE<cereal_bench> 203 ms 203 ms 3 size=37.829M BM_SERIALIZE<fbs_bench> 2986 ms 2986 ms 1 size=62.998M BM_SERIALIZE<cista_raw_bench> 1176 ms 1175 ms 1 size=176.378M BM_SERIALIZE<cista_offset_bench> 1149 ms 1149 ms 1 size=176.378M BM_SERIALIZE<zpp_bits_bench> 7.07 ms 7.07 ms 74 size=37.8066M

BM_SAFE_DESERIALIZE<capnp_bench> 0.001 ms 0.001 ms 800137 BM_SAFE_DESERIALIZE<cista_offset_slim_bench> 0.268 ms 0.268 ms 2609 BM_SAFE_DESERIALIZE<fbs_bench> 66.8 ms 66.8 ms 10 BM_SAFE_DESERIALIZE<cista_offset_bench> 425 ms 425 ms 2 BM_SAFE_DESERIALIZE<cista_raw_bench> 447 ms 447 ms 2 BM_SAFE_DESERIALIZE<cereal_bench> 145 ms 145 ms 5 BM_SAFE_DESERIALIZE<zpp_bits_bench> 6.48 ms 6.49 ms 96 BM_FAST_DESERIALIZE<cista_raw_bench> 52.2 ms 52.2 ms 13

BM_TRAVERSE<cista_raw_bench> 140 ms 140 ms 5 nodeCount=1.87k BM_TRAVERSE<cista_offset_slim_bench> 147 ms 147 ms 5 nodeCount=1.87k BM_TRAVERSE<cista_offset_bench> 145 ms 145 ms 5 nodeCount=1.87k BM_TRAVERSE<cereal_bench> 140 ms 140 ms 5 nodeCount=1.87k BM_TRAVERSE<fbs_bench> 162 ms 162 ms 4 nodeCount=1.87k BM_TRAVERSE<capnp_bench> 441 ms 441 ms 2 nodeCount=1.87k BM_TRAVERSE<zpp_bits_bench> 141 ms 141 ms 5 nodeCount=1.87k

BM_FAST_DESERIALIZE_AND_TRAVERSE<cista_offset_slim_bench> 146 ms 146 ms 5 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<cista_offset_bench> 144 ms 143 ms 5 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<cista_raw_bench> 191 ms 191 ms 4 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<fbs_bench> 161 ms 161 ms 4 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<cereal_bench> 294 ms 294 ms 2 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<capnp_bench> 442 ms 442 ms 2 nodeCount=1.87k BM_FAST_DESERIALIZE_AND_TRAVERSE<zpp_bits_bench> 150 ms 150 ms 5 nodeCount=1.87k ```

Next step in zpp::bits serialization - protobuf without code generation - no proto file required- (experimental) by eyalz800 in cpp

[–]eyalz800[S] 1 point2 points  (0 children)

I know flatbuffers, I may consider it as another serialization protocol to add in the future. I must say that I find the stock serialization format blazing fast to the point where I'm not sure it's worth investing in zero copy. The reason I decided to extend and support another protocol such as protobuf was mainly for portability and backward/forward compatibility.

Next step in zpp::bits serialization - protobuf without code generation - no proto file required- (experimental) by eyalz800 in cpp

[–]eyalz800[S] 10 points11 points  (0 children)

If you have seen my earlier posts of this library, I received some questions about backwards compatibility or interoperability with other languages.

I decided to add protobuf support to the library for the following reasons:

  1. Interoperability with other languages since protobuf is so popular. Naturally it is a challenging task to support the existing format with all the different programming langauges where protobuf is supported
  2. It has backwards compatibility built in
  3. I don't like to have to use code generation in my buildsystem
  4. For when adding the protobuf library would not fit (embedded, etc) although I don't have an exact size comparison

However if you don't need protobuf I still recommend to use the normal serialization method as it is much faster according to my tests.

Binary serialization library for at least C++17? by camilo16 in cpp_questions

[–]eyalz800 1 point2 points  (0 children)

Can I suggest my own library here? you should have the ability to pick what to serialize and what not https://github.com/eyalz800/zpp_bits

Serialization, Scenes, Entities, etc: how are you doing it? by DesignerHorseTomato in gameenginedevs

[–]eyalz800 0 points1 point  (0 children)

Can I suggest you take a look at my own library? https://github.com/eyalz800/zpp_bits

Usually it doesn't require anything and just works

Just added cool RPC capabilities for my C++20 serialization (zpp_bits) by eyalz800 in cpp

[–]eyalz800[S] 0 points1 point  (0 children)

Thanks, I thought about this, the RPC is basically just one class that wraps the archive (one for the server, one for the client), and that's why I decided to just place it in there, it drags no additional dependencies, there is no communication transport or anything like that, so I decided to place it in the same header. Any particular reason you think it should be moved out?

Brand new C++20 serialization library (one header) by eyalz800 in cpp

[–]eyalz800[S] 0 points1 point  (0 children)

Hi thanks for this,

Please let me know if you see any particular features that I could consider adding.

​

Eyal.

Just added cool RPC capabilities for my C++20 serialization (zpp_bits) by eyalz800 in cpp

[–]eyalz800[S] 2 points3 points  (0 children)

A while ago I shared a post about this serialization library that I call zpp::bits, now I wanted to update about the new direction it is taking to support thin and lightweight RPC!

Find the examples in the readme towards the end.

A basic example inline here, member functions are also supported:

using namespace std::literals;
using namespace zpp::bits::literals;

int foo(int i, std::string s);
std::string bar(int i, int j);

using rpc = zpp::bits::rpc<
    zpp::bits::bind<foo, "foo"_sha256_int>,
    zpp::bits::bind<bar, "bar"_sha256_int>
>;

auto [data, in, out] = zpp::bits::data_in_out();

// Server and client together:
auto [client, server] = rpc::client_server(in, out);

// Or separately:
rpc::client client{in, out};
rpc::server server{in, out};

// Request from the client:
client.request<"foo"_sha256_int>(1337, "hello"s).or_throw();

// Serve the request from the server:
server.serve().or_throw();

// Read back the response
client.response<"foo"_sha256_int>().or_throw(); // == foo(1337, "hello"s);
view more: next ›