In article <Eu7QPKAaTcy2EwTh@noco.demon.co.uk>,
  Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <36C044E9.578B@clipper.ens.fr>, Valentin Bonnard
>
> >> An object store database system.
> >
> >Then that's completly unrelated with sizeof.
> >
>
> I once needed to know the size in bytes of a linked list

If you mean the whole linked list, then sizeof() isn't going to
help you. You'll either have to walk the list counting elements,
or maintain a counter somewhere. Either way this has to be beyond
the scope of the language, so a new operator can't help you.

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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 <7ahksq$n6v$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com> wrote:
>
>In article <Eu7QPKAaTcy2EwTh@noco.demon.co.uk>,
>  Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>> In article <36C044E9.578B@clipper.ens.fr>, Valentin Bonnard
>>
>> >> An object store database system.
>> >
>> >Then that's completly unrelated with sizeof.
>> >
>>
>> I once needed to know the size in bytes of a linked list
>
>If you mean the whole linked list, then sizeof() isn't going to
>help you. You'll either have to walk the list counting elements,
>or maintain a counter somewhere. Either way this has to be beyond
>the scope of the language, so a new operator can't help you.

But for each element, you need a virtual sizeof() to determine its
contribution to the size.  That's what I thought he was referring to.

Or the sizeof() operator for the linked list class could itself perform the
walk.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


[ 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 <36C044E9.578B@clipper.ens.fr>, Valentin Bonnard

>> An object store database system.
>
>Then that's completly unrelated with sizeof.
>

I once needed to know the size in bytes of a linked list

--
Mike Davies
---
[ 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              ]

Valentin Bonnard wrote in message <36C044E9.578B@clipper.ens.fr>...
>Al Stevens wrote:
>>
>> >Personally, I can't remember ever needing to know the size of a
>> >non-POD object.  Perhaps you have an example or two showing this
>> >(presumed) need?
>>
>> An object store database system.
>
>Then that's completly unrelated with sizeof.


Well, having implemented an object store database, I can only disagree. The
details of the implementation aren't important to this discussion, but I can
assure you, a polymorphic sizeof would have made it easier.

I'm tending to agree with those here who think it could be somehow related
to RTTI.




[ 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              ]

Al Stevens wrote:
>
> >Personally, I can't remember ever needing to know the size of a
> >non-POD object.  Perhaps you have an example or two showing this
> >(presumed) need?
>
> An object store database system.

Then that's completly unrelated with sizeof.

--

Valentin Bonnard
---
[ 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              ]

Siemel Naran wrote:
>
> On 10 Feb 99 05:09:57 GMT, James Kuyper <kuyper@wizard.net> wrote:
> >Siemel Naran wrote:
>
> >> class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
....
> Note the "==" on the function 'clone'.
> It means that 'clone' is always inherited as a pure virtual function.
> So it must be overrided in every concrete class.
> Maybe "%" instead of "==" is better, just because "==" doesn't stand out.

It sure doesn't. If you use a proposed new feature in a code example,
it's a good idea to identify it as such, particularly when it could
easily otherwise be taken as a typo.
---
[ 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 <ph6PkRBtkCw2EwGs@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> In article <lsHv2.33248$bM1.43930@newscene.newscene.com>, Al Stevens
> <alstevens@midifitz.com> writes
> >Make the Base::size function a pure virtual function and you won't need to
> >remember. The compiler will remind you.
>
> No it won't.
> I wish we actually had a mechanism that required an
> implementation to be provided by EVERY derived class but at present once
> you derive from a derived class that provides an implementation there is
> no requirement to re-implement.

**ME TOO**

> Any ideas?

How about?
    virtual MustBeOverridden() = 1;

Actually I am moderately serious. - The ability to require every class that
uses a class as an INDIRECT base, to redefine a function is useful. - I don't
think it can be done without a change to the language (unless someone comes
up with a clever use of templates and virtual base classes?). - The above
syntax would not have any impact on currently valid programs. - I have *NO*
idea how much more difficult it might make parsers. - This syntax does not
allow a class to be concrete, while still requiring any child classes to
override the function. I don't think that is a major problem (there is a
simple workround). - This syntax is opaque, but it does have the advantage of
not introducing yet another keyword.

(I bet I don't remember to post this again in five years time, when the
standard is up for review).



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

mbonner@my-dejanews.com wrote in article
<79s2a4$f2r$1@nnrp1.dejanews.com>...
> In article <ph6PkRBtkCw2EwGs@robinton.demon.co.uk>,
>   Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> >
> > I wish we actually had a mechanism that required an
> > implementation to be provided by EVERY derived class but at present
once
> > you derive from a derived class that provides an implementation there
is
> > no requirement to re-implement.
>
> **ME TOO**
>
> > Any ideas?
>
> How about?
>     virtual MustBeOverridden() = 1;
>
> Actually I am moderately serious. - The ability to require every class
that
> uses a class as an INDIRECT base, to redefine a function is useful. - I
don't
> think it can be done without a change to the language (unless someone
comes
> up with a clever use of templates and virtual base classes?).

A simple application of one of Scott Meyers' Effective C++ rules will do -
I believe this one is called 'base classes must be abstract'.

The idea is that every instantiatable base class is split in two: one
intended for further derivation, which is not instantiatable (it may have a
pure virtual function or just protected ctors), plus an instantiatable leaf
class which is directly derived from the non-instantiable one and
considered final.

The idiom works nicely to prevent accidental slicing when a particular
class is used polymorphically in one context and as a simple automatic or
member object in another: the instantiatable variant can have a regular
copy ctor and assignment operator, both of which are not accessible through
the interface of its abstract parent class.

Another benefit is that this rule (Can we call this a design pattern? I
think we can!) defines a natural place for virtual functions that must be
overridden: they can be declared as abstract in some base class and only be
overidden by the instantiatable leaf classes in the hierarchy.

- Wil

--
sender's address is spam-protected -
please remove 'nospam.' when sending email
---
[ 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 <slrn7c0tnn.ij9.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain.COM> writes
>class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
>class Derived { Derived * clone() const { return new Derived(*this); } };
>class MoreDerived { };
>
>int main()
>{
>   Base * b1=new Base(); // error  Base::clone() pure
>   Base * b2=new Derived(); // ok
>   Base * b3=new MoreDerived(); // error  MoreDerived::clone() pure
>   delete b3;
>   delete b2;
>   delete b1;
>}

I have read this three times and it simply does not make sense.  You
have elided too much.  Is MoreDerived derived from Derived or Base?  Are
you trying to use virtual inheritance.  Please fill in the detail
because I have tried a lot of variations on this theme and have yet to
find one that works.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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              ]

On 10 Feb 99 05:09:57 GMT, James Kuyper <kuyper@wizard.net> wrote:
>Siemel Naran wrote:

>> class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
>> class Derived { Derived * clone() const { return new Derived(*this); } };
>> class MoreDerived { };
>
>I assume that Derived was intended to be derived from Base, and that
>MoreDerived was intended to be derived from Derived.

Yes.
Note the "==" on the function 'clone'.
It means that 'clone' is always inherited as a pure virtual function.
So it must be overrided in every concrete class.
Maybe "%" instead of "==" is better, just because "==" doesn't stand out.

>Why? Assuming that it's name means what it says, MoreDerived::clone()
>will be inherited from Derived::clone(), which is not pure. That's
>precisely what Francis is trying to avoid.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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              ]

