Depending on compiler switches and/or certain pragma definitions, padding for alignment can be modified or disabled.

The C++ language specification allows compiler writers to add abitrary internal data to a class instance, and this data can be either before or after the regular class data in memory. Some compilers do this. Almost all compilers do this if Run Time Type Information (RTTI) is enabled at compiler time.

More importantly, any future compiler can increase the size of class instances in any future compiler without violating the language specification.

The C++ language specification prohibits adding any data to a structure that contains only non-virtual members. A pointer to a vtable will be added if the struct contains virtual members.

A structure with ‘no’ virtual members is guaranteed to be the size of it’s data elements plus an padding bytes necessary to aligh data members for the current memory alignment.

Thus, unlike a class, the address of a structure with no virtual members is guaranteed to be the same as the address of the first data element in the structure. As mentioned earlier by MG, the struct exists in C++ to allow compatibility with C code.

However, a struct can be occasionally preferable in C++ code. AI a C++ container class with thousands of instances, as adding padding data ‘can’ greatly increase memory utilization. This is because some memory allocators, in order to reduce memory fragmentation, only allocate sizes that are powers of two up to some maximum power of two. Thus, adding a single byte to a size that is already a small power of two can double memory utilization.

Thanks for the great article!

I’m still curious about the flagging mechanism you mentioned in the last paragraph.
For this mechanism to work, I guess we need the “observer” component to continuously pool this local flag and execute some action upon flag change? So, it is only possible to implemented in a multi-threaded app?

Missing:

#include

:-)