3

In C++ I presume the C++ standard has nothing to do with how data members are arranged within a class, in terms of memory layout? Would I be right in thinking this is down to the compiler in question?

I'm very interested in learning how objects and other C++ entities (structs etc) are represented in physical memory (I know things like lists are node to node and arrays are continuous memory- but all the other aspects to the language).

EDIT: Would learning x86 assembler help with this and understanding C++ better?

user997112
  • 29,025
  • 43
  • 182
  • 361
  • probably shortest answer to your question is fields of struct or classes are represented as contiguous in memory. – taufique Oct 14 '12 at 18:07

2 Answers2

6

The C++ standard does specify a few things, but far from everything.

The main rules are these:

  • objects in an array are laid out contiguously, with no padding between them.
  • class member objects not separated by an access specifier (public:/private:/protected:) are laid out in memory in the order in which they're declared, but there may be an unspecified amount of padding between member objects.
  • for certain types (standard-layout structs, in standardese terminology), the first base class, or if none exists, the first member, is laid out at the same address that the class itself.

There are a few more bits and pieces specified by the standard, but on the whole, the remaining details are really down to the compiler.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • I have a small question, if I have a class with, say 10 member functions. Would it be known that accessing the 10th-declared function would be slower than the 1st? Is this down to the order they are declared in the header file? – user997112 Oct 14 '12 at 18:06
  • The C++ standard doesn't really say anything about that, but in any sane compiler, it makes no difference. Member functions are not represented in the object at all. At compile-time, the compiler determines which function to call, so it doesn't need to look inside the object at all at runtime. – jalf Oct 14 '12 at 18:11
  • 1
    @NicolBolas: source, please? 9.2:12 specifies point 2, at least, and applies to any "non-union class". Perhaps you should check the standard before correcting and downvoting others? If you're unsure, it is actually allowed to post a comment asking for verification before you downvote. For point 3, you may be right, and I'll fix my answer to reflect that – jalf Oct 14 '12 at 18:24
  • @jalf +1 helping should still be rewarded – Oliver Oct 14 '12 at 18:38
  • 1
    @OliverStutz: well, techincally, it's not much of a help if it provides incorrect information, so I appreciate being corrected. ;) But before downvoting, I think it's fair to ask that you actually ensure that you're correct, and that the person you're downvoting is not – jalf Oct 14 '12 at 18:39
  • By the way, I finally found it in the standard: @NicolBolas was correct on point 3, as specified by 9.2:18. I've updated the answer with this information. On point 2, my answer was, as far as I can see, correct. And I'd appreciate a citation if he has information to the contrary – jalf Oct 14 '12 at 18:52
  • @jalf: Fair enough. Since you can't rely on the layout for non-standard layout types, I assumed the spec defined them as unspecified. – Nicol Bolas Oct 14 '12 at 19:00
  • @NicolBolas: technically you can't rely on the layout of standard-layout types either. Things like padding are still unspecified. But yeah, the layout of non-standard-layout types is even *less* reliable :) – jalf Oct 14 '12 at 21:17
  • @jalf: "Rely on" as in "know that any two types with the equivalent layout are compatible". Not as in "know the byte offsets of"; that's what `offsetof` is for. – Nicol Bolas Oct 14 '12 at 22:13
2

Yes, the standard doesn't say how the objects are to be represented in memory. To get an idea how normall C++ objects are represented read this book: inside C++ object model.

Asha
  • 11,002
  • 6
  • 44
  • 66
  • 1
    The standard does specify *some* things about how objects are to be represented in memory. But you're right that there's also a lot it doesn't specify – jalf Oct 14 '12 at 18:42