On 10 Feb 99 17:10:20 GMT, Wil Evers <Wil_Evers@nospam.doosys.com> wrote:

>A simple application of one of Scott Meyers' Effective C++ rules will do -
>I believe this one is called 'base classes must be abstract'.

An excellent coding standard, but a coding standard nevertheless.
It may at times still be useful to derive from a concrete class.
Then we want some assurance that a virtual function (not pure) is
inherited as a pure virtual function.  Hence my "==" suggestion.


>The idea is that every instantiatable base class is split in two: one
>intended for further derivation, which is not instantiatable (it may have a
>pure virtual function or just protected ctors), plus an instantiatable leaf
>class which is directly derived from the non-instantiable one and
>considered final.

OK.  It does complicate the inheritance hierarchy tree though.


>The idiom works nicely to prevent accidental slicing when a particular
>class is used polymorphically in one context and as a simple automatic or
>member object in another: the instantiatable variant can have a regular
>copy ctor and assignment operator, both of which are not accessible through
>the interface of its abstract parent class.

I like this.


>Another benefit is that this rule (Can we call this a design pattern? I
>think we can!) defines a natural place for virtual functions that must be
>overridden: they can be declared as abstract in some base class and only be
>overidden by the instantiatable leaf classes in the hierarchy.

I'd call it a "trick".

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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 <79s2a4$f2r$1@nnrp1.dejanews.com>, mbonner@my-dejanews.com
writes
>How about?
>    virtual MustBeOverridden() = 1;
>
>Actually I am moderately serious. - The ability to require every class that
>uses a class as an INDIRECT base, to redefine a function is useful. - I don't
>think it can be done without a change to the language (unless someone comes
>up with a clever use of templates and virtual base classes?). - The above
>syntax would not have any impact on currently valid programs. - I have *NO*
>idea how much more difficult it might make parsers. - This syntax does not
>allow a class to be concrete, while still requiring any child classes to
>override the function. I don't think that is a major problem (there is a
>simple workround). - This syntax is opaque, but it does have the advantage of
>not introducing yet another keyword.
>
>(I bet I don't remember to post this again in five years time, when the
>standard is up for review).


