Re: [boost] Subobjects placement.

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

On 09/17/2005 10:55 AM, Adam Badura wrote:
[snip]
>     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:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/indexed_types/composite_product.hpp?rev=1.1&view=auto

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:

   project<x>

Please see the tests at:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/indexed_types/test/composite_product_test.cpp?rev=1.1&view=auto

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: