[comp.lang.c++] virt base c'tor -- my error or CC bug?

tuck@jason.cs.unc.edu (Russ Tuck) (01/23/90)

I think I've found a bug in the AT&T C++ 2.0 compiler, cfront, but I'm 
willing to be shown the error in my code.  On p. 82, section 12.6.2, of
the C++ (2.0) Reference Manual (AT&T select code 307-146), it says:
"All sub-objects for virtual base classes are initialized by the constructor
of the most derived class.  If a constructor of the most derived class
does not specify a mem-initializer for a virtual base class then that
virtual base class must have a default constructor or no constructors."

The example in the manual following the quote above shows the case of
no mem-initializer in the most derived class's constructor, where the
virtual base class has a default constructor.  I would like to use the
other case described in the quote: a mem-initializer in the most derived
class's constructor and no default initializer in the virtual base class.
Here's a trivial example program showing this case.

  class V { public: V(int); };

  class A : public virtual V { public: A(); };

  A::A() : V(1) {}

  V v(1);
  A a;

CC (cfront 2.0, running on any of Sun4, DEC 3100, VAX 785) gives these 
error messages when compiling the above code:

CC  t.c:
"t.c", line 3: error: virtual base V has no default initializer
"t.c", line 5: error: unexpected argument list: no base class V 
2 errors

Is there something wrong with this code, or is this indeed a compiler bug?

Russ Tuck		               tuck@cs.unc.edu
UNC Dept. of Computer Science          ...!mcnc!unc!tuck
CB 3175, Sitterson Hall
Chapel Hill, NC 27599-3175, USA        (919) 962-1755 or 962-1700

tuck@jason.cs.unc.edu (Russ Tuck) (01/23/90)

In article <11582@thorin.cs.unc.edu> tuck@jason.cs.unc.edu (Russ Tuck) writes:
>I think I've found a bug ...
>Here's a trivial example program showing this case.
>
>  class V { public: V(int); };
>
>  class A : public virtual V { public: A(); };
>
>  A::A() : V(1) {}
>
>  V v(1);
>  A a;
>
>CC (cfront 2.0, running on any of Sun4, DEC 3100, VAX 785) gives these 
>error messages when compiling the above code .....

I've found what appears to be a good work-around to this problem:
adding a private default constructor to class V.  This gets rid of the
error messages, but should not change V's public or protected interfaces
because the added c'tor is private.  Here's the revised code.

class V { private: V(); public: V(int); };

class A : public virtual V { public: A(); };

A::A() : V(1) {}

V v(1);
A a;

CC (cfront 2.0) compiles this without giving errors or warnings.
(Of course, it won't link without defining V's methods.)
 
Russ Tuck		               tuck@cs.unc.edu
UNC Dept. of Computer Science          ...!mcnc!unc!tuck
CB 3175, Sitterson Hall
Chapel Hill, NC 27599-3175, USA        (919) 962-1755 or 962-1700

vinoski@apollo.HP.COM (Stephen Vinoski) (01/24/90)

In article <11582@thorin.cs.unc.edu> tuck@jason.cs.unc.edu (Russ Tuck) writes:
>I think I've found a bug in the AT&T C++ 2.0 compiler, cfront, but I'm 
>willing to be shown the error in my code.  On p. 82, section 12.6.2, of
>the C++ (2.0) Reference Manual (AT&T select code 307-146), it says:
>"All sub-objects for virtual base classes are initialized by the constructor
>of the most derived class.  If a constructor of the most derived class
>does not specify a mem-initializer for a virtual base class then that
>virtual base class must have a default constructor or no constructors."
>
>Here's a trivial example program showing this case.
>
>  class V { public: V(int); };
>
>  class A : public virtual V { public: A(); };
>
>  A::A() : V(1) {}
>
>  V v(1);
>  A a;

From Lippman's "C++ Primer", Addison-Wesley, ISBN 0-201-16487-6, page 363:

"A base class specified as virtual must, if it defines any constructors, define
a constructor that does not require an argument list - either a constructor
taking no arguments or one in which default value is provided for each
argument."


-steve

P.S.  IMHO Lippman's "C++ Primer" is the best C++ book going.  If you don't have
it you should get a copy.


| Steve Vinoski                                                                |
| Hewlett-Packard Apollo Division, Testability and Diagnostics Dept.           |
| Chelmsford, MA    01824    (508)256-6600 x5904                               | 
| Internet: vinoski@apollo.com UUCP: {mit-eddie,yale,uw-beaver}!apollo!vinoski |

tuck@zeta.cs.unc.edu (Russ Tuck) (01/24/90)

In article <48359bd1.20b6d@apollo.HP.COM> vinoski@zep.UUCP (Stephen Vinoski) writes:
>In article <11582@thorin.cs.unc.edu> tuck@jason.cs.unc.edu (Russ Tuck) writes:
>>On p. 82, section 12.6.2, of the C++ (2.0) Reference Manual (AT&T select 
>>code 307-146), it says:
>>
>>"All sub-objects for virtual base classes are initialized by the constructor
>>of the most derived class.  If a constructor of the most derived class
>>does not specify a mem-initializer for a virtual base class then that
>>virtual base class must have a default constructor or no constructors."
>
>From Lippman's "C++ Primer", Addison-Wesley, ISBN 0-201-16487-6, page 363:
>
>"A base class specified as virtual must, if it defines any constructors, define
>a constructor that does not require an argument list - either a constructor
>taking no arguments or one in which default value is provided for each
>argument."

Thanks for pointing out a clear contradiction between these two authoritative
references.  I thought the Reference Manual (by Stroustrup) was the ultimate
authority, but here Lippman is in better agreement with the compiler.
(Which is "right" is another question.  Would the authors care to say?)

In contrast, GNU's C++ compiler, g++, corresponds to the Reference Manual,
rather than to Lippman and cfront.
 
>P.S.  IMHO Lippman's "C++ Primer" is the best C++ book going.  If you don't have
>it you should get a copy.

I have it.  I hadn't consulted it in this case, because what I found in
the Reference Manual spoke so directly to the issue.  But when I looked 
at p. 363, I found your quote above already marked with faded highlighter.  
(The book hasn't been in print for a year yet, so my marker must be cheap
and my memory less than perfect.)

Russ Tuck		               tuck@cs.unc.edu
UNC Dept. of Computer Science          ...!mcnc!unc!tuck
CB 3175, Sitterson Hall
Chapel Hill, NC 27599-3175, USA        (919) 962-1755 or 962-1700