In article <jc.795885674@atcmpg>,
Jan Christiaan van Winkel <jc@atcmp.nl> wrote:
>In the ARM, par 10.3 Abstract Base classes, it says that
>it is allowed to give a pure virtual function a body, such as:
>
> class A {
>  virtual void f() =0;
>  A() {
>   A::f();    // ok
>  }
> };
>
>XX void A::f() { // defined somewhere
>  // ...
> }
>
>A::f() is then callable only statically using the scope operator, thus
>explicitly referring to A's f() (in marked with line XX).

There is one exception: a pure virtual destructor. It is called only
implicitly when an object is destructed. This immediately gives a
possible reason why this  is allowed in C++.

>I would be inclined to say that A::f() and the pure virtual A::f() are two
>distinct functions (eventhough they have the same name and argumentlist).

Your assumption is wrong, just as with return types the compiler is
not able to differentiate between a method that is pure virtual and
one that is not.

--
Name: Arnoud Martens, Utrecht, the Netherlands,  tel: +31-30-732679
E-mail: arnoudm@ijssel.xs4all.nl WWW: http://www.xs4all.nl/~arnoudm

In article <jc.795885674@atcmpg>, jc@atcmp.nl (Jan Christiaan van Winkel) writes:
|>
|> Hello netters,
|>
|> I have the following question about pure virtual functions:
|>
|> In the ARM, par 10.3 Abstract Base classes, it says that
|> it is allowed to give a pure virtual function a body, ...
|> ...
|>
|> Why is this feature available?  Isn't it so that A::f() (in XX) can only
|> be called explicitly using the scope operator, hence that the virtual f()
|> functions in the A hierarchy have *nothing* to do with A::f() (in XX), and
|> thus that the name of A::f() could just as well have been say A::oreo()?

Scott Meyers discusses a possible use of this feature in Effective C++, p 128,
as a way to provide both an interface and a `safe' default implementation,
where `safe' means that you have to invoke it explicitly rather than risking
obtaining it accidentally through careless derivation. Granted, the default
implementation could have been called with a different name but this helps
limiting name clutter.

The real rationale is probably related with those methods which cannot
be assigned an alternate name and default/not-readily-accessible
implementation, such as pure virtual destructors.

|> I would be inclined to say that A::f() and the pure virtual A::f() are two
|> distinct functions (eventhough they have the same name and argumentlist).

Not quite, athough this could probably be endlessly debatable... IMHO, it
separates two concerns: the existence of scoped implementations and their
default (planned) accessibility to average clients of the class. The ability
to keep the same name for `hidden' implementations may provide a significant
simplification for automatically-generated code, in situations where you have
uncommon needs and more control/knowledge than average clients.

As an aside, I'd be curious to know what kind of use one could make of a
pure virtual assignment operator. Any idea ?

--chris@etca.fr
Le monde entier est un cactus, il est impossible de s'asseoir (J. Dutronc)

Hello netters,

I have the following question about pure virtual functions:

In the ARM, par 10.3 Abstract Base classes, it says that
it is allowed to give a pure virtual function a body, such as:

 class A {
  virtual void f() =0;
  A() {
   A::f();    // ok
  }
 };

XX void A::f() { // defined somewhere
  // ...
 }

A::f() is then callable only statically using the scope operator, thus
explicitly referring to A's f() (in marked with line XX).

Why is this feature available?  Isn't it so that A::f() (in XX) can only
be called explicitly using the scope operator, hence that the virtual f()
functions in the A hierarchy have *nothing* to do with A::f() (in XX), and
thus that the name of A::f() could just as well have been say A::oreo()?

I would be inclined to say that A::f() and the pure virtual A::f() are two
distinct functions (eventhough they have the same name and argumentlist).

Then why does the ARM say that ``Note that pure virtual functions can
be defined''.  No it's not!  It's just a totally different function with
coincidentally the same name and signature.

Thanks for helping me with this ``problem''

JC
--
___  __  ____________________________________________________________________
   |/  \   Jan Christiaan van Winkel      Tel: +31 80 527252  jc@atcmp.nl
   |       AT Computing   P.O. Box 1428   6501 BK Nijmegen    The Netherlands
__/ \__/ __________ http://www.nl.net/~atcmp/staf/jc.gif ____________________

In article <jc.795885674@atcmpg> jc@atcmp.nl (Jan Christiaan van Winkel) writes:
>Why is this feature available?  Isn't it so that A::f() (in XX) can only
>be called explicitly using the scope operator, hence that the virtual f()
>functions in the A hierarchy have *nothing* to do with A::f() (in XX), and
>thus that the name of A::f() could just as well have been say A::oreo()?

I think it exists for the benefit of the common OO programming style where
Derived::f() (which can be called virtually) calls Base::f().  While the
function in the base class doesn't have to have the same name, doing so
makes this relationship more obvious.  It's pretty clear what's going on
when Derived::f() calls Base::f(), but less so when Derived::f() call
Base::oreo().  Of course, judicious choice of names could make the latter
more clear; e.g. Derived::f() could call Base::default_f().  Another
feature of defining the pure virtual function is that you don't need a
second function name (default_f) cluttering up your namespace.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@bbnplanet.com

In article 795885674@atcmpg, jc@atcmp.nl (Jan Christiaan van Winkel) writes:
>
>
>In the ARM, par 10.3 Abstract Base classes, it says that
>it is allowed to give a pure virtual function a body...
>
>Why is this feature available?

It is required for pure virtual destructors, which is probably the main
reason, since the destructor will be called when the object is destroyed.
The choices would seem to be
1. disallow pure virtual destructors.
2. special rule: a pure virtual destructor is not called.
3. allow a pure virtual dtor to be instantiated, but not other pure virtuals.
4. allow any pure virtual function to be instantiated.

#1 prevents declaring an abstract class unless you can identify some
virtual functions. An abstract class will have a virtual dtor anyway,
but this rule would require at least one more virtual function.

#2 doesn't work. Suppose the class has member data which need destruction.

#3 Why is it better to forbid instantiation of a general pure virtual function?

#4 is the language rule.


>I would be inclined to say that A::f() and the pure virtual A::f() are two
>distinct functions (eventhough they have the same name and argumentlist).
>
>Then why does the ARM say that ``Note that pure virtual functions can
>be defined''.  No it's not!  It's just a totally different function with
>coincidentally the same name and signature.

Depends on how you want to quibble. A C++ rule is that there cannot be
two functions in the same scope with the same name and signature. If
the instantiated pure virtual function is really a "different" function,
that would require a special case for this rule.

Instead, we have a special case that a pure virtual function is never
called via the virtual function mechanism. The assumption is that a pure
virtual function does not exist, so this special-case rule makes sense
IMHO. If you happen to know that a pure virtual function does exist,
there is a syntax to call it.
---
Steve Clamage, stephen.clamage@eng.sun.com