I think I prefer Siemel Naran's suggestion to use == or something along
that line.  However I would like implementors to consider the
implications to them.  At the moment all a derived class needs to see is
the vtable for the direct bases, if there is a zero then an
implementation is required if the class is not to remain abstract.
AFAICS any proposal for a stronger requirement would need at least a set
of bool flags that identified which functions required implementations
for the derived type to be concrete.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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 <01be5512$a1839500$aa12f0c3@twwie>, Wil Evers
<Wil_Evers@nospam.doosys.com> writes
>A simple application of one of Scott Meyers' Effective C++ rules will do -
>I believe this one is called 'base classes must be abstract'.
>
>The idea is that every instantiatable base class is split in two: one
>intended for further derivation, which is not instantiatable (it may have a
>pure virtual function or just protected ctors), plus an instantiatable leaf
>class which is directly derived from the non-instantiable one and
>considered final.

Sorry, but I disagree.  It is easy to solve the problem with a coding
guideline but that is not what I want.  Most code out there is written
by people who need rather more support.  In addition just because a
derived class is abstract does not enforce the requirement that a
specific virtual function is always instantiated.  Part of the problem
is that in the Real World (tm) programmers do not always read
documentation let alone do what they are asked to do.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 Minnoy" <cminnoy@starlab.net> writes:

>Ever wanted to ask the size of an object? Sure you did. Ever wanted to ask
>the size of a polymorphic type? Sure you did, but you came home form a cold
>yourney. C++ doesn't recognizes the size of indirect virtual types. This is
>because the size of an object is determined at compile time, and there is
>no way for the compiler to figure out what kind of object you will be
>dealing with at runtime. But, do we have to live wih it? I don't think so.
>It's rather easy for a compiler to add a facility so sizeof could determine
>the size of an object at runtime, and that's through the vtable.

But no language extension is required. If you want the size of a
polymorphic target, add a virtual function that returns the size:

class Base {
public:
 virtual size_t size() { return sizeof(*this); }
 ...
};

class Derived : public Base {
 virtual size_t size() { return sizeof(*this); }
 ...
};

And so on. This is not quite as convenient as a built-in feature,
because you must remember to add the size function to each
derived class.

But I think it is rather unusual to need to query the size of a
polymorphic target. Usually you want the size so that you can
create an object -- but that's the job of a class member
operator new, or of a virtual clone() function. Or you want
the size so you can dump the object to a file -- but a virtual
write() function will do that.

Maybe you could explain what problem you are trying to solve.

--
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              ]

On 07 Feb 99 00:13:45 GMT, Steve Clamage <clamage@Eng.Sun.COM> wrote:

>But no language extension is required. If you want the size of a
>polymorphic target, add a virtual function that returns the size:

Then why did C++ add the typeid operator?  A virtual function
Base::typeid would have sufficed.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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 <slrn7bpnn6.mdm.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>>But no language extension is required. If you want the size of a
>>polymorphic target, add a virtual function that returns the size:
>
>Then why did C++ add the typeid operator?  A virtual function
>Base::typeid would have sufficed.

Because an increasing number of library implementors (particularly AFX
libraries) were simulating RTTI by slightly variant mechanisms.  That is
a certain clue that a standardised mechanism is worth consideration.
Not many, if any, have been providing a virtual size mechanism -
suggesting that it is rather too specialist to be worth providing
generally.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

>And so on. This is not quite as convenient as a built-in feature,
>because you must remember to add the size function to each
>derived class.


Make the Base::size function a pure virtual function and you won't need to
remember. The compiler will remind you.




