🚀 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.

malloc is required to return storage suitably aligned for any
object of that size. In order for the technique above not to
work, it would have to be the case that some smaller object could
always require stricter alignment than any larger object. Since
a larger object might contain the smaller as a subobject, I think
this would always lead to a contradiction. It seems to me you would
have to work hard to make such a perverse implementation even if
it *could* somehow conform to the standard.

>Is there a constraint on
>where in an object image the "this" pointer points?

No.

>Or is it that the low address of a memory block
>is supposed to be passed when this form of new
>is used (my memory is fuzzy on this)?  I had the
>impression that the "this" pointer could have an
>environment specific (or even variable between classes)
>relationship to the object instance.

Some implementations have "this" pointing to a location other
than the starting address of the object. For example,
there is some advantage in having the vtable pointer at a
negative offset, although there are disadvantages too.

If "this" does not point at the starting address, the compiler
has to take care to do pointer adjustments in the face of
conversion to and from void*, and with the use of placement new.

That is, the above code has some conversions to and from void*,
and the compiler would adjust the pointer value correspondingly.
--
Steve Clamage, stephen.clamage@eng.sun.com

---
[ 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. ]