In article <1993Jul21.160523.470@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) writes:
|> "Bradley D. Keister" <keister@poincare.phys.cmu.edu> writes:
|>
|> >I have a class hierarchy which starts with a base class, is inherited
|> >virtually by two separate branches, and then the branches are brought
|> >together by multiple inheritence for the class used in the
|> >application.  Some pure virtual functions are declared in the base
|> >class which are all eventually defined along one branch, but not the
|> >other.  For the (multiply inherited) class I use, all functions are
|> >therefore defined and unambiguous.
|>
|> >g++ 2.4.5
|> >compiles successfully and the program performs as expected.  For
|> >cfront 3.1, however, the test program gives a compile-time error,
|> >claiming that the final class is abstract; the actual application
|> >compiles, but the executable gives segmentation faults.
|>
|> The ARM, 10.3,  pg 215  says: "Pure virtual functions are inherited as
|> pure virtual functions."

  While this is true, the pure-virtuals are not inherited in this
arrangement.  The implementation branch of the "virtual-base-diamond"
declares the virtual as not pure.  This name declaration dominates
the name declaration at the top of the diamond.  Thus the pure-virtual
is not inherited.



|>
|> So, it would appear that cfront should indeed be complaining since the
|> purity of the virtual functions is being inherited.  I have
|> cross-posted this to comp.std.c++ so that the standards gurus can
|> comment on any changes to this policy.  In the meantime, if you remove
|> the pure specifiers from the functions in the virtual base, your
|> problems should go away.  If you want the virtual base to be abstract,
|> then you can make its destructor pure virtual (which is *not*
|> inherited), or make the constructors protected.
|> --
|> Robert Martin       | Design Consulting   | Training courses offered:
|> Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
|> 2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
|> Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <1993Jul21.160523.470@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>"Bradley D. Keister" <keister@poincare.phys.cmu.edu> writes:
>
>>I have a class hierarchy which starts with a base class, is inherited
>>virtually by two separate branches, and then the branches are brought
>>together by multiple inheritence for the class used in the
>>application.  Some pure virtual functions are declared in the base
>>class which are all eventually defined along one branch, but not the
>>other.  For the (multiply inherited) class I use, all functions are
>>therefore defined and unambiguous.
>
>>g++ 2.4.5
>>compiles successfully and the program performs as expected.  For
>>cfront 3.1, however, the test program gives a compile-time error,
>>claiming that the final class is abstract; the actual application
>>compiles, but the executable gives segmentation faults.
>
>The ARM, 10.3,  pg 215  says: "Pure virtual functions are inherited as
>pure virtual functions."
>
>So, it would appear that cfront should indeed be complaining since the
>purity of the virtual functions is being inherited.

 No, cfront 3.0.1 is bugged. The bug is fixed in 3.0.2.
The wording of the section on abstract classes is sloppy and needs
to be fixed. A class is abstract if, and only if, a virtual
call(**) might invoke a pure virtual function. If all the pure virtuals
are overridden, the class is concrete.

**Invoked after the constructor body of the most complete class
is entered, and before destruction commences.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

"Bradley D. Keister" <keister@poincare.phys.cmu.edu> writes:

>I have a class hierarchy which starts with a base class, is inherited
>virtually by two separate branches, and then the branches are brought
>together by multiple inheritence for the class used in the
>application.  Some pure virtual functions are declared in the base
>class which are all eventually defined along one branch, but not the
>other.  For the (multiply inherited) class I use, all functions are
>therefore defined and unambiguous.

>g++ 2.4.5
>compiles successfully and the program performs as expected.  For
>cfront 3.1, however, the test program gives a compile-time error,
>claiming that the final class is abstract; the actual application
>compiles, but the executable gives segmentation faults.

The ARM, 10.3,  pg 215  says: "Pure virtual functions are inherited as
pure virtual functions."

So, it would appear that cfront should indeed be complaining since the
purity of the virtual functions is being inherited.  I have
cross-posted this to comp.std.c++ so that the standards gurus can
comment on any changes to this policy.  In the meantime, if you remove
the pure specifiers from the functions in the virtual base, your
problems should go away.  If you want the virtual base to be abstract,
then you can make its destructor pure virtual (which is *not*
inherited), or make the constructors protected.
--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++