In article <D19H8u.AD6@gsl.com>, Douglas Clinton <dec@gsl.com> wrote:
> In article <3da676$5qa@seattle.polstra.com>, jdp@polstra.com (John Polstra) writes:
> |> In article <3d5r26$1eo@triode.apana.org.au>,
> |> Richard Welykochy <rick@triode.apana.org.au> wrote:
> |> >
> |> > Misha'al A. Al-Kadhi (maalkadh@rodan.syr.edu) wrote:
> |> >
> |> > : When I test for teh length of an object, will the
> |> > : vtable length be included in this returned value
> |> > : or is teh length only the length of the object
> |> > : minus the vtable?
> |> >
> |> > Try sizeof(object) ... you will find that the size of an object
> |> > includes any 'hidden' details used by the compiler implementor
> |> > to realize an instance of the class.

[Ill-considered rudeness on my part elided.]

> |> An instance of a class does not contain the vtable.  It contains only
> |> a pointer to the vtable.  The size as given by sizeof will include the
> |> size of the vtable pointer, but it will not include the size of the
> |> vtable itself.  The vtable is allocated separately, and a single vtable
> |> can be shared by many instances of the class.

[Reciprocal rudeness on Doug's part also elided.]

> Whether the instance contains the vtable or a pointer to it, or whether
> it uses a vtable at all is an implementation issue.

Well, you're certainly right about that.  I should have stated that
clearly.  After all, this is comp.STD.c++.

> As Richard said, sizof(object) will include any hidden details and
> those details will be implementation dependent.

Sorry, but I have to disagree with the first part of that statement.
Sizeof will NOT necessarily include all the hidden details.  If vtbls are
used to implement virtual functions (as is the case in most, if not all,
present day non-experimental compilers), and if the vtbls are allocated
outside of the class instances (as is the case in most, if not all,
present day non-experimental compilers), then sizeof will NOT include
the size of the vtbl.  Nevertheless, the vtbl is a "hidden detail" which
MUST be present in order for the class instance to function properly.

The real point which I think we are all trying to make to the original
poster, each in his own way, is this:  You cannot, in general, just blat
out the raw bits of a class instance to a file, then blat them back in
later.  If you do that, there's a good chance that your newly read in
class instance isn't going to work properly -- particularly if you've read
it into a different program than the one that wrote it out.

The fact that that approach is a bad idea actually has little to do with
C++.  It's a bad idea even in C.  Because, eventually, you are going to
want to read that file back in on some different architecture.  Trust me,
it will happen some day.  You think it won't, but it will.  And then
you'll have a mess on your hands, because your fancy new machine will
have a different byte ordering, or different word sizes, or a different
floating point representation, or different alignment requirements.  Or,
maybe you'll simply switch to a different compiler (or a new release of
your current compiler) which, for whatever reason, lays out its class
instances differently in memory.

My advice to the original poster:  Do yourself a favor.  Bite the bullet,
and implement serialization / deserialization functions that write /
read the class data member-by-member, in a machine-independent format.

In my experience, the best implementations of such functions don't use
sizeof at all.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

In article <3d5r26$1eo@triode.apana.org.au>,
Richard Welykochy <rick@triode.apana.org.au> wrote:
>
> Misha'al A. Al-Kadhi (maalkadh@rodan.syr.edu) wrote:
>
> : When I test for teh length of an object, will the
> : vtable length be included in this returned value
> : or is teh length only the length of the object
> : minus the vtable?
>
> Try sizeof(object) ... you will find that the size of an object
> includes any 'hidden' details used by the compiler implementor
> to realize an instance of the class.

I find this answer misleading.

An instance of a class does not contain the vtable.  It contains only
a pointer to the vtable.  The size as given by sizeof will include the
size of the vtable pointer, but it will not include the size of the
vtable itself.  The vtable is allocated separately, and a single vtable
can be shared by many instances of the class.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                   Phone (206) 932-6482
   Seattle, Washington USA                         Fax (206) 935-1262
   "Self-knowledge is always bad news."                 -- John Barth

