🚀 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.
>
>Advantages: much safer, ensures correct deletion of objects
>by default.  Removes a source of bugs. Removes the reminder
>that its wise to do this from the FAQ.
>
>Disadvantage: might slow down destruction a little. Can be
>fixed by the programmer explicitly declaring a non-virtual
>destructor.

I think that this situation should cause a compiler warning, rather
than adding another arbitrary rule in the language for programmers to
remember. Bugs would still occur if a programmer accidentally forgot to
make the destructor virtual. A good compiler will generate a warning
in this situation anyway (eg. g++ does, I believe).

Mind you, I do believe that there is a place in the standard for
required warnings. Claims that these are a "quality of implementation"
issue ignore the social effect of standards. There are never *any*
genuinely 100% conformant compilers, no matter what it says on the
box you bought it in. (Read the fine print on the license inside :-( ). 
The truth is that standards provide a strong incentive for compiler
vendors to ship products with certain characteristics. Provided (as
with all other aspects of a standard) that they don't require an
excessive difficulty of implementation, I don't see any good reason
not to include particular required warnings as part of a standard.

[Off the topic, another situation that should have a required warning
is the (void *) to (T *) conversion. It is definitely a hole in the
type system, but making such conversion *illegal* breaks many C programs.
It broke ALL of my C programs (well, ok, except for the hello world ones :-).
A warning would have closed the hole in the type system just as well -
after all, programmers can always achieve the same effect with a cast,
so it doesn't actually "close" the hole anyway - the error message is
just like a warning, except that you have to actually modify the
program text to get it to compile.]

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

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

In article <9300301.307@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) 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.
>>
>>Advantages: much safer, ensures correct deletion of objects
>>by default.  Removes a source of bugs. Removes the reminder
>>that its wise to do this from the FAQ.
>>
>>Disadvantage: might slow down destruction a little. Can be
>>fixed by the programmer explicitly declaring a non-virtual
>>destructor.
>
>I think that this situation should cause a compiler warning, rather
>than adding another arbitrary rule in the language for programmers to
>remember. 

	What arbitrary rule? Do you mean the rule that says
automatically generated destructors are *non-virtual* :-) ??

	The point here is that the forgetful programmer is protected.

