Boost logo

Boost :

From: Larry Evans (cppljevans_at_[hidden])
Date: 2005-09-17 13:31:33

On 09/17/2005 10:55 AM, Adam Badura wrote:
> I have a question on placement of subobjects in a class (or struct -
> what I know of standard this will be the same). In S. Lippman's "Inside the
> C++ Object Model" I found that standard only guaranties that subobjects are
> placed in specific sequence (not to get inside details) but there is no
> guarante that compiler doesn't place some additional objects (for his
> internal use) at the begining of object in between subobjects or at the end.
> (I looked also in Stroustrup's "The C++ Programming Language" and "The
> Design and Evolution of C++" but have found nothing - but I wasn't looking
> that hard).
> So, if I have a class:
> class point2d {
> public:
> double x;
> double y;
> };
> and make an object of it
> point2d pp = new point2d;
> than ther is no guaranty that
> reinterpret_cast<double*>(pp) will give me addres of point2d::x.
> Normally it no difference but if I want to write a class that for
> example warps comunication with some hardware than I have to be SURE how
> data would be allocated in memory becouse it must be correct acording to
> this hardware specification (if hardware keeps in memory a buffer with a
> char [for command] and int [for argument]) than I my class members must be
> so placed in this mamory).
> Another example is color. If I want to write a class that warps color
> managemant I want it to be more useable I have to be sure that class
> class color_argb {
> public:
> unsigned char a;
> unsigned char r;
> unsigned char g;
> unsigned char b;
> };
> will use ONLY 4 chars (bytes) and ther will not be any other data placed in
> memory. If one would be added (for example virtual table pointer) than
> color_argb could not be used to warp data recevied from and given to many
> libraries and hardware.
> I suppose that if I don't use any polimorphism (as virtual functions),
> inherit only in single line and without virtual base classes and don't use
> any runtime support that compiler doesn't have any reason to place
> additional data (but still can use more than 4 bytes to align data for
> example). But what I know it still MAY do this and relaying on that that it
> does not have to is dangarous.
> So how is it?
You could specify the actual layout, as done here:

however, this would require you to define an enumeration
for each class. For example for the point2d, there would be:

   enum point2d_fields
   { x
   , y

and then, instead of your point2d struct, there would be a
composite_product with member function:


Please see the tests at:

for clarification. As shown in composite_product.hpp, the memory is
explicitly laid out by the factor template; hence, you know exactly
where each subobject is located.

I've worked on a type of policy_composite allowing different
methods for constructing the composite, amoung other
features. However, so far, it hasn't prompted much interest:

Boost list run by bdawes at, gregod at, cpdaniel at, john at