I thought the point of C++ was to avoid (as much as practical)
calls like that memcpy() call.  If you want portability, it's
a necessity.  So what if it complicates your code.  The worst
case is some reduction in speed.  Unless you really need
to do this, why bother digging into your compiler's implementation?

I suppose some people find it fun.  Too concrete!

Chris

Barry Margolin wrote:

> Given Derived1 and Derived2, both derived from AbstractClass, is the
> following well-defined:
>
> Derived1 d1;
> Derived2 d2;
>
> memcpy((AbstractClass *)&d1, (AbstractClass *)&d2, sizeof(AbstractClass));
>



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Ahlstrom wrote:

> I thought the point of C++ was to avoid (as much as practical)
> calls like that memcpy() call.  If you want portability, it's
> a necessity.

memcpy is portable and well-defined for PODs.

It doesn't do the right thing in most cases, that's
why we can overload the assignement operator in C++.
But memcpy is fine in some situations, like for
old style char arrays (used to implement higher level
classes).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Barry Margolin wrote:
>
> In article <6jvfdo$7ib@engnews1.Eng.Sun.COM>,
> Steve Clamage <stephen.clamage@sun.com> wrote:
> >You couldn't do anything portable with the result, since the meaning
> >of the result isn't specified by the standard.
>
> Is there even a practical use for it?  Why do you need to know the size of
> something that can't exist?

It can exist, as a base class sub-object of a derived class. It can take
up space, if it contains any non-static data members. In rare
circumstances, you might want to copy those byte by byte, rather than
using the copy constructor (with highly implementation-specific
consequences).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6k23mi$no4@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>The question was what sizeof(AbstractClass) returns. The draft
>standard doesn't provide any useful guidelines. But I don't
>know what you could do with the result even if it were better
>specified. When used as a base class, any class might take up
>less space than is reported by sizeof.

Given Derived1 and Derived2, both derived from AbstractClass, is the
following well-defined:

Derived1 d1;
Derived2 d2;

....

memcpy((AbstractClass *)&d1, (AbstractClass *)&d2, sizeof(AbstractClass));

In article 3580@cam-news-reader1.bbnplanet.com, Barry Margolin <barmar@bbnplanet.com> writes:
>In article <6k23mi$no4@engnews1.Eng.Sun.COM>,
>Steve Clamage <clamage@Eng.Sun.COM> wrote:
>>The question was what sizeof(AbstractClass) returns. The draft
>>standard doesn't provide any useful guidelines. But I don't
>>know what you could do with the result even if it were better
>>specified. When used as a base class, any class might take up
>>less space than is reported by sizeof.
>
>Given Derived1 and Derived2, both derived from AbstractClass, is the
>following well-defined:
>
>Derived1 d1;
>Derived2 d2;
>
>.....
>
>memcpy((AbstractClass *)&d1, (AbstractClass *)&d2, sizeof(AbstractClass));
>
>From your last sentence, I take it that the answer is independent of
>whether the base class is abstract.

Well, yes, because using memcpy on a non-POD has undefined results.
The only way to copy a non-POD class object and get defined results
is to copy the whole object with the copy constructor or assignment
operator. (Draft standard section 12.8 "Copying class objects".)

Maybe you meant to use memcpy only as an example. In any event,
the same class used in different hierarchies might occupy different
amounts of space. I think the standard pretty much requires (unless
you have a loose definition of "required padding") that the class
not take up any more space than reported by sizeof. Intermediate
amounts of space occupied might depend on details of class layout
and vtable implementation. There isn't any portable way to find
out this kind of information (in the sense of writing a program
that will work in the desired way on all implementations).

Trivial example: A class with no data used as a base class might zero
size. The class used as a complete object must not have zero size.
If the same class appears more than once in a hierarchy, each
instance must have a different address, so they could each have zero
size only if they don't collapse into the same location.

---
Steve Clamage, stephen.clamage@sun.com



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

|>  Barry Margolin wrote:
|>  >
|>  > In article <6jvfdo$7ib@engnews1.Eng.Sun.COM>,
|>  > Steve Clamage <stephen.clamage@sun.com> wrote:
|>  > >You couldn't do anything portable with the result, since the meaning
|>  > >of the result isn't specified by the standard.
|>  >
|>  > Is there even a practical use for it?  Why do you need to know the size of
|>  > something that can't exist?
|>
|>  It can exist, as a base class sub-object of a derived class. It can take
|>  up space, if it contains any non-static data members. In rare
|>  circumstances, you might want to copy those byte by byte, rather than
|>  using the copy constructor (with highly implementation-specific
|>  consequences).

But one of Steve's points was that the sizeof a type does NOT
necessarily correspond to the size of that type when used as a base
class.  Although Steve didn't explicitly say so, this implies that you
can NEVER copy the base class by copying sizeof bytes, byte by byte.

