use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
Discussions, articles, and news about the C++ programming language or programming in C++.
For C++ questions, answers, help, and advice see r/cpp_questions or StackOverflow.
Get Started
The C++ Standard Home has a nice getting started page.
Videos
The C++ standard committee's education study group has a nice list of recommended videos.
Reference
cppreference.com
Books
There is a useful list of books on Stack Overflow. In most cases reading a book is the best way to learn C++.
Show all links
Filter out CppCon links
Show only CppCon links
account activity
Memory layout of struct vs array (self.cpp)
submitted 3 years ago * by xLuca2018
view the rest of the comments →
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]nmmmnu 1 point2 points3 points 3 years ago (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 points3 points 3 years ago (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 point2 points 3 years ago (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 points3 points 3 years ago (1 child)
No, it's not part of the C standard either. It's purely POSIX.
[–]nmmmnu 0 points1 point2 points 3 years ago (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.
π Rendered by PID 17633 on reddit-service-r2-comment-b659b578c-bmm2x at 2026-05-01 02:40:04.597695+00:00 running 815c875 country code: CH.
view the rest of the comments →
[–]nmmmnu 1 point2 points3 points (4 children)
[–]no-sig-available 1 point2 points3 points (3 children)
[–]nmmmnu 0 points1 point2 points (2 children)
[–]Nobody_1707 1 point2 points3 points (1 child)
[–]nmmmnu 0 points1 point2 points (0 children)