>[Off the topic, another situation that should have a required warning
>is the (void *) to (T *) conversion. 


	void *x;
	T* t;
	t=x; // error here, no mere warning
	t=(T*)x; // warning inserted by programmer in the form of (T*)
	t=reinterpret_cast<T*>x; // grepable warning 

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

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

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

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

How about a new keyword "__pure" to
	1)	prefix "class" in a class definition to stop automagic
		constructor + assignment generation ++
	2)	prefix "virtual" in a pure virtual function
		declaration to get rid of the "=0" hack
	3)	waste some of the compiler implementor's name space
		(rather the the compiler user's name space). The
		user can #define pure __pure if it causes no problem


Doug Gilbert

In article <1992Dec31.050150.28929@ucc.su.OZ.AU> 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.
>
>(The suggestion was first read by me in a paper of Markku Sakkinen,
>who claims it was not his idea originally either.)
>
>Advantages: much safer, ensures correct deletion of objects
>by default.  Removes a source of bugs. Removes the reminder
>that its wise to do this from the FAQ.

This would be a way in which a function within the source code would be
virtual without the keyword 'virtual' having been used on it or a function of
the same name in an inherited class.  That would bother me as a consistency 
issue.

>Disadvantage: might slow down destruction a little. Can be
>fixed by the programmer explicitly declaring a non-virtual
>destructor.

The only way to make something explicity non-virtual would be the absence
of the 'virtual' keyword, unless we add a new keyword <shudder>.

If the destructor is going to be made virtual by that rule, there is no
need to declare it virtual.  But we can not make it explicitly non-virtual
unless the virtual keyword is an option.


Michael Feathers  [feathers@fiu.edu]      main () { main (); }

In article <C0Ayt4.263@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
|> In article <1992Dec31.050150.28929@ucc.su.OZ.AU> 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.
|> >
[...]

|> This would be a way in which a function within the source code would be
|> virtual without the keyword 'virtual' having been used on it or a function of
|> the same name in an inherited class.  That would bother me as a consistency 
|> issue.

I think you misread the original post.  Only the automagically generated 
destructors would be virtual by default.  If the programmer explicity
defined a destructor _without_ the virtual keyword, it would not be virtual
(unless _I_ misread the post  :).

|> 
|> >Disadvantage: might slow down destruction a little. Can be
|> >fixed by the programmer explicitly declaring a non-virtual
|> >destructor.
|> 
|> The only way to make something explicity non-virtual would be the absence
|> of the 'virtual' keyword, unless we add a new keyword <shudder>.

Again, see comment above.

					-=Dave

In article <C0Ayt4.263@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>In article <1992Dec31.050150.28929@ucc.su.OZ.AU> 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.
>>
>>(The suggestion was first read by me in a paper of Markku Sakkinen,
>>who claims it was not his idea originally either.)
>>
>>Advantages: much safer, ensures correct deletion of objects
>>by default.  Removes a source of bugs. Removes the reminder
>>that its wise to do this from the FAQ.
>
>This would be a way in which a function within the source code would be
>virtual without the keyword 'virtual' having been used on it or a function of
>the same name in an inherited class.  That would bother me as a consistency 
>issue.

	Yes. But it is also a way to have a virtual function which
is NOT in the source code at all. Worse, it only applies
if the base class already has at least one virtual function.

>
>>Disadvantage: might slow down destruction a little. Can be
>>fixed by the programmer explicitly declaring a non-virtual
>>destructor.
>
>The only way to make something explicity non-virtual would be the absence
>of the 'virtual' keyword, unless we add a new keyword <shudder>.

	Yes, just define a destructor in the base class without
the keyword virtual.
>
>If the destructor is going to be made virtual by that rule, there is no
>need to declare it virtual.  But we can not make it explicitly non-virtual
>unless the virtual keyword is an option.

	Sure we can:

	class X { virtual fred(); } // has a virtual destructor
	class Y { virtual fred(); ~Y(){} }; // non-virtual destructor

The rule only applies to compiler generated destructors.

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

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

The problem with this is that struct == class with all members public.
This would break much C code.
Better would be for the compiler not to generate default stuff
if _any_ constructor or destructor (or op=) is declared for a class;
elsewise, generate if nec.

db@argon.Eng.Sun.COM (David Brownell) writes:

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


I like this! Compilers could have "compatibility" switches, but for 
those of us who would rather do it ourselves, we could use the
full strength version.

I think I would feel a lot better about my C++ compiler if I didn't
have to make a copy-ctor private/unimplemented (as a safegaurd) just
because I was afraid that I *might* be accidentally copying an object.
It would be much better if the compiler simply said it was an error
to copy without a copy-ctor (or whatever), then the programmer can:

1) remove the need to copy
2) install the proper method to do the copy

This goes for all the other automagic stuff too! I cringe when I 
think about automagically adding virtual destructors, even though
they are most times needed...



-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599

In <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

>db@argon.Eng.Sun.COM (David Brownell) writes:

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

	A warning, perhaps.

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

	Would break a large part of th the world (like all struct declarations
	for starters; see below).

>I think I would feel a lot better about my C++ compiler if I didn't
>have to make a copy-ctor private/unimplemented (as a safegaurd) just
>because I was afraid that I *might* be accidentally copying an object.
>It would be much better if the compiler simply said it was an error
>to copy without a copy-ctor (or whatever), then the programmer can:

>1) remove the need to copy
>2) install the proper method to do the copy

>This goes for all the other automagic stuff too! I cringe when I 
>think about automagically adding virtual destructors, even though
>they are most times needed...

	Another case for protecting programmers from themselves.  For:

		struct Point {
			int x, y;
		};

	I don't want to have to write a ctor and assign-op. especially
	when the generated ones would work perfectly.

	Whenerver one writes a class, one *has* to ask onesself: Do I
	need a ctor?  An assign-op?  One should have to ask onesself
	this regardless of whether the compiler did the default ones
	for one or not.  If one doesn't, then one is just careless.

	The default stuff is for convenience.  In my experience, and I
	would venture others', it's rare to have to forbid copy/assign
	anyway.  Unless you have a good reason to forbid them, who cares?
	Let users copy them.