[ 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 Minnoy wrote:
>
> Ever wanted to ask the size of an object? Sure you did. Ever wanted to
> ask the size of a polymorphic type? Sure you did, but you came home
> from a cold journey. C++ doesn't recognizes the size of indirect
> virtual types.
...
> I think this would have great benefits.

Personally, I can't remember ever needing to know the size of a
non-POD object.  Perhaps you have an example or two showing this
(presumed) need?

-- David R. Tribble, dtribble@technologist.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 <lsHv2.33248$bM1.43930@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>
>>And so on. This is not quite as convenient as a built-in feature,
>>because you must remember to add the size function to each
>>derived class.
>
>
>Make the Base::size function a pure virtual function and you won't need to
>remember. The compiler will remind you.

No it won't.  Consider:

class Base {
    ...
  public:
    size_t size() = 0;
    ...
}

class Derived: public Base {
    ...
  public:
    site_t size();
    ...
}

class Derived_from_Derived: public Derived {
    ...
}

There won't be any complaint if Derived_from_Derived doesn't override
Derived::size.  But if sizeof(Derived_from_Derived) != sizeof(Derived), the
result will be wrong.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
---
[ 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              ]

"Al Stevens" <alstevens@midifitz.com> writes:

>>And so on. This is not quite as convenient as a built-in feature,
>>because you must remember to add the size function to each
>>derived class.

>Make the Base::size function a pure virtual function and you won't need to
>remember. The compiler will remind you.

Really? Let's try an example:

class Base {
public:
 virtual size_t size() = 0;
 ...
};

class D1 : public Base {
public:
 virtual size_t size() { return sizeof(*this); }
 ...
};

class D2 : public D1 {
 ... // does not contain a size function
};

int main()
{
    Base b;             // won't compile
    Base* bp = new D2;
    cout << bp->size(); // compiles, gives wrong answer
}

You need an extra sub-level of base class in order to be able to
have Base objects. Even if you implement Base::size(), you can't
create Base objects.

Let's try a dummy base class:

struct Dummy { virtual size_t size() = 0; }

class Base : public Dummy {
public:
 virtual size_t size() { return sizeof(*this); }
 ...
};

class Derived : public Base {
 ... // does not contain a size function
};

Now we can create a Base object, but we have the same "size"
problem in Derived as with D2 in the earlier example.

The compiler won't warn you about a missing "size" in any class
derived from the first class that can be instantiated.  If you have
no derivation, you have no polymorphism, and the need for a virtual
size function disappears. The "pure virtual" solution works only
when you don't need it.

--
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              ]

David R Tribble <dtribble@technologist.com> wrote:
> Personally, I can't remember ever needing to know the size of a
> non-POD object.  Perhaps you have an example or two showing this
> (presumed) need?

Writing your own allocator.

Paul


[ 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 message <79fqfc$apn$1@engnews2.Eng.Sun.COM>...
>But no language extension is required. If you want the size of a
>polymorphic target, add a virtual function that returns the size:
>
>class Base {
>public:
> virtual size_t size() { return sizeof(*this); }
> ...
>};
>
>class Derived : public Base {
> virtual size_t size() { return sizeof(*this); }
> ...
>};
>

... or even put in place a template mixin:

template <class T> struct DynamicallyMeasurable;

template <> struct DynamicallyMeasurable<void>
{
    virtual size_t size() = 0;
};

template <class T>
struct DynamicallyMeasurable : public DynamicallyMeasurable<void>
{
    size_t size() { return sizeof(T); }
};

class Base : public DynamicallyMeasurable<Base>
{
    ...
};

class Derived : public Base, public DynamicallyMeasurable<Derived>
{
    ...
}

Andrei (again waiting to be decapitated)
---
[ 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              ]

On 07 Feb 99 16:51:35 GMT, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

>In article <slrn7bpnn6.mdm.sbnaran@localhost.localdomain>, Siemel Naran
><sbnaran@localhost.localdomain> writes
>>>But no language extension is required. If you want the size of a
>>>polymorphic target, add a virtual function that returns the size:
>>
>>Then why did C++ add the typeid operator?  A virtual function
>>Base::typeid would have sufficed.
>
>Because an increasing number of library implementors (particularly AFX
>libraries) were simulating RTTI by slightly variant mechanisms.  That is
>a certain clue that a standardised mechanism is worth consideration.
>Not many, if any, have been providing a virtual size mechanism -
>suggesting that it is rather too specialist to be worth providing
>generally.

There's also the obvious answer that typeid works on ALL types, not
just polymorphic class types.

---
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              ]

>Personally, I can't remember ever needing to know the size of a
>non-POD object.  Perhaps you have an example or two showing this
>(presumed) need?


An object store database system.




[ 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              ]