maalkadh@rodan.syr.edu (Misha'al A. Al-Kadhi) writes:
>
>Hi. Just a quick question regarding vtables.  I understand that
>there is no standard place to store vtables for a given
>object, however, do all implementations require storing them
>either at the beginning or the end of an object or can they
>be stored in a completely independant location?

The standard says nothing, absolutely nothing about where or how any sort
of vtables might or might not be stored anywhere.  That is left
completely up to the compiler vendor.

>Second question (probably answered by teh first):
>When I test for teh length of an object, will the
>vtable length be included in this returned value
>or is teh length only the length of the object
>minus the vtable?

It turns out that you only need one actual vtable per class as opposed to
a whole vtable per object instance.  That means that compilers tend to
allocate one vtable for a class, then just stick a pointer in with the
object instances that points to the appropriate table.  This pointer, of
course, changes as need be for various descendents and what-not.

If you do a sizeof(object), you will get the size of all its data,
including that vtable pointer.  If you're worried about persistence,
you're going to have to write the data fields individually with a class
member, calling base class functions to get their members stored as
well.  Don't worry about saving the vtable, as it should be the same in
later executions of the program where you call member functions to load
the instance data back in.

Me

maalkadh@rodan.syr.edu (Misha'al A. Al-Kadhi) writes:
>Hi. Just a quick question regarding vtables.  I understand that
>there is no standard place to store vtables for a given
>object, however, do all implementations require storing them
>either at the beginning or the end of an object or can they
>be stored in a completely independant location?

The standard mentions "vtable" nowhere, since it doesn't require
that implementations use virtual function tables at all.  A conforming
implementation could implement virtual functions in an entirely
different way (you could have one big lookup table for all virtual
functions of all objects, say, which might save storage if you had
thousands of derived classes).

>When I test for teh length of an object, will the
>vtable length be included in this returned value

sizeof(object) returns the size of the object, including any overhead
for the vtable (or other means for resolving virtual functions).



--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

Misha'al A. Al-Kadhi (maalkadh@rodan.syr.edu) wrote:
: Hi. Just a quick question regarding vtables.  I understand that
: there is no standard place to store vtables for a given
: object, however, do all implementations require storing them
: either at the beginning or the end of an object or can they
: be stored in a completely independant location?

Of course, this is an implementation detail, and one cannot rely
on where the vtable will be stored.  Why is this an issue?

: Second question (probably answered by teh first):
: When I test for teh length of an object, will the
: vtable length be included in this returned value
: or is teh length only the length of the object
: minus the vtable?

Try sizeof(object) ... you will find that the size of an object
includes any 'hidden' details used by the compiler implementor
to realize an instance of the class.
Try the same for MI classes, and you'll be suprised at the
overhead you buy when using multiple inheritance.

Hi. Just a quick question regarding vtables.  I understand that
there is no standard place to store vtables for a given
object, however, do all implementations require storing them
either at the beginning or the end of an object or can they
be stored in a completely independant location?

Second question (probably answered by teh first):
When I test for teh length of an object, will the
vtable length be included in this returned value
or is teh length only the length of the object
minus the vtable?  Thanks
Misheal

maalkadh@rodan.syr.edu (Misha'al A. Al-Kadhi) writes:

>Hi. Just a quick question regarding vtables.  I understand that
>there is no standard place to store vtables for a given
>object, however, do all implementations require storing them
>either at the beginning or the end of an object or can they
>be stored in a completely independant location?

>Second question (probably answered by teh first):
>When I test for teh length of an object, will the
>vtable length be included in this returned value
>or is teh length only the length of the object
>minus the vtable?  Thanks

Vtables are not part of the language definition. No compiler is
obligated to use them. A compiler which does can put them anywhere
it likes. The "sizeof" operator returns the amount of space an
object requires when used as an array element, including any
hidden data and padding for alignment. If a vtable is part of
the object (I don't know of any implemenations for which this
is the case), then its size is included. The usual implementation
has one pointer for each associated vtable, and (only) the pointers
are included in the object's size (because they are part of the
object, but the vtables are not).

You cannot write portable code which makes any assumptions at all
about vtables.
--
Steve Clamage, stephen.clamage@eng.sun.com