rfg@netcom.com (Ronald F. Guilmette) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>evan@hplerk.hpl.hp.com (Evan Kirshenbaum) writes:
>>>we get the following error:
>>>
>>>    declaration of object of abstract class struct B1 - pure virtual
>>>    function(s) A::f() have not been defined
>>>
>>>According to the ARM (p 205-6), A1::f() dominates A::f() for B1, but
>>>the compilers (cfront and HP C++) seem to think that it has to be
>>>defined on *all* paths.
>>>
>>>So, are the compilers broken?
>>
>>Yes.  Complain to your vendors.
>
>I don't suppose you would care to try to justify that answer, would you?

No - but you don't give me much choice ;-)

According to ARM 10.3,

| A class is abstract if it has at least one _pure virtual function_.
| A virtual function is specified _pure_ by using a _pure-specifier_
| (9.2) in the function declaration in the class declaration.
| ...
| Pure virtual functions are inherited as pure virtual functions.
| For example,
|  class ab_circle : public shape {
|      int radius;
|  public:
|      void rotate(int) {}
|      // ab_circle::draw() is a pure virtual
|  };

Now the comment in the example is somewhat nonsensical, since there
is no member of ab_circle called "draw" --- ab_circle::draw
is just another way of referring to shape::draw.  Hence the
comment could have read
      // shape::draw() is a pure virtual
which was something we knew already.

This leaves us pondering about what it means for a class to "have" a
pure virtual function.  We must infer what we can from the example and
following implications that ab_circle is an abstract class whereas a
similar example which defines draw() is non-abstract, since there
doesn't look to be anything better we can go on.  Judging from these,
for a class C to "have" a pure virtual function means that there exists
some function f such that C::f() is pure virtual.  In the example given
by the original poster, the name dominance rule implies that B1::f() is
A1::f() not A::f(), and hence B1::f() is not pure virtual.  Thus B1
does not "have" any pure virtual functions, and so B1 is not abstract.
Q.E.D. ;-)

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <9333003.2685@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>evan@hplerk.hpl.hp.com (Evan Kirshenbaum) writes:
>
>>We have a situation in which we want to export an interface hierarchy
>>as a set of abstract classes, with multiple possible implementations
>>of each (a real one, a local proxy, a remote proxy, etc.).
>[...]
>>we get the following error:
>>
>>    declaration of object of abstract class struct B1 - pure virtual
>>    function(s) A::f() have not been defined
>>
>>According to the ARM (p 205-6), A1::f() dominates A::f() for B1, but
>>the compilers (cfront and HP C++) seem to think that it has to be
>>defined on *all* paths.
>>
>>So, are the compilers broken?
>
>Yes.  Complain to your vendors.

I don't suppose you would care to try to justify that answer, would you?

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

evan@hplerk.hpl.hp.com (Evan Kirshenbaum) writes:

>We have a situation in which we want to export an interface hierarchy
>as a set of abstract classes, with multiple possible implementations
>of each (a real one, a local proxy, a remote proxy, etc.).
[...]
>we get the following error:
>
>    declaration of object of abstract class struct B1 - pure virtual
>    function(s) A::f() have not been defined
>
>According to the ARM (p 205-6), A1::f() dominates A::f() for B1, but
>the compilers (cfront and HP C++) seem to think that it has to be
>defined on *all* paths.
>
>So, are the compilers broken?

Yes.  Complain to your vendors.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU