Topic: Feature request: immediate implementation of pure virtual functions


Author: pagey@drcsdca.com (Manish P. Pagey)
Date: Sun, 14 Jan 2001 12:04:09 CST
Raw View
>>>>> "mgradman" == mgradman  <mgradman@my-deja.com> writes:

    mgradman> Allowing an implementation for a pure virtual function
    mgradman> at all would contradict the true meaning of "pure
    mgradman> virtual".  Pure virtuals are only supposed to serve as
    mgradman> an abstract placeholder which must be implemented in
    mgradman> derived classes that will be instantiated.  One should
    mgradman> not be able to provide an implementation of a pure
    mgradman> virtual within the class it is defined.

This is all ok as long as you are not dealing with destructors. At
times when it is desirable to make the destructor a "pure virtual" one
still needs to provide an implementation.

--
Pagey

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: emarkp@CSUA.Berkeley.EDU (E. Mark Ping)
Date: Wed, 10 Jan 2001 19:49:44 GMT
Raw View
In article <3A49C426.C86617E@aixigo.de>,
Daniel Frey  <daniel.frey@aixigo.de> wrote:
>I'd like to write:
>
>class X
>{
>public:
>   virtual ~X() = 0 {}
>};

If I were to parse this, it'd look like you were trying to define a
funciton that is both pure virtual and inline.  It seems like this
would have to be an exception in the way that inline functions are
declared, doesn't it?

--
                              |  "If hard data were the filtering criterion
Mark Ping                     |   you could fit the entire contents of the
emarkp@soda.CSUA.Berkeley.EDU |   Internet on a floppy disk."
                              | - Cecil Adams, The Straight Dope Tells All

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: mgradman@my-deja.com
Date: Thu, 11 Jan 2001 19:21:37 GMT
Raw View
Allowing an implementation for a pure virtual function at all would
contradict the true meaning of "pure virtual".  Pure virtuals are only
supposed to serve as an abstract placeholder which must be implemented
in derived classes that will be instantiated.  One should not be able
to provide an implementation of a pure virtual within the class it is
defined.  Pure virtuals are abstract methods that serve as polymorphic
interfaces to the derived classes and nothing more.  And remember, the
class in which the pure virtual is defined may only be used
polymorphically (no objects of this *abstract* class may be
instantiated; they may only be referred to through pointers or
references).  If you really need to define an implementation for such
functions, they should not even be pure virtual ... just declare them
as "virtual" and then you may provide your implementation.  To emulate
the "abstractness" of the class, just declare a protected pure virtual
dummy function which your concrete subclasses implement with an empty
function body:

