C++ object model question - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

C++ object model question

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Emil Dotchevski
Guest

Posted: Sat Jan 31, 2004 1:55 am Post subject: C++ object model question

According to 1.8.5: "... An object of POD type (3.9) shall occupy contiguous bytes of storage." I guess it implies that non-PODs may occupy non-contiguous bytes of storage. I wonder how would that work? Would the implementation call the operator new function multiple times? What would sizeof(T) return? Assuming such an implementation can be conforming, what would the benefit be? What reasons could they have for not using contiguous storage for non-PODs? --Emil [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow
Guest

Posted: Sat Jan 31, 2004 6:22 pm Post subject: Re: C++ object model question

In message <5059663b.0401301319.1635f655 (AT) posting (DOT) google.com>, Emil
Dotchevski <emild (AT) collectivestudios (DOT) com> writes

Quote:

According to 1.8.5:

"... An object of POD type (3.9) shall occupy contiguous bytes of
storage."

I guess it implies that non-PODs may occupy non-contiguous bytes of
storage. I wonder how would that work? Would the implementation call
the operator new function multiple times? What would sizeof(T) return?

struct A {int i;};

struct B: virtual A {int j;};

struct C: virtual A {int k;};

struct D: virtual A {int m;};

struct E: B, C, D {};

Now not all the subobjects of E can be contiguous.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andrew Koenig
Guest

Posted: Sun Feb 01, 2004 3:31 am Post subject: Re: C++ object model question

Quote:

I guess it implies that non-PODs may occupy non-contiguous bytes of
storage. I wonder how would that work? Would the implementation call
the operator new function multiple times? What would sizeof(T) return?

Consider classes A, B, C, and then define:

struct D: virtual A, B { };
struct E: virtual B, C { };
struct F: virtual A, C { };
struct X: virtual D, virtual E, virtual F { };

Every object of type X has a D subobject, an E subobject, and an F
subobject.

If you think about it, you will see that there is no way of laying out
memory so that the D, E, and F subobjects of an X object are all contiguous.
However, there is no problem defining sizeof(D), sizeof(E), and sizeof(F),
because you can construct objects of type D, E, or F in contiguous memory.
It's just that you can't be assured that every object of these types is
contiguous.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gennaro Prota
Guest

Posted: Sun Feb 01, 2004 3:25 pm Post subject: Re: C++ object model question

On 31 Jan 2004 22:31:28 -0500, "Andrew Koenig" <ark (AT) acm (DOT) org> wrote:

Quote:

But is it correct to say that, e.g., the D subobject in X "has type
D"? We went thorough this issue a while ago, without coming to a
definite answer. See for instance the following post (the part below
"sketch"):

http://google.com/groups?selm=k4eriugdf99ibvvljv86t8f367iv89n4ln%404ax.com

Genny.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andrew Koenig
Guest

Posted: Sun Feb 01, 2004 8:09 pm Post subject: Re: C++ object model question

Quote:

But is it correct to say that, e.g., the D subobject in X "has type
D"?

What other type could it have? Suppose, for example, we have class X
derived from D, and we then do this:

template<class T> void foo(T t) { /* ... */ }

X x;
foo(static_cast<D&>(x));

Inside the instantiation of foo that results, what type is T if not D? For
that matter:

void bar(D& d) { /* ... */ }

X x;
foo(x);

Inside bar, isn't d a reference to D? If not, what is it? And if it is,
isn't d a reference to an object of type D that occupies discontiguous
storage?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Martijn Lievaart
Guest

Posted: Mon Feb 02, 2004 7:43 pm Post subject: Re: C++ object model question

On Fri, 30 Jan 2004 20:55:23 -0500, Emil Dotchevski wrote:

Quote:

Others already answered the first question, I just want to point out that
these objects which use virtual inheritance will still use one blob of
contigouous memory. It's just that some subobjects are splattered over
this area. So operator new is called only once.

HTH,
M4

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

ta0kira
Guest

Posted: Tue Feb 03, 2004 2:28 pm Post subject: Re: C++ object model question

Quote:

What other type could it have? Suppose, for example, we have class X
derived from D, and we then do this:

template<class T> void foo(T t) { /* ... */ }

X x;
foo(static_cast<D&>(x));

t would be an instance of D that was created by D(const D&). See below...

Quote:

Inside the instantiation of foo that results, what type is T if not D? For
that matter:

void bar(D& d) { /* ... */ }

X x;
foo(x);

Inside bar, isn't d a reference to D? If not, what is it? And if it is,
isn't d a reference to an object of type D that occupies discontiguous
storage?

(I think you meant bar(x) above, and not foo(x), therefore:)
Inside bar is a dynamic reference to D. Since the data member offsets probably
don't line up as a normal D (because of the virtual A in both D and F) it
would not be a normal reference to D. Therefore, it is not a reference to an
object of type D; it would be a reference to an object with a dynamic type of D.
ta0kira

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gennaro Prota
Guest

Posted: Fri Feb 06, 2004 8:48 pm Post subject: Re: C++ object model question

On 1 Feb 2004 15:09:55 -0500, "Andrew Koenig" <ark (AT) acm (DOT) org> wrote:

Quote:

But is it correct to say that, e.g., the D subobject in X "has type
D"?

What other type could it have? Suppose, for example, we have class X
derived from D, and we then do this:

template<class T> void foo(T t) { /* ... */ }

X x;
foo(static_cast<D&>(x));

Inside the instantiation of foo that results, what type is T if not D? For
that matter:

void bar(D& d) { /* ... */ }

X x;
foo(x);

Inside bar, isn't d a reference to D? If not, what is it? And if it is,
isn't d a reference to an object of type D that occupies discontiguous
storage?

Yes

That's what I've always thought too but, as I said, John Potter
(whose opinions are always worth listening with attention) argued on
this group that base subobjects where different kind of beasts and
that "D base of X" was somewhat a different type than D. I don't see
anything in the standard that supports that view, but I thought to ask
anyway, to dispel any doubts.

(BTW, sorry for the confusion I may have caused by saying that the
relevant part of the post I linked to was under the "sketch" part; it
was actually above. Sorry again)

Well, so I'll return to my initial questions about 3.9/4. It says:

"The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T)."

Was it intended to apply to base subobjects too? The term "sequence"
suggests (to me) an idea of contiguity. I may understand that if
contiguity was really implied than the term "array" could have been
used. OTOH if they meant "bunch" of bytes, not necessarily contiguous,
then why not using the term "set". So I'm really asking to you how to
interpret it.

Secondly, the part "where N equals sizeof(T)" perplexes me a bit. If
the compiler applies EBO here, what's the object representation of the
A base subobject in X?

struct A {};
struct B : A {};

int main()
{
B b;
}

BTW, 5.3.3/2 explicitly says that "The result of applying sizeof to a
base class subobject is the size of the base class type".

Thirdly, note 70 talks about "actual size" of a base subobject and
says it can be *less* than the result of applying sizeof to the
subobject, due to virtual base classes: do they mean that "melted"
members (from virtual base classes) are counted only once, i.e. as if
they belonged to one subobject, or to the complete object only?

Example:

struct A { int a; };

struct B : virtual A { int b; };

struct C : virtual A { int c; };

struct D : B, C { int d; };

Suppose in a complete D object the compiler arranges the data members
in the order (ignoring any internal pointer)

b / c / d / a

Did they mean that "a" is only counter as a part of D, where as the B
and C subobjects only contain b and c respectively?

Thanks,
Genny.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Frank Birbacher
Guest

Posted: Sat Feb 07, 2004 11:15 am Post subject: Re: C++ object model question

Hi!

ta0kira wrote:

Quote:

Inside bar is a dynamic reference to D. Since the data member offsets probably
don't line up as a normal D (because of the virtual A in both D and F) it
would not be a normal reference to D. Therefore, it is not a reference to an
object of type D;

Yes, it is.

Quote:

it would be a reference to an object with a dynamic type of D.
ta0kira

Which is the same in this regard.

Altough the data members "line up" differently in instances of D and X,
=>the way to access them is the same<=

The compiler could use a pointer to the virtual base, for instance.

Frank

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

John Potter
Guest

Posted: Sun Feb 08, 2004 12:24 pm Post subject: Re: C++ object model question

On 6 Feb 2004 15:48:07 -0500, Gennaro Prota <gennaro_prota (AT) yahoo (DOT) com>
wrote:

Quote:

struct A { int a; };
struct B : virtual A { int b; };
struct C : virtual A { int c; };
struct D : B, C { int d; };

Suppose in a complete D object the compiler arranges the data members
in the order (ignoring any internal pointer)

b / c / d / a

Did they mean that "a" is only counter as a part of D, where as the B
and C subobjects only contain b and c respectively?

I don't remember what the point was in the previous discussion and am
not sure that there is one here either.

The terms object type, object representation, and value representation
are nicely related for PODs only. Since the object representation of
a B subobject of a D object is not the same as the object representation
of a free B object, I conclude that object representation does not apply
to non-POD types. There is no question that the value representation of
a C++ string is the bits defining the characters which may or may not be
anywhere near the object representation of the string. The possible
object representation of three pointers would not contain the value
representation. On a 370 IBM mainframe, a struct containing three
pointers where sizeof(pointer) == 4 and charbit == 8 has only 72 value
bits because the high order byte of the pointer does not participate in
the value representation. 3.9/4 was written to cover this not C++.

It seems reasonable to conclude that the C++ object model has nothing to
do with 3.9/4. It is an abstraction unrelated to the memory model. All
of these problems are a result of trying to force this into a nice low
level C object == memory model.

If the B subobject of a D is a D then an object type does not have an
object representation. If non-POD object types have object
representations then a B subobject of a D has a different object type
from a free B object.

BTW, you might have some fun changing the members in the above to char.
G++ will stuff the d char into the padding of the C subobject reducing
the size of the D object to 20. Bc also does some interesting things
with three byte pointers and packing of that struct to get a size of 12.

Stick that in your object pipe and smoke it. :)

