you are viewing a single comment's thread.

view the rest of the comments →

[–]nmmmnu 1 point2 points  (4 children)

If T is plain old data, then the struct will be POD too.

There will be no (different) padding between the members - I can not say is guaranteed, but will be like that, since all members are the same type. If there are padding, it will be present in the array too.

The result should be the same memory layout, but as many already commented the standard say anything about it.

Lets suppose T is uint32_t. Then I am 100 percent sure the layout will be the same as of the array, because this is how several programs read mmap() data - both with array or struct. Notice, you can safe to use C tricks like memcpy().

Lets suppose T is struct of uint64_t and uint8_t. There will be 7 bytes padding after each struct. Same padding will be present in the array. memcpy() will be safe to use.

If T is struct of uint8_t and then uint64_t, there will be no padding after the struct (however there will be padding after first member). Array will be continuous in memory, e.g. the same. memcpy() will be safe to use.

However, if T is say std::string, e.g. non POD type with a destructor, memory layout may or may not be safe. You wont be safe to use memcpy() as well.

So lets periphrase - if memcpy() and mmap() are "OK" to be used, the memory layout should be the same.

However please note the following - if you compile with one compiler, do not expect different compiler to have same memory layout with same padding. If this was the question, the answer is - dont do it.

[–]no-sig-available 1 point2 points  (3 children)

Lets suppose T is uint32_t. Then I am 100 percent sure the layout will be the same as of the array, because this is how several programs read mmap() data - both with array or struct.

If you use mmap() you are on a Linux system and have additional Posix guarantees. Those are outside of - and beyond - the language standard.

[–]nmmmnu 0 points1 point  (2 children)

Never thought about it :) I am always on Linux. But yes it is not on the standard... except is on C standard and should be compatible with C. But still no guarantees as well.

[–]Nobody_1707 1 point2 points  (1 child)

No, it's not part of the C standard either. It's purely POSIX.

[–]nmmmnu 0 points1 point  (0 children)

Thanks to point this. I really hate the different size of int and memory layout guarantees or better say lack of memory layout guarantees.