Re: A question about sizeof, offsetof, new and objects in contiguous
regions. (Was Re: technical correctness 2)
On Jan 7, 5:09 pm, LR <lr...@superlink.net> wrote:
James Kanze wrote:
On Jan 7, 5:59 am, LR <lr...@superlink.net> wrote:
Alf P. Steinbach /Usenet wrote:
It so happened that this vagueness (allowing non-contiguous regions)
was done deliberately in order to support multiple virtual
inheritance, but that at least some committee members saw it as not
only necessary for virtual inheritance, but also allowing
implementations that scatter parts of objects all around in memory.
Thus, the wording in the standard does not say right out that it's in
support of virtual inheritance. The standard intentionally leaves
the door open for what we'd now regard as "perverse" implementations.
:-)
Would I be correct in inferring that non-contiguous classes are no
longer regarded as necessary? If not, does the current draft still
support a requirement for this?
All of the implementations I know do insert extra bytes here and
there in the object; in this sense, they all use non-contiguous
memory.
Yes, but I don't think that padding or putting things like vtable
pointers in an object is what was meant here.
I don't really think so either, but... it's either padding, or
parts of some other object. And I don't think they really want
to allow parts of some other object.
Or perhaps it is meant to refer to something that are implicitly
created. If instead of a vptr, you use a map, with the address
of the object as a key, I suppose you could think of the map
entry as "part of the object".
But to tell the truth, I'm just guessing about what they might
have meant.
The real question is: what did the authors of the standard mean
by "non-contiguous"? That parts of other objects are somehow
interspaced in the memory of the object. I don't think that
this could be made to work; how would operator new work, for
example. That not all of the memory encompassed in sizeof is
used by the object. That's the case, even in C, because padding
is not only allowed, but also necessary.
I suspect that actual non-contiguous objects could be made to work. But
it would require some jumping through some interesting, for which read:
probably pointless, hoops.
However,
From n3126
1.8, from 5 ... An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage. ...
Tha text, of course, isn't present in the current standard. But
it certainly does imply that the text about non-contiguous
didn't mean padding, since even trivially copyable objects can
have padding.
3.9 Types
2 For any object (other than a base-class subobject) of trivially
copyable type T, whether or not the object holds a valid value of type
T, the underlying bytes making up the object can be copied into an array
of char or unsigned char [which a footnote says can be done using for
example std::memcpy or std::memmove]. If the content of the array of
char or unsigned char is copied back into the object, the object shall
subsequently hold its original value. ...
And since arrays have to be contiguous per 8.3.4,1 ... An
object of array type contains a contiguously allocated non-empty set of
N subobjects of type T. ...
I think this requires a contiguous region for some objects. But I don't
think it addresses the issue of multiple virtual inheritance.
I'm sure that some objects have to be contiguous. I can't see
any possibility of a POD not being contiguous.
--
James Kanze