John

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gennaro Prota
Guest

Posted: Mon Feb 09, 2004 12:48 am Post subject: Re: C++ object model question

On 8 Feb 2004 07:24:18 -0500, John Potter <jpotter (AT) falcon (DOT) lhup.edu>
wrote:

Quote:

On 6 Feb 2004 15:48:07 -0500, Gennaro Prota wrote:

struct A { int a; };
struct B : virtual A { int b; };
struct C : virtual A { int c; };
struct D : B, C { int d; };

Suppose in a complete D object the compiler arranges the data members
in the order (ignoring any internal pointer)

b / c / d / a

Did they mean that "a" is only counter as a part of D, where as the B
and C subobjects only contain b and c respectively?

I don't remember what the point was in the previous discussion and am
not sure that there is one here either.

The point was that I see some potential defects in 3.9/4 (see the
questions I ask in my previous post). You argued the following:

Note that object representation applies only to objects of
type. A base subobject has neither a name nor a name for its type
(which is base subobject of D). There is no way to apply sizeof
to it and it does not have an object representation.
[From: google.com/groups?selm=3d25e7c0.34024125%40news.earthlink.net]

and I disagreed. Of course, it may well be that I see defects because
I don't understand the paragraph, that's why I'm asking; but I don't
find yours a convincing explanation.