// can't be instantiated due to dummy() being pure virtual
class AbstractBase
{
public:
   virtual void PureVirtual() { // ... }

protected:
   virtual void dummy() = 0;  // preserves abstractness of AbstractBase
};

class ConcreteDerived : public AbstractBase
{
public:
    // override PureVirtual() here if desired

protected:
   virtual void dummy() { }  // "flags" this class as concrete
};

// remains abstract as dummy() not implemented
class AbstractDerived : public AbstractBase
{
public:
    // override PureVirtual() here if desired
};

class ConcreteMostDerived : public AbstractDerived
{
public:
    // override PureVirtual() here if desired

protected:
    virtual void dummy() { } // "flags" this class as concrete
};

The use of these classes is just as you would expect.

If your classes have true pure virtual functions besides the "pure
virtual" that you wish to actually implement in your class, then you
don't need to use the pure virtual dummy() function in them.


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Daniel Frey <daniel.frey@aixigo.de>
Date: Thu, 11 Jan 2001 14:54:31 CST
Raw View
"E. Mark Ping" wrote:
>
> In article <3A49C426.C86617E@aixigo.de>,
> Daniel Frey  <daniel.frey@aixigo.de> wrote:
> >I'd like to write:
> >
> >class X
> >{
> >public:
> >   virtual ~X() = 0 {}
> >};
>
> If I were to parse this, it'd look like you were trying to define a
> funciton that is both pure virtual and inline.  It seems like this
> would have to be an exception in the way that inline functions are
> declared, doesn't it?

'inline' is just a hint for the compiler and I think it is allowed to
have a virtual inline function, so why not have a pure virtual inline
function? This is nothing new for the compiler and it allows better
optimizations.

Regards, Daniel

--
Daniel Frey               wir machen anleger

aixigo AG - financial research and education
Schlo   -Rahe-Stra   e 15, 52072 Aachen, Germany
phone: +49 (0)241 93 67 37 - 42    fax: - 99
daniel.frey@aixigo.de   http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Francis Glassborow <francis.glassborow@ntlworld.com>
Date: Fri, 12 Jan 2001 04:54:19 GMT
Raw View
In article <93idaa$cro$1@agate.berkeley.edu>, E. Mark Ping
<emarkp@CSUA.Berkeley.EDU> writes
>In article <3A49C426.C86617E@aixigo.de>,
>Daniel Frey  <daniel.frey@aixigo.de> wrote:
>>I'd like to write:
>>
>>class X
>>{
>>public:
>>   virtual ~X() = 0 {}
>>};
>
>If I were to parse this, it'd look like you were trying to define a
>funciton that is both pure virtual and inline.  It seems like this
>would have to be an exception in the way that inline functions are
>declared, doesn't it?

Why? I am not supporting the proposal, just querying your implicit
statements about declaring inline functions.  AFAIK there is nothing
wrong with declaring an inline function as virtual (and compilers may
even use the 'inline' hint.)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Steve Clamage <stephen.clamage@sun.com>
Date: Wed, 3 Jan 2001 20:20:23 GMT
Raw View
Daniel Frey wrote:
>
>
> I'd like to write:
>
> class X
> {
> public:
>    virtual ~X() = 0 {}
> };
>
> As it is allowed to supply an implementation for a pure virtual
> function, I wonder if there is any reason why it is not allowed to mix
> the pure specifier with an implementation.

The syntax is confusing enough without allowing syntax such as the above.
The usual reasons for syntactical restrictions are to make the grammar
unambiguous, and to make it easier to report on common errros.

If instead of "=0" we had a keyword like "pure", it might have been
reasonable to allow the definition at the point of declaration.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Daniel Frey <daniel.frey@aixigo.de>
Date: Fri, 5 Jan 2001 01:00:38 GMT
Raw View
Steve Clamage wrote:
>=20
> Daniel Frey wrote:
> >
> > I'd like to write:
> >
> > class X
> > {
> > public:
> >    virtual ~X() =3D 0 {}
> > };
> >
> > As it is allowed to supply an implementation for a pure virtual
> > function, I wonder if there is any reason why it is not allowed to mi=
x
> > the pure specifier with an implementation.
>=20
> The syntax is confusing enough without allowing syntax such as the abov=
e.
> The usual reasons for syntactical restrictions are to make the grammar
> unambiguous, and to make it easier to report on common errros.

I think a lot of people may miss a later implementation, so you have to
work-around this by adding (and sometimes forgetting) comments. I'd like
to replace comments by a language-construct when it is possible and if
the =3D0 seems confusing, this is IMHO due to the fact that some people
associate "not implemented" instead of "this class can't be instantiated
directly and this function has to be implemented in any derived class
TOO". Even without a "=3D0" you can skip the implementation of any
function as long as it is never required (otherwise your linker (!) will
tell you). If the suggested syntax would appear in some sources, it may
even _help_ some people to understand the diffrence, but I don't believe
it would cause more confusion.

> If instead of "=3D0" we had a keyword like "pure", it might have been
> reasonable to allow the definition at the point of declaration.

I prefer not to add new keywords if they are not absolutely neccessary.
There is another reason comming to my mind for allowing the above
syntax: It helps when using templates, right? But I'm not sure about
this yet.. gotta think about it a bit longer..

Regards, Daniel

--
Daniel Frey               wir machen anleger

aixigo AG - financial research and education
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
phone: +49 (0)241 93 67 37 - 42    fax: - 99
daniel.frey@aixigo.de   http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Anthony Williams <anthony_w@my-deja.com>
Date: Fri, 5 Jan 2001 00:59:58 GMT
Raw View
In article <3A5240BA.24B67BB5@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> Daniel Frey wrote:
> >
> >
> > I'd like to write:
> >
> > class X
> > {
> > public:
> >    virtual ~X() = 0 {}
> > };
> >
> > As it is allowed to supply an implementation for a pure virtual
> > function, I wonder if there is any reason why it is not allowed to
mix
> > the pure specifier with an implementation.
>
> The syntax is confusing enough without allowing syntax such as the
above.
> The usual reasons for syntactical restrictions are to make the grammar
> unambiguous, and to make it easier to report on common errros.
>
> If instead of "=0" we had a keyword like "pure", it might have been
> reasonable to allow the definition at the point of declaration.
>

I like this suggestion. Keep "=0" permitted, for legacy code, and add a
new keyword "pure":

class SomeClass
{
  virtual void func1()=0; // OK, as now
  virtual void func2()=0 {} // not permitted, as now
  pure virtual void func3(); // OK
  pure virtual void func4() {} // OK, pure virtual with implementation
};

Anthony

--
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net  -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]





Author: Daniel Frey <daniel.frey@aixigo.de>
Date: Fri, 29 Dec 2000 21:28:42 GMT
Raw View
Hi,

this is not a big deal but I think it makes the source more obvious:

Instead of

class X
{
public:
   virtual ~X() =3D 0;
};

X::~X() {}

I'd like to write:

class X
{
public:
   virtual ~X() =3D 0 {}
};

As it is allowed to supply an implementation for a pure virtual
function, I wonder if there is any reason why it is not allowed to mix
the pure specifier with an implementation. IMHO it would make it easier
to see that a function (especially a destructor) *has* an implementation
(and usually this means that it will be called) because it's easy to
overlook that if the implementation is at a different location. Any
objections?

Regards, Daniel

--
Daniel Frey               wir machen anleger

aixigo AG - financial research and education
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
phone: +49 (0)241 93 67 37 - 42    fax: - 99
daniel.frey@aixigo.de   http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]