1

Is it a universal rule that C++ stores variables in memory in the same order as are in the source? So if I define a lot of 4-byte member variables consecutively with different privacy in 32-bit ordering and 32-bit architecture compiler puts them to consecutive words in memory?

Botje
  • 26,269
  • 3
  • 31
  • 41
RobertSzili
  • 162
  • 7
  • 1
    No. That's an implementation detail. Trying to leverage that implementation detail in C++ itself will likely invoke *undefined behavior*. A `struct` has some layout guarantees, an *array* has some layout guarantees, but not local variables or parameters. – Eljay Oct 06 '20 at 14:58
  • 1
    I can't think of any reason the compiler *wouldn't* store consecutive variables in consecutive memory locations ... but there's no rule that says a compiler *MUST* do this. There is no such "universal rule". [access specifiers](https://en.cppreference.com/w/cpp/language/access) shouldn't play any role in memory layout. And don't forget about [byte padding](https://stackoverflow.com/a/5398498/421195) – paulsm4 Oct 06 '20 at 15:00
  • 1
    Local variables do not even need to exist in memory, they could be optimized away or only exits in the registers of the CPU. Also, member variables do not need to exist in memory, a compiler could - if it does not change the outcome of the application (as if rule) - even optimize a struct and its members away. – t.niese Oct 06 '20 at 15:02
  • 1
    @t.niese Only if the ABI permits it. Your type needs to be common across all systems sharing that ABI, so you can't just alter it on one system because that particular program using the type doesn't use one or more of its members. It _can_ skip baking the use of the type into the executable though ofc – Asteroids With Wings Oct 06 '20 at 15:03
  • 1
    @paulsm4 Reasons include: minimal required alignments, whether something is const, static or local and whether or not they are assigned to 0 or not at start. – Elijan9 Oct 06 '20 at 15:06
  • 1
    Asteroids With Wings: partially. I want a guarantee about the ordering is not touched by the compilation/optimization, and independent of private/public/... flags, every kind of standards, and tricking. – RobertSzili Oct 06 '20 at 15:15
  • @RobertSzili Why do you think that you need such guarantee? – eerorika Oct 06 '20 at 15:25
  • 1
    @AsteroidsWithWings I didn't say anything else. But if an instance of the type is only used in a way that the compiler has full control over that instance and can guarantee that the observable behavior does not change it could e.g. remove unused member variables [Does an unused member variable take up memory?](https://stackoverflow.com/questions/55060820). If it can't guarantee it e.g. due to interoperability with linked libraries (if the instance is passed there), calls like `memcopy`, usage of `volatile` , … it can for sure not do that. – t.niese Oct 06 '20 at 16:49

2 Answers2

2

Is it a universal rule that C++ stores variables in memory in the same order as are in the source?

No. Such rule does not exist in C++ for variables in general.

However, member variables with same access control are stored in the same order as declared, yes. The order between members with different access control is unspecified.

Consecutive layout of member variables in memory?

There is no guarantee of the members being in consecutive memory. There may be unused padding bytes between the members, which may be required for example to satisfy the alignment requirement of the members.

If we add additional restrictions of same access control and that the members have same alignment, then effectively they are likely going to be in consecutive memory in practice, although that is not guaranteed by the language.

eerorika
  • 232,697
  • 12
  • 197
  • 326
0

If you define struct/class or array, your requested memory will be consecutive. If your idea from member variable is class/struct property, so I can say yes, it will be stored wrapped in memory(so consecutively). Every time that you construct an object, all properties of that object will be defined wrapped with the order that relative class/struct defined.

SpongeBob
  • 383
  • 3
  • 16