Your previous example did not derive that deeply. The compiler will indeed
report if you omit size() from class Derived.
---
[ 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              ]

Siemel Naran wrote:
>
> On 05 Feb 99 17:10:47 GMT, Chris Minnoy <cminnoy@starlab.net> wrote:
>
> >Ever wanted to ask the size of an object? Sure you did. Ever wanted to ask
> >the size of a polymorphic type? Sure you did, but you came home form a cold
> >yourney. C++ doesn't recognizes the size of indirect virtual types. This is
> >because the size of an object is determined at compile time, and there is
> >no way for the compiler to figure out what kind of object you will be
> >dealing with at runtime. But, do we have to live wih it? I don't think so.
> >It's rather easy for a compiler to add a facility so sizeof could determine
> >the size of an object at runtime, and that's through the vtable. If the
> >compiler added an extra entry in the vtable stating the size of that object,
> >it's quite easy for sizeof just to read that entry. For non polymorphic
> >types
> >(with no vtable) the size should be determined at compile time, just like
> >it's
> >being done now.
>
> There's a thread on comp.lang.c++.moderated about this very question.
> Basically, we could have a runtime sizeof() operator.  However, this
> would make the runtime more inefficient.  It would also complicate
> the compile and link processes, although the compiler writers could
> easily deal with this.  Take a look at the thread :).

IMHO a better solution would be to give type_info a member size().
This would not give a change in the language at all, but only a
slight change in the library interface. Implementation should be
trivial, and you could rely on the properties of the typeid operator:

class X { ... };

X* x=...;

int i=sizeof(*x); // guaranteed compile time; good for templates etc.
int j=typeid(*x).size(); // determined at runtime if X polymorphic

Also note that any overhead is mainly caused by the typeid;
the simple lookup of the size in it can be made inline and
therefore cheap.
Also, the "dynamic size" of an object is related to
RTTI (it depends on the type at run time), so type_info
is the correct place to put it in even conceptionally.

[...]
---
[ 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 <lsHv2.33248$bM1.43930@newscene.newscene.com>, Al Stevens
<alstevens@midifitz.com> writes
>>And so on. This is not quite as convenient as a built-in feature,
>>because you must remember to add the size function to each
>>derived class.
>
>
>Make the Base::size function a pure virtual function and you won't need to
>remember. The compiler will remind you.

No it won't.  I wish we actually had a mechanism that required an
implementation to be provided by EVERY derived class but at present once
you derive from a derived class that provides an implementation there is
no requirement to re-implement.

Several times recently I have come up against cases where (for safety) I
need to require that every concrete derived class in a hierarchy provide
its own implementation of a virtual function.  I could live with a
comparatively high level of expertise placed on the base class
designer/implementor as long as the result would be a required
diagnostic for any derived class that breached this invariant.  Any
ideas?



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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              ]

>IMHO a better solution would be to give type_info a member size().
>This would not give a change in the language at all, but only a
>slight change in the library interface. Implementation should be
>trivial, and you could rely on the properties of the typeid operator:


I could go with that. I made a similar proposal a will ago about adding
an extra function to type_info that reports if a certain class is a
public parent of an other class. See DejaNews 1998/12/29,
extending type_info




[ 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              ]

On 9 Feb 1999 16:26:32 GMT, Francis Glassborow

>Several times recently I have come up against cases where (for safety) I
>need to require that every concrete derived class in a hierarchy provide
>its own implementation of a virtual function.  I could live with a
>comparatively high level of expertise placed on the base class
>designer/implementor as long as the result would be a required
>diagnostic for any derived class that breached this invariant.  Any
>ideas?

class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
class Derived { Derived * clone() const { return new Derived(*this); } };
class MoreDerived { };

int main()
{
   Base * b1=new Base(); // error  Base::clone() pure
   Base * b2=new Derived(); // ok
   Base * b3=new MoreDerived(); // error  MoreDerived::clone() pure
   delete b3;
   delete b2;
   delete b1;
}

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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 <3sIv2.2057$oD6.86307@burlma1-snr1.gtei.net>,
  Barry Margolin <barmar@bbnplanet.com> wrote:
