Closed AdelKS closed 1 year ago
With cista, I try to achieve a serialization format that is platform/compiler/standard-library independent. This means that I cannot use std::vector
, std::array
, etc. because I cannot be 100% sure about their memory layout (which is important for serialization, since we write their memory layout to disk/network). If they differ between standard library implementations, this would make serialized data incompatible between platforms which is undesirable. If the standard guarantees the exact memory layout for std::array
, it would be possible to make an exception for this container.
Thanks for your input !
Okay I think I understand better what's at stake here:
For all standard layout, non-polymorphic aggregate types you do not have to write a custom function
Even though std::array can indeed be serialized as any custom type, we are not sure it's doesn't have extra members across STL implementations. Found a discussion here and indeed, sizeof(std::array < T, N>) == sizeof(T) * N
is a necessary and sufficient condition to have cista::array
to be binary compatible with std::array
.
sizeof(std::array < T, N>) == sizeof(T) * N
This condition is not sufficient. You could reorder elements arbitrarily (for reads as well as writes). So for example STD lib A might access element i
at position i
and B might access element i
at N-i-1
(reversed order) and your condition is still true. Serializing data with std::array<T>
from STD lib A and deserializing with STD lib B will yield reversed results. Of course, this is very theoretical and there's no good reason to do this. On the other side, maintaining a custom cista::array
implementation has a low overhead.
I understand your point, strictly speaking. My sentence needs to be updated to "the only extra necessary and sufficient condition is sizeof(std::array < T, N>) == sizeof(T) * N
.
Now, for the order of the elements, the standard mandates them to be stored in the intuitive way because its iterator
satisfy the LegacyRandomAccessIterator (since C++17) which abides by
(a + n) is equivalent to (std::addressof(*a) + n).
Makes sense. Thank you! I changed cista::array
to be a alias of std::array
.
Amazing, thanks for your awesome work !
Hello!
By looking closer at the code, it appears to me that built-in support for type hashing and serializing
std::array
could be possible ? This has the benefit to avoid migrating downstream code bases that usestd::array
. Mirroring the code that already exists forcista::array
in my tests seems to workAlso, the code of
cista::array
seems to be standard enough so thatstd::array
could replace it ?I am probably missing some important piece of information that made it not possible to begin with.
Thanks for your time !
Adel