Re: Constructing Derived in shell of Base <shudder>

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Sun, 18 Jul 2010 08:24:53 -0700 (PDT)

Message-ID:

<ecd3eadd-fae2-4e09-908f-1808d1a2aebe@k19g2000yqc.googlegroups.com>

On Jul 16, 6:16 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:

On Jul 16, 6:36 am, James Kanze <james.ka...@gmail.com> wrote:

On Jul 15, 11:05 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:

On Jul 15, 6:27 am, =D6=F6 Tiib <oot...@hot.ee> wrote:

[...]

To reiterate my question, I don't understand how an object
could exist in non-contiguous storage, but still be
creatable with placement new.

An object doesn't have to always have the same
representation. When you create an object with placement
new, you are creating an object of the most derived type.
If we abstract padding bytes (considering them part of the
object), then an object must consist of a contiguous block
of storage. Once we consider sub-objects (which are objects
too), the issue is less clear. Consider:

    struct Base { virtual ~Base(){} int takesSpace; };
    struct Derived : virtual Base { int takesSpace; };
    struct Further : Derived { int takesSpace; };

If you do sizeof(Derived), you'll get a size which
represents the size of a Derived when it is the most derived
class. If you fiddle around with the addresses in the
Derived base class of Further, however, there's a good
chance that the difference between some of those addresses
if greater than sizeof(Derived)---in some (most?)
implementations, Further::takesSpace, which is not part of
the Derived object, will be placed between Base::takesSpace
and Derived::takesSpace, both part of the derived object.
(If this example doesn't show it, it should be easier to
come up with more complicated ones that do.)

Oh of course, with virtual inheritance. Is that the point of
the allowance, (not the extent, but the point) to allow
"non-contiguous storage" of virtual base classes? That makes
perfect sense. Still, am I right to think it would be a
perverse implementation which would have complete objects
exist in not-contiguous storage of sizeof(the_type)?

For a sufficiently loose definition of the terms involved. I
think you could find enough constraints in the standard that
would make an implementation which somehow put parts of some
other complete object in the middle of an object. But given
something like:

struct S { char c; double d; }:

every implementation I know will have unused memory between c
and d, which is not part of the value representation of an S.
The sizeof operator has to take this memory into account, but
I'm not sure you can consider it part of the object. (Note, for
example, that given:
static S anS;
you've no guarantees about the value of this memory. The
"object" has been zero initialized, but the standard doesn't say
anything about the extra memory separating parts of the object.)

--
James Kanze