5 ms·

there's a lot of C++ around this FlexBuffer thing so I'm not sure how relevant it is outside of C++. Any idea?

mmastrac 6y ago
We use FlatBuffers (the parent project) in our code @ FS... that means it has to work in C++, Rust, Java, and TypeScript. It's mostly the schema processing that requires a C++ compiler to make it work. It's a pretty stellar cross-platform serialization toolkit and the zero-copy support for reading is no joke.
- maximilianburke 6y ago
  We've been using it across multiple languages too as the data serialization format between server and (web) client. It's fantastic.
jchook 6y ago
AFAIK some languages can use C++ fairly easily, including D and Rust
- kccqzy 6y ago
  These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features. Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises. And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises. The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.
  - pjmlp 6y ago
    Wrong, D has support for C++ FFI. https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
    - kccqzy 6y ago
      It supports neither templates nor ADL, the two of my examples. In fact the doc says, > Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. It then goes on to describe the pragmatic approach that doesn't allow full compatibility: > D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem: > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Can you see how limited this subset of interoperable API is?
      - pjmlp 6y ago
        I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.
      - gpderetta 6y ago
        > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Basically COM? Which is not surprising as it was designed as an OO native FFI.
        pjmlp 6y ago
        And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.
DethNinja 6y ago
It is basically a code template generator. It is written in C++ but it can generate code for other languages. It is one of the best serialisation methods currently available.
tkzed49 6y ago
FlatBuffers libraries are implemented in a big list of languages, as you can see on the website. FlexBuffers is not implemented in all the same languages yet, at least in the official Google repo. Otherwise, it is very relevant in any language--it's a binary serialization format.
- mzaks 6y ago
  If you need a language support for FlexBuffers please create an issue on GitHub repo. I ported it already to Swift, C#, Dart, Python, JS (is in review). If I am familiar with the language you need, it will take me just a couple of days to port it.
Aardappel 6y ago
FlexBuffers currently is implemented in C++, Java, Rust, Dart, Swift, (and JS under review).
- mzaks 6y ago
  You forgot Python and C# :). Plus a Unity3D specific version, which is battle tested in a game with more than half a million downloads ;).
_nhynes 6y ago
The codegen for flatbuffers is fairly extensive, but C++ is still the blessed language for gRPC, however [0]. [0] https://google.github.io/flatbuffers/flatbuffers_grpc_guide_use_cpp.html https://google.github.io/flatbuffers/flatbuffers_grpc_guide_...
- Aardappel 6y ago
  gRPC FlatBuffers is supported in quite a few languages besides C++, Java, Go, Python, Swift, off the top of my head..
liuliu 6y ago
We use Flexbuffer to serialize aribitary Objective-C objects through reflection (rather than NSCoding). It is faster and stable for us in a few years actually (we implemented that in early 2019).

We use FlatBuffers (the parent project) in our code @ FS... that means it has to work in C++, Rust, Java, and TypeScript. It's mostly the schema processing that requires a C++ compiler to make it work. It's a pretty stellar cross-platform serialization toolkit and the zero-copy support for reading is no joke.

maximilianburke 6y ago
We've been using it across multiple languages too as the data serialization format between server and (web) client. It's fantastic.

jchook 6y ago

AFAIK some languages can use C++ fairly easily, including D and Rust

kccqzy 6y ago
These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features. Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises. And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises. The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.
- pjmlp 6y ago
  Wrong, D has support for C++ FFI. https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
  - kccqzy 6y ago
    It supports neither templates nor ADL, the two of my examples. In fact the doc says, > Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. It then goes on to describe the pragmatic approach that doesn't allow full compatibility: > D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem: > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Can you see how limited this subset of interoperable API is?
    - pjmlp 6y ago
      I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.
    - gpderetta 6y ago
      > matching C++ name mangling conventions > matching C++ function calling conventions > matching C++ virtual function table layout for single inheritance Basically COM? Which is not surprising as it was designed as an OO native FFI.
      - pjmlp 6y ago
        And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.

DethNinja 6y ago

It is basically a code template generator. It is written in C++ but it can generate code for other languages. It is one of the best serialisation methods currently available.

tkzed49 6y ago

FlatBuffers libraries are implemented in a big list of languages, as you can see on the website. FlexBuffers is not implemented in all the same languages yet, at least in the official Google repo. Otherwise, it is very relevant in any language--it's a binary serialization format.

mzaks 6y ago
If you need a language support for FlexBuffers please create an issue on GitHub repo. I ported it already to Swift, C#, Dart, Python, JS (is in review). If I am familiar with the language you need, it will take me just a couple of days to port it.

Aardappel 6y ago

FlexBuffers currently is implemented in C++, Java, Rust, Dart, Swift, (and JS under review).

mzaks 6y ago
You forgot Python and C# :). Plus a Unity3D specific version, which is battle tested in a game with more than half a million downloads ;).

_nhynes 6y ago

The codegen for flatbuffers is fairly extensive, but C++ is still the blessed language for gRPC, however [0]. [0] https://google.github.io/flatbuffers/flatbuffers_grpc_guide_use_cpp.html https://google.github.io/flatbuffers/flatbuffers_grpc_guide_...

Aardappel 6y ago
gRPC FlatBuffers is supported in quite a few languages besides C++, Java, Go, Python, Swift, off the top of my head..

liuliu 6y ago

We use Flexbuffer to serialize aribitary Objective-C objects through reflection (rather than NSCoding). It is faster and stable for us in a few years actually (we implemented that in early 2019).