Does the standard make any guarantee that adding a constructor does not change the size?

Question

Lets say I have a class

struct Foo {
    uint32_t x;
    uint32_t y;
};

does the C++ standard make any mention whether sizeof(Foo) should be the same as sizeof(Bar) if Bar just adds a constructor ?

struct Bar {
    uint32_t x;
    uint32_t y;
    Bar(uint32_t a = 1,uint32_t b = 2) : x(a),y(b) {}
};

The reason why I am asking is that Foo is send across network as a void* and I cannot change its size, but if possible I would like to add a constructor.

I found some related: here and here, but there the answers focus mainly on virtuals changing the size and I was looking for something more definite than "[...] all implementations I know of [...]".

PS: To avoid misunderstanding... I am not asking how to constsruct a Foo and then send it as a void* nor am I asking for a workaround to make sure the size does not change, but I am really just curious, whether the standard says anything about sizeof in that specific case.

Answer 1

C++ 98 only guarantees layout for “plain old data” objects and those don't permit constructors.

C++ 11 introduces “standard layout types”, which still guarantee layout, but do permit constructors and methods to be added (and permits non-virtual bases to be added with some exceptions for empty classes and duplicates).

Answer 2

Actually, the only thing that influences the layout is the data contained in an object -- with one important exception, coming to that later. If you add any functions (and constructors in reality are nothing more than some kind of static function only with special syntax), you do not influence the layout of the class.

If you have a virtual class (a function with at least one virtual function, including a virtual destructor), your class will contain an entry to a vtable (this is not enforced by the standard, but that's the standard way how polymorphism is implemented), but this is just a pointer to some specific memory location elsewhere. The vtable itself will be modified, if you add more virtual functions, but without any influence on the layout of your data containers (which your class instances actually are).

Now the exception mentioned above: If you add a virtual function to a class (or make an existing one virtual, including the destructor) while the class did not have any virtual functions before (i. e. no own virtual functions and no inherited ones!), then a vtable will be newly added and then the data layout does change! (Analogously, the vtable pointer is removed if you make all functions non-virtual - including all inherited ones).

Guaranteed by the standard?

Edit:

From C++ standard, section 4.5 The C++ object model (§ 1):

[...] Note: A function is not an object, regardless of whether or not it occupies storage in the way that objects do. — end note [...]

Next is deduction (of mine): A function (note: not differentiated if free or member one) is not an object, thus cannot be a subobject, thus is not part of the data of an object.

Further (same §):

An object has a type (6.9). Some objects are polymorphic (13.3); the implementation generates information associated with each such object that makes it possible to determine that object’s type during program execution.

(That is the vtables! - note that it is not explicit about how they are implemented, does not even enforce them at all, if a compiler vendor finds some alternative, it is free to use it...).

For other objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 8) used to access them.

Well, couldn't find any hints (so far), if or how functions influence the layout of a class, not flying over the standard as a whole, not (with special attendance) in chapters 8 (as referenced above) or 12 "Classes" (especially 12.2 "Class members").

Seems as this is not explicitly specified (won't hold my hand into fire for not having overseen, though...). Maybe it is valid to deduce this already from functions not being objects solely...

Standard layout classes, as referenced by Jan Husec, provide further guarantees on layout, such as no reordering of members (which is allowed for members of different accessibility), alignment conditions, ...

From those conditions for being a SLC, I deduce that for these, at least, the guarantee applies, as all that is referenced for being layout compatible is the data members, no mention of (non-static member) functions (other than no virtual ones being allowed...).

Answer 3

As explained by other answers the layout can change in case a virtual destructor is added.

If your destructor is not virtual you can go ahead and add. But say you need a virtual destructor, you can wrap the struct in another struct and place the destructor there.

Make sure the fields that you want to modify are accessible to the wrapper class. A friend relation should be good enough.

Although all your inheritance will be through the wrapper. The inner struct is just to maintain the layout so you can send it over the network.