-- 
	- Paul J. Lucas
	  AT&T Bell Laboratories
	  Naperville, IL

In article <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

> I like this! Compilers could have "compatibility" switches, but for 
> those of us who would rather do it ourselves, we could use the
> full strength version.

The trouble with compatibility switches is that they force people
who care about portability to write in the intersection of the language
accepted in the two modes.
-- 
				--Andrew Koenig
				  ark@europa.att.com

In article <lm0gudINN9be@exodus.Eng.Sun.COM>, chased@rbbb.Eng.Sun.COM (David Chase) writes:
|> In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
|> >On the subject of "trampolenes" in the implementation of nested functions, this 
|> >presumably means the following appraoch:
|> 
|> > [code generation into stack frame, which works.]
|> > ... The main objection I can see is that on some operating systems
|> >you are not allowed to do any run-time code generation.
|> 
|> One workaround is to keep a cache of trampolines, which in this case
|> are pairs of code+data, where each piece of code is compiled to
|> reference a particular piece of data.  Some run-time code generation
|> must still occur.  In the limit case (the least flexible OSes) a
|> different calling convention must be used for all function calls.

As you say, the cache appraoch still involves generating code on the fly, 
or making the function pointer data type more complex (impacting all cases) 
and changing the procedure call convention.
|> 
|> >Other people talk about "bound" functions which presumably means that
|> >given an object a of class A with member function f, then "a.f" can be
|> >regarded as a new function (whose pointer can be taken) with a non
|> >member-function signature.  The only way I can see of using a
|> >trampolene appraoch for this situation is to place the trampolene for
|> >the function a.f into the object a itself.
|> 
|> Actually, you could "new" them.  Just allocate the functions on the
|> "heap", and free them when you are done.  Or, we could take a flying
|> leap at the slippery slope and add garbage collection.

Again, as you say, you have to free them "when you are done", but in 
this situation, there is no natural idea of "when you are done". In 
fact, whereas the natural lifetime of a nested function is until the 
containing function completes, the natural lifetime of a bound function 
is until the destruction of the object to which it is bound. How do you 
ensure that whenever an object dies, that bound function trampolenes 
which *might* have been generated for it are deleted? (Bearing in mind 
that the object may not otherwise need any destructor and may not have 
any virtual functions at all).

|> >This surely makes member function closures an impracticable and
|> >unworkable addition to the language?
|> 
|> I think the answer is another question: "compared to what?"  I'm
|> really looking forward to run-time instantiation of templates.

I can see no way that the solution can be implemented in a way that 
doen't impact the normal performance of the system. The only way I 
can see round this is to add something to the syntax of the language 
to indicate "this member function might be bound" at the point of 
declaration. To me, this is unacceptable.

None of this detracts from the fact that *nested* functions *can* be 
implemented without impacting on the normal performance of the system, 
and without requiring any special new constructs in the language (more 
a relaxation of a rule). What's more, they are extremely valid for 
situations where iterators are used for many general call-back 
mechanisms which are considerably more awkward (or unsafe) when done 
using one of the manual alternatives.

Moreover, if nested functions are implemented, they imply an easy 
manual solution to many cases where bound member functions might have 
been required. Other cases where bound member functions might be 
required can surely be solved through abstract base classes and in some 
cases MI.

|> 
|> David Chase
|> Sun

ark@alice.att.com (Andrew Koenig) writes:

>In article <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

>> I like this! Compilers could have "compatibility" switches, but for 
>> those of us who would rather do it ourselves, we could use the
>> full strength version.

>The trouble with compatibility switches is that they force people
>who care about portability to write in the intersection of the language
>accepted in the two modes.

Would this apply if the "compatibility mode" was phased out over time?
In a similar manner to how C vendors gradually migrated to ANSI C?



-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599

In article <harvey.727978914@regina> harvey@opl.com (Harvey Reed) writes:

> Would this apply if the "compatibility mode" was phased out over time?
> In a similar manner to how C vendors gradually migrated to ANSI C?

Yes.  While the "compatibility mode" is being phased out, I still
have to write in the intersection of the two languages, until the
old one is well and truly gone.
-- 
				--Andrew Koenig
				  ark@europa.att.com