> In article <lsHv2.33248$bM1.43930@newscene.newscene.com>,
> Al Stevens <alstevens@midifitz.com> wrote:
> >
> >>And so on. This is not quite as convenient as a built-in feature,
> >>because you must remember to add the size function to each
> >>derived class.
> >
> >
> >Make the Base::size function a pure virtual function and you won't need to
> >remember. The compiler will remind you.
>
> No it won't.  Consider:
>
> class Base {
>     ...
>   public:
>     size_t size() = 0;
>     ...
> }
>
> class Derived: public Base {
>     ...
>   public:
>     site_t size();
>     ...
> }
>
> class Derived_from_Derived: public Derived {
>     ...
> }
>
> There won't be any complaint if Derived_from_Derived doesn't override
> Derived::size.  But if sizeof(Derived_from_Derived) != sizeof(Derived), the
> result will be wrong.

Alright, so how about

    // This is the Abstract Base Class
    class SizeIs {
        // Assumes sizes are always static. If sizes can change
        // dynamically we must make this non-const and add a
        // method to change the size.
        const size_t m_size;
    public:
        // No default ctor. SizeIs users MUST specify the size!
        explicit SizeIs(size_t size) : m_size(size) { }
        virtual size_t size() { return m_size; }
    };

    // First derived class. Must list SizeIs as base class.
    class Derived : virtual public SizeIs {
    public:
        Derived() : SizeIs(sizeof(Derived)) { /* ... */ }
    };

    // Naive and incorrect derivation. This will fail.
    class Derived_from_Derived : public Derived {
    public:
        Derived_from_Derived() { /* ... */ }
        // Error: SizeIs::SizeIs: no appropriate default constructor available
    };

    // Legal derivation. This works.
    class Derived2 : public Derived {
    public:
        Derived2()
            : SizeIs(sizeof(Derived2)) // Must remember to initialize SizeIs!
            { /* ... */ }
    };

    // Even better, always include SizeIs as base class for consistency.
    class Derived3 : public Derived, public virtual SizeIs {
    public:
        Derived3() : SizeIs(sizeof(Derived3)) { /* ... */ }
    };

Look how much this manages: We can now implement a new STL-
compatible container such as Bag, which would be unique in
allowing different object types (all descended from SizeIs)
to be present in the same container.

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

David Tribble <dtribble@technologist.com> wrote:
>> Personally, I can't remember ever needing to know the size of a
>> non-POD object.  Perhaps you have an example or two showing this
>> (presumed) need?

Paul Black <paul@darwin.demon.co.uk> wrote:
> Writing your own allocator.

And how would this be affected by a derived type that's pointed to
by a base type pointer?  You still have to call operator new() with
the proper derived subtype specified, right?

Al Stevens wrote:
> An object store database system.

Now this one I can believe.  I can imagine handing a database store()
function a derived object via a base pointer, which would then need
to know the real size of the object.

Of course, such a function would also have to properly account for
the hidden _vtbl pointers of such objects (and possibly multiple
_vtbl pointers in the case of multiple inheritance), which would
seem to imply that the function needs more RTTI than just the
object size.

Perhaps this is a good time to suggest that C++ programs should have
type information "descriptors" or "meta-class information" available
to the program at runtime, ala SmallTalk (i.e., have runtime objects
that contain type information about all of the classes used in the
program).  Determining the true size of an object is then fairly
easy to do.

-- David R. Tribble, dtribble@technologist.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              ]

sbnaran@localhost.localdomain.COM (Siemel Naran) writes:
>On 9 Feb 1999 16:26:32 GMT, Francis Glassborow

>>Several times recently I have come up against cases where (for safety) I
>>need to require that every concrete derived class in a hierarchy provide
>>its own implementation of a virtual function.  I could live with a
>>comparatively high level of expertise placed on the base class
>>designer/implementor as long as the result would be a required
>>diagnostic for any derived class that breached this invariant.  Any
>>ideas?

>class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
>class Derived { Derived * clone() const { return new Derived(*this); } };
>class MoreDerived { };

>int main()
>{
>   Base * b1=new Base(); // error  Base::clone() pure
>   Base * b2=new Derived(); // ok
>   Base * b3=new MoreDerived(); // error  MoreDerived::clone() pure
>   delete b3;
>   delete b2;
>   delete b1;
>}

Well, there are a lot of problems with the example.

I assume you meant to
- derive Derived from Base
- derive MoreDerived from Derived
- make the member functions public.
After making those changes and changing the "==" to "=", we still
wind up with no problem creating objects of class MoreDerived:

struct Base {
  virtual ~Base() { }
  virtual Base* clone() const = 0;
};
struct Derived : Base {
  Derived* clone() const { return new Derived(*this); }
};
struct MoreDerived : Derived { }; // no clone function

int main()
{
   Base* b1 = new Base();        // error,  Base::clone() pure
   Base* b2 = new Derived();     // ok, Derived::clone() not pure
   Base* b3 = new MoreDerived(); // ok, inherit Derived::clone()
}