Quote:

The terms object type, object representation, and value representation
are nicely related for PODs only. Since the object representation of
a B subobject of a D object is not the same as the object representation
of a free B object, I conclude that object representation does not apply
to non-POD types.

I don't see the implication.

Quote:

There is no question that the value representation of
a C++ string is the bits defining the characters which may or may not be
anywhere near the object representation of the string.

That's a possible definition, but I think that's not the one the
standard adopted. Let's see what Andrew Koenig says.

Quote:

The possible
object representation of three pointers would not contain the value
representation. On a 370 IBM mainframe, a struct containing three
pointers where sizeof(pointer) == 4 and charbit == 8 has only 72 value
bits because the high order byte of the pointer does not participate in
the value representation.

I'm well aware that, except for unsigned char, C allows padding bits.
Padding bits would not be part of the "value representation".

Quote:

3.9/4 was written to cover this not C++.

Maybe some word is missing in this phrase. What does it mean?

Quote:

It seems reasonable to conclude that the C++ object model has nothing to
do with 3.9/4. It is an abstraction unrelated to the memory model. All
of these problems are a result of trying to force this into a nice low
level C object == memory model.

I don't see how do you conclude that, if not by assuming *your*
definition of value representation. You choose, so to speak, a logical
definition ("the value of the string is its sequence of characters")
whereas the standard insists, I think, on a mechanical one (the value
of its data members, say, three pointers).

Quote:

If the B subobject of a D is a D then an object type does not have an
object representation. If non-POD object types have object
representations then a B subobject of a D has a different object type
from a free B object.

That's where I think you are in error. It's *objects* that have object
representations, not types. So you may have different objects with
different object representations even though they have the same type.

Quote:

BTW, you might have some fun changing the members in the above to char.
G++ will stuff the d char into the padding of the C subobject reducing
the size of the D object to 20. Bc also does some interesting things
with three byte pointers and packing of that struct to get a size of 12.

Stick that in your object pipe and smoke it. Smile

I hope that's not something offensive. Anyway I don't smoke :)

Genny.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

John Potter
Guest

