🚀 go-pugleaf

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> I would like to propose that if a class has virtual functions,
> then any destructor generated by the compiler will be virtual
> by default.

Hmmm ... given that I've never seen such nonvirtual destructors be
anything except bug, I like the idea of fixing this problem.

On the other hand, one of the things I'd really like to see changed is
how much stuff a C++ compiler does "for me" automagically.  It's a rare
day when it really does what I need to have done; just how often is
memory management broken when pointers "owned" by class instances are
bitwise copied?  Arguments I've heard against automagic generation of 
code by the C++ compiler seem to fall into three categories:

    -	Memory management bugs get trivially introduced, both in the
	initial implementations and during subsequent maintainence;

    -	Declaring automagic routines as 'private', with implementations
	that abort, to prevent assigning/copying data structures that
	shouldn't be support those operations (due to various expenses,
	or to design desiderata) is really ugly, and consumes both
	coding and runtime resources;

    -	It's confusing both to beginning and to expert programmers
	(e.g. C ones who are "upgrading" to C++) that private data
	structures be manipulated (and bugs added) by compilers.

So, a pair of proposals that I'd be happier to see accepted:

   (1)	It is an error for a class to have virtual functions and a
	nonvirtual destructor.
	
   (2a)	C++ compilers don't automagically generate ANYTHING for classes
	any more:  constructors, destructors, assignment and address-of
	operators, etc.  If such routines are used but not declared and
	defined, that is an error.

Or in short, if you want to allow copying, destruction, assignment,
and so on for instances of your classes, you'll have to explicitly
provide member functions to support those actions in the interface
definitions (and implementation bodies) for your classes.

Perhaps the specific issues with memory management could be fixed by
the alternate proposal below:

   (2b)	C++ compilers don't automagically generate those routines
	(complete list omitted :-) for classes that have members which
	are pointers or references.  If such routines are used but
	not declared and defined, that is an error.

Existing code compiled with a compiler enforcing (2a) or (2b) would
generate error messages; fixing that code and then recompiling it with
today's compilers (e.g. CFRONT) would not cause any problems at all.

Comments?

- Dave

--
David Brownell                        db@Eng.Sun.COM.
Distributed Object Management