Sizeof is defined in terms of the space an object of that type occupies
in an array.  If you cannot put the object in an array, either sizeof
has no real meaning, or the standard has made a special case of it.  The
only special case I know of is a reference, where sizeof( T& ) is
defined as sizeof( T ).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is there anything in the standard preventing taking the sizeof an
abstract class?  The standard says sizeof can't give the size of an
incomplete type, but I don't believe a fully declared abstract class
is incomplete.  I've run across a compiler that refuses to do it.

class AbstractClass {
public:
    virtual void SomeFunction() = 0;
private:
    int x;
}

void Foo()
{
    int x = sizeof(AbstractClass);
}
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article fsf@lickey.shell4.ba.best.com, Matt Armstrong <mattdav+matt@best.com> writes:
>Is there anything in the standard preventing taking the sizeof an
>abstract class?  ...  I've run across a compiler that refuses to do it.

Interesting question.

The section on abstract classes (10.4 "Abstract classes") lists some
things you can and cannot do with an abstract class, but doesn't
mention sizeof.

The section on sizeof (5.3.3 "Sizeof") says you can't take the size
of an incomplete type, a function type, an enum before all its members
are defined, or a bitfield. An abstract class is none of those.

On that basis, it would seem to be legal to ask for the size of an
abstract class type.

On the other hand, the definition of sizeof says "When applied to a
class, the result is the number of bytes in an object of that class
including any padding required for placing objects of that type in
an array."

Since there can be no objects (that is, no complete objects, no array
members, and no function parameters -- just base-class subobjects) of
such a type, it isn't clear what the sizeof operator should yield.
You couldn't do anything portable with the result, since the meaning
of the result isn't specified by the standard.

I can imagine an implementation disallowing sizeof(abstract_class)
on that basis, but I think it should accept the expression and yield
a value.

---
Steve Clamage, stephen.clamage@sun.com



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6jvfdo$7ib@engnews1.Eng.Sun.COM>,
Steve Clamage <stephen.clamage@sun.com> wrote:
>You couldn't do anything portable with the result, since the meaning
>of the result isn't specified by the standard.

Is there even a practical use for it?  Why do you need to know the size of
something that can't exist?

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> In article fsf@lickey.shell4.ba.best.com, Matt Armstrong <mattdav+matt@best.com> writes:
> >Is there anything in the standard preventing taking the sizeof an
> >abstract class?  ...  I've run across a compiler that refuses to do it.
>
> Interesting question.
>
> The section on abstract classes (10.4 "Abstract classes") lists some
> things you can and cannot do with an abstract class, but doesn't
> mention sizeof.
>
> The section on sizeof (5.3.3 "Sizeof") says you can't take the size
> of an incomplete type, a function type, an enum before all its members
> are defined, or a bitfield. An abstract class is none of those.
>
> On that basis, it would seem to be legal to ask for the size of an
> abstract class type.
>
> On the other hand, the definition of sizeof says "When applied to a
> class, the result is the number of bytes in an object of that class
> including any padding required for placing objects of that type in
> an array."
>
> Since there can be no objects (that is, no complete objects, no array
> members, and no function parameters -- just base-class subobjects) of
> such a type, it isn't clear what the sizeof operator should yield.
> You couldn't do anything portable with the result, since the meaning
> of the result isn't specified by the standard.

A base class sub-object can still have a fairly well-defined size - I
would expect that it would be the same as the size of an otherwise
identical class that differed from the original only by providing a
definition for every virtual member.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Armstrong <mattdav+matt@best.com> writes:

> Is there anything in the standard preventing taking the sizeof an
> abstract class?

No.

> The standard says sizeof can't give the size of an incomplete type,

A semicolon was missing after the class declaration, so the compiler
may have considered the class an incomplete type in the body of the
function that followed its declaration.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 167E@wizard.net, James Kuyper <kuyper@wizard.net> writes:
>Steve Clamage wrote:
>>
>> In article fsf@lickey.shell4.ba.best.com, Matt Armstrong <mattdav+matt@best.com> writes:
>> >Is there anything in the standard preventing taking the sizeof an
>> >abstract class?  ...  I've run across a compiler that refuses to do it.
>>
>> On the other hand, the definition of sizeof says "When applied to a
>> class, the result is the number of bytes in an object of that class
>> including any padding required for placing objects of that type in
>> an array."
>>
>> Since there can be no objects (that is, no complete objects, no array
>> members, and no function parameters -- just base-class subobjects) of
>> such a type, it isn't clear what the sizeof operator should yield.
>> You couldn't do anything portable with the result, since the meaning
>> of the result isn't specified by the standard.
>
>A base class sub-object can still have a fairly well-defined size ...

Defined by the compiler, when used as a base class, yes. The compiler
knows how it implements things. But not all aspects of the
implementation are available for inspection by standard-
conforming or portable programs. (Similarly, even undefined operations
have some sort of result, but usually you don't know what the result
is ahead of time.)

The question was what sizeof(AbstractClass) returns. The draft
standard doesn't provide any useful guidelines. But I don't
know what you could do with the result even if it were better
specified. When used as a base class, any class might take up
less space than is reported by sizeof.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]