--
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              ]

Al Stevens wrote:
>
> Your previous example did not derive that deeply. The compiler will indeed
> report if you omit size() from class Derived.

The ability to check the size would be a lot more useful if a) it didn't
depend upon the static type of a pointer have a particular virtual
function defined, and b) it didn't depend upon the dynamic type being a
class that overode that virtual function. The suggestion to make size()
a member of the type_info class makes a lot more sense to me.
---
[ 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              ]

David R Tribble <dtribble@technologist.com> wrote:
> >> Personally, I can't remember ever needing to know the size of a
> >> non-POD object.  Perhaps you have an example or two showing this
> >> (presumed) need?
>
> Paul Black <paul@darwin.demon.co.uk> wrote:
> > Writing your own allocator.
>
> And how would this be affected by a derived type that's pointed to
> by a base type pointer?  You still have to call operator new() with
> the proper derived subtype specified, right?

What I was thinking of was this:
If you have a class where you are continuely allocating and deallocating
instances, it'll be more efficient to have class specific allocation
and deallocation routines (new & delete) and keep spare memory blocks
for the class on a linked list. These routines, however, may be called
when instantiating a derived class. The list only usefully contains
blocks that are sizeof(Base) bytes large. Any other size that is
requested (such as derived classes) should be passed to the global new.

Paul
---
[ 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              ]

Siemel Naran wrote:
>
> On 9 Feb 1999 16:26:32 GMT, Francis Glassborow
>
> >Several times recently I have come up against cases where (for safety) I
> >need to require that every concrete derived class in a hierarchy provide
> >its own implementation of a virtual function.  I could live with a
> >comparatively high level of expertise placed on the base class
> >designer/implementor as long as the result would be a required
> >diagnostic for any derived class that breached this invariant.  Any
> >ideas?
>
> class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
> class Derived { Derived * clone() const { return new Derived(*this); } };
> class MoreDerived { };

I assume that Derived was intended to be derived from Base, and that
MoreDerived was intended to be derived from Derived.

> int main()
> {
>    Base * b1=new Base(); // error  Base::clone() pure
>    Base * b2=new Derived(); // ok
>    Base * b3=new MoreDerived(); // error  MoreDerived::clone() pure

Why? Assuming that it's name means what it says, MoreDerived::clone()
will be inherited from Derived::clone(), which is not pure. That's
precisely what Francis is trying to avoid.
---
[ 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              ]

AllanW@my-dejanews.com wrote:
>
> In article <3sIv2.2057$oD6.86307@burlma1-snr1.gtei.net>,
>   Barry Margolin <barmar@bbnplanet.com> wrote:
> > In article <lsHv2.33248$bM1.43930@newscene.newscene.com>,
> > Al Stevens <alstevens@midifitz.com> wrote:
> > >
> > >>And so on. This is not quite as convenient as a built-in feature,
> > >>because you must remember to add the size function to each
> > >>derived class.
> > >
> > >
> > >Make the Base::size function a pure virtual function and you won't need to
> > >remember. The compiler will remind you.
> >
> > No it won't.  Consider:
> >
> > class Base {
> >     ...
> >   public:
> >     size_t size() = 0;
> >     ...
> > }
> >
> > class Derived: public Base {
> >     ...
> >   public:
> >     site_t size();
> >     ...
> > }
> >
> > class Derived_from_Derived: public Derived {
> >     ...
> > }
> >
> > There won't be any complaint if Derived_from_Derived doesn't override
> > Derived::size.  But if sizeof(Derived_from_Derived) != sizeof(Derived), the
> > result will be wrong.
>
> Alright, so how about
>
>     // This is the Abstract Base Class
>     class SizeIs {
>         // Assumes sizes are always static. If sizes can change
>         // dynamically we must make this non-const and add a
>         // method to change the size.
>         const size_t m_size;
>     public:
>         // No default ctor. SizeIs users MUST specify the size!
>         explicit SizeIs(size_t size) : m_size(size) { }
>         virtual size_t size() { return m_size; }
>     };

So every object derived from SizeIs carries around the baggage of it's
own size information, which is class-level information, not
object-level. What's more, it wastes time initializing it during
construction. Also, you're relying on the derived classes initilizing it
correctly. It doesn't need to be that expensive or unreliable! Providing
the information through a type_info::size() function would be much
cheaper.
---
[ 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              ]

Al Stevens <alstevens@midifitz.com> writes:

>Your previous example did not derive that deeply. The compiler will indeed
>report if you omit size() from class Derived.

Evidently you missed the "and so on," implying further derivation.

--
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              ]

