RE: Is this a bug for gcc (2.95 and 3.1)?

[Bernard Dautrevaux <Dautrevaux at microprocess dot com>]

> -----Original Message-----
> From: Matthias Benkmann [mailto:matthias@winterdrache.de]
> Sent: Saturday, May 25, 2002 10:01 PM
> To: gcc@gcc.gnu.org
> Subject: Re: Is this a bug for gcc (2.95 and 3.1)?
> 
> 
> On Fri, 24 May 2002 03:29:09 +0000 "Mitchell Maggie"
> <maggie_shh@hotmail.com> wrote:
> 
> > HI,All:
> > There are two problem about g++.
> > OS:
> > CYGWIN_NT-5.0 MAGGIE 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown

	<skipped>

> > 2:This program will cause gcc3.1 link error ,but passed by gcc2.95
> > //code begin
> > #include <stdio.h>
> > class A
> > {
> > public:
> >   virtual ~A()=0;
> > //      {
> > //      };
> > };
> > A::~A()
> > {
> > }
> > class B:public A
> > {
> > };
> > 
> > int main()
> > {
> > B b;
> > return 1;
> > };
> > //code ends
> > 
> 
> 
> Hmm. This one is more difficult. I believe it is incorrect 
> according to
> the standard:
> 
> "10.3  Virtual functions" states in paragraph 8 that
> 
> "8 A virtual function declared in a class shall be defined,  
> or  declared
>   pure  in that class, or both;"
> 
> So it is permissible for a pure virtual function to have a definition
> (although not inline because the grammar forbids it). However, the
> function is still pure virtual even if a definition is 
> provided, because
> ("10.4 Abstract classes" paragraph 2)
> 
> "A virtual function is specified pure
>   by using a pure-specifier  in the function declaration in
>   the class declaration."
> 
> 
> And as a consequence in the above example the class A is 
> abstract, because
> (same paragraph):
> 
> "A class is abstract
>   if  it has at least one pure virtual function."
> 

So far, so good

> 
> Now the important part: Class B is abstract, too, because 
> (10.4 paragraph
> 4):
> 
> "4 A  class is abstract if it contains or inherits at least 
> one pure vir-
>   tual function for which the final overrider is pure  virtual."

Here I have a small problem: constructors can be overridden, but not
inherited. So Class B does not inhertit the pure virtual destructor...

> 
> 
> Class B does not override the pure virtual destructor so the final
> overrider is A::~A(). Nitpickers see "10.3  Virtual 
> functions" paragraph
> 2: 
> 
> "For convenience we say that any virtual function overrides 
> itself.  Then
> in any well-formed class,  for  each virtual function declared in that
> class or any of its direct  or indirect base classes there is a unique
> final overrider [..]"
> 
> and also paragraph 4 
> 
> "4 Even  though  destructors are not inherited, a destructor 
> in a derived
>   class  overrides  a  base  class  destructor  declared  virtual;"
> 
> So destructors do really have final overriders.

Here I have another problem; even if the destructor is not defined
explicitely, it seems that as there is a virtual destructor the compiler
must synthesize a destructor, and so there *seems to be* an overriding
destructor...

See 12.4 §3:
	"If a class has no userdeclared destructor, a destructor is declared
implicitly. An
	"implicitly declared destructor is an inline public member of its
class."

and §5:
	"An implicitly declared destructor is implicitly defined when it is
used to destroy 
	"an object of its class type

So there is a final overrider for A::~A, which is the implicitely declared
and defined B::~B, so B seems NOT to be abstract...

> Okay, now that we have established that class B is an 
> abstract class, we
> can look at "10.4  Abstract classes" again and in paragraph 2 we see:
> 
> "no  objects  of  an abstract class can be created
>   except as sub-objects of a class derived from it."

If I'm right above this does not apply, and so GCC-3.1 is in error.

        Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
--------------------------------------------