🚀 go-pugleaf

In article <lkc2k7INNajv@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes:
>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?  

	A decent solution could have been had except for the
extremely unfortunate (IMHO) decision that 'struct' and 'class'
are synonymous (except for public/private defaults).

	For example, how about:

	generate X::X(const X&);

This could only apply to classes and not 'C' structs for compatibility
reasons.

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

	Not possible for C-Structs, compiler MUST automagiocally
generate constructors and assignment for these.

	Want to modify (2a) to include 'with virtual functions'?

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

	You do NOT want to have to write the code. Explicit
direction to the compiler to generate the code may be acceptable.

	generate X& operator=(const X&);

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

	Not compatible with C.

	Personally, I'd like to ban virtual functions from
'structs' and insist structs worked as they do in C.
Also allows nested structs to be globally visible, as in C.

	The classes could be distinct and have different rules.
But it is too late for this.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------