On 9 Feb 1999 21:44:27 GMT, Steve Clamage <stephen.clamage@sun.com> wrote:
>sbnaran@localhost.localdomain.COM (Siemel Naran) writes:

>>class Base { virtual ~Base() {}  virtual Base * clone() const == 0; };
>>class Derived { Derived * clone() const { return new Derived(*this); } };
>>class MoreDerived { };
>
>>int main()
>>{
>>   Base * b1=new Base(); // error  Base::clone() pure
>>   Base * b2=new Derived(); // ok
>>   Base * b3=new MoreDerived(); // error  MoreDerived::clone() pure


>Well, there are a lot of problems with the example.
>
>I assume you meant to
>- derive Derived from Base
>- derive MoreDerived from Derived
>- make the member functions public.

Yes (my mistake).
Yes (my mistake).
Yes (but this is beside the point).

>After making those changes and changing the "==" to "=", we still
>wind up with no problem creating objects of class MoreDerived:

No, the "==" was deliberate.  It's a new hypothetical language
feature.  It means that the function is super pure virtual, which
basically means that concrete classes have to instantiate it.
Previously, on comp.lang.c++.moderated I used "%".

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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              ]

Ever wanted to ask the size of an object? Sure you did. Ever wanted to ask
the size of a polymorphic type? Sure you did, but you came home form a cold
yourney. C++ doesn't recognizes the size of indirect virtual types. This is
because the size of an object is determined at compile time, and there is
no way for the compiler to figure out what kind of object you will be
dealing with at runtime. But, do we have to live wih it? I don't think so.
It's rather easy for a compiler to add a facility so sizeof could determine
the size of an object at runtime, and that's through the vtable. If the
compiler added an extra entry in the vtable stating the size of that object,
it's quite easy for sizeof just to read that entry. For non polymorphic
types
(with no vtable) the size should be determined at compile time, just like
it's
being done now.
I think this would have great benefits.

Chris

cminnoy@starlab.net
http://www.starlab.org
---
[ 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              ]

On 05 Feb 99 17:10:47 GMT, Chris Minnoy <cminnoy@starlab.net> wrote:

>Ever wanted to ask the size of an object? Sure you did. Ever wanted to ask
>the size of a polymorphic type? Sure you did, but you came home form a cold
>yourney. C++ doesn't recognizes the size of indirect virtual types. This is
>because the size of an object is determined at compile time, and there is
>no way for the compiler to figure out what kind of object you will be
>dealing with at runtime. But, do we have to live wih it? I don't think so.
>It's rather easy for a compiler to add a facility so sizeof could determine
>the size of an object at runtime, and that's through the vtable. If the
>compiler added an extra entry in the vtable stating the size of that object,
>it's quite easy for sizeof just to read that entry. For non polymorphic
>types
>(with no vtable) the size should be determined at compile time, just like
>it's
>being done now.

There's a thread on comp.lang.c++.moderated about this very question.
Basically, we could have a runtime sizeof() operator.  However, this
would make the runtime more inefficient.  It would also complicate
the compile and link processes, although the compiler writers could
easily deal with this.  Take a look at the thread :).

Besides, a compile time sizeof(...) is firmly entrenched in the
language.

An implementation may indeed store the sizeof of a polymorphic
object in the virtual table.  Then a call
   delete base;
translates to
   base->~Base(); // calls derived class destructor
   Base::operator delete(base->vptr->size);

Unfortunately, a call
   sizeof(*base)
returns sizeof(Base).  Ie, it does not look at the dynamic type
of 'base'.  It would be nice if C++ required sizeof(*base) to look
at the dynamic type of base.  Now if we want the size of the
static type of base, we just ask for sizeof(Base); if we want the
size of the dynamic type of base, we ask for sizeof(*base).
This parallels the case for typeid.
   typeid(NonPolymorphicVariable); // must be evaluated at compile time
   typeid(   PolymorphicVariable); // must be evaluated at run     time
Hence
   sizeof(NonPolymorphicVariable); // must be evaluated at compile time
   sizeof(   PolymorphicVariable); // must be evaluated at run     time

Finally, sizeof(NonPolymorphicVariable) is an integral constant
whereas sizeof(PolymorphicVariable) is not.


>I think this would have great benefits.

This is the most important question.  What practical problems does
it solve?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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              ]