🚀 go-pugleaf

parker@WPI.EDU (Chris Parker) writes:
	...
>    The only disadvantage of this is there is price to pay at runtime when 
>freeing the object because we need to find the destructor function through 

And a space cost that can be huge.

>dynamic binding.  So, I propose that if that if at any point in a class
>heirarchy tree a destructor is declared virtual, all destructors in the tree
>are virtual because that is really what you are trying to ask for.  What
>do you think?

Consider:

class Point {
  unsigned short x, y;
public:
  // nonvirtual methods
};

I want my compiler to stick that in 4 bytes and move it around in
registers, of course.  Now, you want to make it carry the weight
of a _vptr_ *just in case* somebody does:

	class VPoint: public Point {public: virtual ~VPoint();}

and

	Point *p=new VPoint;
	//...
	dispose(p);

where "dispose(Point *)" is a function written and compiled far
in advance of anybody dreaming up VPoint, which at the end does
"delete p;"?

In other words, can the compiler, separately compiling dispose()
into a library-resident object before anybody ever inherited
from Point, "know" that Point's dtor is nonvirtual, or does it
have to fear that it can "change from under it" unexpectedly,
and therefore must always take a vptr from somewhere inside Point?

A pointer is 8 bytes on Alpha.  Do you realize your proposal
may require a 200% space overhead on this class, or doing
without separate compilation altogether?

The philosophy of C++: if somebody does not use a feature, they
must pay no price whatsoever for the mere existence of that
feature.  It can't be followed 100%, but it's a good guiding
principle, and IMHO it has served the language pretty well.


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]