Posted: Fri Feb 13, 2004 1:51 am Post subject: Re: C++ object model question

On 8 Feb 2004 19:48:02 -0500, Gennaro Prota <gennaro_prota (AT) yahoo (DOT) com>
wrote:

Quote:

There is no question that the value representation of
a C++ string is the bits defining the characters which may or may not be
anywhere near the object representation of the string.

That's a possible definition, but I think that's not the one the
standard adopted. Let's see what Andrew Koenig says.

Nothing, it seems. Let's assume that 3.9/4 was copied from the C
standard and has no meaning for non-POD objects. I guess that the
wording should be "The object representation of a COMPLETE object of
type T" to remove your complaints about sequence of bytes in an
object. If the wording were changed, what new freedoms/restrictions
would implementers/users have? What difference does it make whether
the value representation of an string is three pointers or the
characters holding the value? The standard does not require the
value representation to be in the object representation. Why should
it? Why do you think that "The object representation of an object
of type T" allows different representations for different objects of
the same type when it says "The"?

What would you change and how would the time spent to make those
changes be of value to implementers or practitioners? Are we just
counting angels on pinheads?

John

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gennaro Prota
Guest

Posted: Sat Feb 14, 2004 12:30 pm Post subject: Re: C++ object model question

On 12 Feb 2004 20:51:20 -0500, John Potter <jpotter (AT) falcon (DOT) lhup.edu>
wrote:

Quote:

On 8 Feb 2004 19:48:02 -0500, Gennaro Prota wrote:

There is no question that the value representation of
a C++ string is the bits defining the characters which may or may not be
anywhere near the object representation of the string.

That's a possible definition, but I think that's not the one the
standard adopted. Let's see what Andrew Koenig says.

Nothing, it seems.

Yes. Probably he isn't following the group anymore; I was busy and let
several days pass before replying to his post, so he may have checked
for a couple of days and then thought the thread was dead.

Quote:

Let's assume that 3.9/4 was copied from the C
standard and has no meaning for non-POD objects. I guess that the
wording should be "The object representation of a COMPLETE object of
type T" to remove your complaints about sequence of bytes in an
object.

Which doesn't mean POD objects, only.

Quote:

If the wording were changed, what new freedoms/restrictions
would implementers/users have?

The freedom to understand the standard? :)

Quote:

What difference does it make whether
the value representation of an string is three pointers or the
characters holding the value? The standard does not require the
value representation to be in the object representation. Why should
it? Why do you think that "The object representation of an object
of type T" allows different representations for different objects of
the same type when it says "The"?

If I say: "the nose of a person with black hair" why do you think
different black-haired people may have different noses? Why I say
"the"?

Quote:

What would you change and how would the time spent to make those
changes be of value to implementers or practitioners? Are we just
counting angels on pinheads?

We are just discussing to understand things better, which is what we
do 90% of the time here. I've not filed any DR so the committee isn't
spending time. And then, if you take a look at the core issues list
you will see many defects that require a lot of discussion for no
sensible benefit; but once a flaw is spotted, I think, nobody can
resist the impulse to fix it :)

Genny.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

John Potter
Guest

Posted: Wed Feb 18, 2004 12:12 pm Post subject: Re: C++ object model question

On 14 Feb 2004 07:30:26 -0500, Gennaro Prota <gennaro_prota (AT) yahoo (DOT) com>
wrote:

Quote:

On 12 Feb 2004 20:51:20 -0500, John Potter wrote:

Let's assume that 3.9/4 was copied from the C
standard and has no meaning for non-POD objects. I guess that the
wording should be "The object representation of a COMPLETE object of
type T" to remove your complaints about sequence of bytes in an
object.

Which doesn't mean POD objects, only.

Agreed. By adding "complete" it would apply to C++ objects and make
sense. It would also answer all of your sizeof questions from the
earlier post. It would also cover the contiguous sequence of bytes.

Quote:

May I assume that the lack of a comment here means that we agree that
the value bits of a non-pod object may be anywhere?

Quote:

Why do you think that "The object representation of an object
of type T" allows different representations for different objects of
the same type when it says "The"?

If I say: "the nose of a person with black hair" why do you think
different black-haired people may have different noses? Why I say
"the"?

Bad analogy. Black hair is an attribute not a type. "The object
representation of an object of type T", looks like it is defining
something which applies to all objects of a given type. If each
object of type T could have a different object representation, the
term would be useless.

I think you have a point on the object representation being defective,
but the rest is purposely unspecified.

John

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum