* Combine vector_like_traits::{insert,reserve}
and explain semantics better. This should make it more clear what
implementers need to do when implementing the vector_like_traits
concept.
* Update std::unordered_set vector_like_traits impl
* Extend flat_buffer to support unordered_set (de)serialize
Extend flat_buffer to support unordered_set (de)serialize
Description
Extend flat_buffer to support unordered_set (de)serialize
Testing
Added unit test in flat_buffers.cpp to validate the functionality:
1. Empty unordered_set (de)serialize
1. Non-Empty unordered_set (de)serialize
* Fix a benign bug turned up by _GLIBCXX_DEBUG
Just calling std::vector::operator[] with an out of bounds index at all
is technically undefined behavior.
* Fix compilation issue with _GLIBCXX_DEBUG
For some reason std::max with an initializer list isn't constexpr with
_GLIBCXX_DEBUG set
Apparently clang11 warns if you pass uninitialized memory to a function
accepting a const reference. Seems fair. This change doesn't actually
fix any bugs, but it silences the warning.
If a flatbuffers message contains many empty strings, its serialized
size is currently unnecessarily large. Point all relative offsets for
empty strings/vectors to the same memory, saving 4 bytes per extra empty
string/vector.
We recently witnessed (using tsan) the main thread exiting without first
joining the network thread, and this caused data races and
heap-use-after-free's
Now the lifetime of these globals will be tied to the network thread
itself (and I guess every thread, but the one that actually uses memory
will be owned by the network thread.)
Writing a value which is not 0 or 1 to the underlying memory of a bool
is undefined behavior. Conformant flatbuffers implementations must
accept bytes that are not 0 or 1 as booleans [1]. (Conformant
implementations are only allowed to write the byte 0 or 1 as a boolean
[1])
So this protects us from undefined behavior if we ever read a
flatbuffers message written by an almost-conformant implementation.
[1]: https://github.com/dvidelabs/flatcc/blob/master/doc/binary-format.md#boolean
The main idea here is that we now have a context for
serialization and deserialization. This can be used
to access the protocolVersion.
The context still needs to be exposed to the
deserailization traits
