🚀 go-pugleaf

Dick Menninger <Dick.Menninger@daytonoh.attgis.com> writes:

>> ==========Fergus Henderson, 11/21/95==========
> 
>> If you changed the line
>>      D1 d1 (7);
>> to
>>      D1 &d1 = *(D1 *) malloc(sizeof(D1) + sizeof(D2));
>>      new (&d1) D1 (7);
> 
>> then the storage would be definitely large enough to hold either
>> a D1 or a D2 and would be correctly aligned to hold any object,
>> so this problem wouldn't arise.
>
>Although it would be overkill as far as allocating
>enough storage, how this insures correct alignment
>less clear, at least to me.  Is there a constraint on
>where in an object image the "this" pointer points?

The draft says that the value of the `this' pointer is the address of
the object (9.4.2 [class.this]), that an object is composed of a
contiguous sequence of bytes (1.6 [intro.object]), and that each byte
of storage has a unique address (1.5 [intro.memory]). However, as
far as I can tell it doesn't define what it means by the address of an object.
So I suppose it would be reasonable for an implementation to define
the address of an object of a certain type to be the address of the
N-th byte of storage for that object for some N != 0.

>I had the
>impression that the "this" pointer could have an
>environment specific (or even variable between classes)
>relationship to the object instance.  Certainly some
>hardware architectures would favor a centrist "this"
>pointer for some sizes of objects (small signed offsets
>imbedded in instructions dereferencing "this").

My reading of the draft confirms your impression.

Nevertheless, the code does ensure correct alignment.
The reason is that there is an implicit conversion to `void *'
in the call to placement new.  This implicit conversion is defined
to return the address of the start of the storage of the object,
i.e. the address of the first byte (4.10/2 [conv.ptr]).

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
I will have little or no net access from Nov 30 until Dec 25.
Please email me a copy of any follow-ups.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]