On 1/23/19 9:12 AM, Niall Douglas via Boost-users wrote:
C++ make NO guarantee that in-memory organization of data structures will match between different architectures, and there is nothing Boost can do to make those structures match between architectures. It's even stronger than that: the C++ standard makes no guarantee that in-memory representation of storage does not change between program executions, let alone between different compilers or architectures. To use mapped memory at all outside a single program execution is pure undefined behaviour. You are literally on your own wrt the standard.
(I have a proposal in the works for WG21 SG12 which will propose how to add support for shared and paged memory to C and C++, but even it specifically excludes the ability to use storage by programs other than the program which constructed the objects. And even that, the standard requiring that the same program binary always uses the same in-memory representation, will be very, very controversial e.g. imagine JITed or translated C++ for example)
Niall
While the standard doesn't explicitly define it, at least a POD which doesn't contain pointers generally should maintain representation within the same executable, even if run multiple times. The offsetof each of the members is defined to be a compile time constant, so unless the compiler uses some from of whole-program optimization to invoke the as-if rule for structure layout, it can't be a run-time decision. The representation of each of the fundamental members needs to be documented, so unless the implementation documents a possible change of representation at executable time, that will be consistent. At a higher level, platform ABIs will generally define the representation of structures, so that provides a stronger promise (and I suspect all the implementations that Boost supports define themselves to conforming to some platform ABI). This is needed for the linking together of independently compiled modules. Pointers will be an issue, as there is generally no assurance that the program will run is the same memory space run to run (except on many embedded platforms) so they would need to be fixed, and in general there is no standard way to do this. Non-PODs also have this issue, in part because they may include as part of their representation pointers to related information (like the v-table for virtual functions as an example). -- Richard Damon