By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,820 Members | 1,187 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,820 IT Pros & Developers. It's quick & easy.

NonCopyable

P: n/a
Having come across a few NonCopyable classes, I just wondered why they don't
have virtual destructors. Doesn't this limit there usefulness? In fact,
there seem a whole bunch of generic classes in Boost, for instance, that
don't have virtual destructors but that do expose public constructors.
Aren't these a recipe for disaster?

Boost has an 'abstract' class that simply defines a virtual destructor; is
the idea that the programmer tags this on the end of the inheritence list if
they want to be able to 'delete' through a base class pointer?
Jul 22 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Tim Clacy wrote:
Having come across a few NonCopyable classes, I just wondered why they don't
have virtual destructors. Doesn't this limit there usefulness? In fact,
there seem a whole bunch of generic classes in Boost, for instance, that
don't have virtual destructors but that do expose public constructors.
Aren't these a recipe for disaster?
No, why? There's only a problem if someone tries to delete a derived
class through a pointer to a base without a virtual destructor. This
isn't always likely to happen, and the absence of a virtual destructor
pretty much says "don't do that."
Boost has an 'abstract' class that simply defines a virtual destructor; is
the idea that the programmer tags this on the end of the inheritence list if
they want to be able to 'delete' through a base class pointer?


No idea, but I like your interpretation. :)
Jul 22 '05 #2

P: n/a
On Tue, 18 May 2004 18:53:32 +0200, "Tim Clacy"
<no*******@nospamphaseone.nospamdk> wrote:
Having come across a few NonCopyable classes, I just wondered why they don't
have virtual destructors. Doesn't this limit there usefulness? In fact,
there seem a whole bunch of generic classes in Boost, for instance, that
don't have virtual destructors but that do expose public constructors.
Aren't these a recipe for disaster?
Generally you inherit privately from NonCopyable classes (like
boost::noncopyable), so there is no likelihood of problems. There is
also no reason to ever have a noncopyable*. How were you envisioning
this disaster occurring? Adding a virtual destructor to
boost::noncopyable would be a terrible thing to do - lots of classes
which don't have virtual functions use noncopyable, and these would
suddenly all gain an unnecessary vtable (and associated RTTI, etc.).

Also, could you give another example of these generic classes that
might have a problem? I suspect that you're seeing danger where there
is none, or only some through serious misuse (such as subclassing a
class that shouldn't be subclassed).
Boost has an 'abstract' class that simply defines a virtual destructor; is
the idea that the programmer tags this on the end of the inheritence list if
they want to be able to 'delete' through a base class pointer?


Where is this class? I found a class deep in some test header that was
called "abstract", but no others, and no end user ones.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #3

P: n/a
Jeff Schwab wrote:
Tim Clacy wrote:
Having come across a few NonCopyable classes, I just wondered why
they don't have virtual destructors. Doesn't this limit there
usefulness? In fact, there seem a whole bunch of generic classes in
Boost, for instance, that don't have virtual destructors but that do
expose public constructors. Aren't these a recipe for disaster?
No, why? There's only a problem if someone tries to delete a derived
class through a pointer to a base without a virtual destructor. This
isn't always likely to happen, and the absence of a virtual destructor
pretty much says "don't do that."


Jeff,

I admire you're faith in programmers but, to me, "This isn't always likely
to happen" means it definately will happen and when it does happen you have,
at best, a memory leak :-)
Boost has an 'abstract' class that simply defines a virtual
destructor; is the idea that the programmer tags this on the end of
the inheritence list if they want to be able to 'delete' through a
base class pointer?


No idea, but I like your interpretation. :)

Jul 22 '05 #4

P: n/a
tom_usenet wrote:
On Tue, 18 May 2004 18:53:32 +0200, "Tim Clacy"
<no*******@nospamphaseone.nospamdk> wrote:
Having come across a few NonCopyable classes, I just wondered why
they don't have virtual destructors. Doesn't this limit there
usefulness? In fact, there seem a whole bunch of generic classes in
Boost, for instance, that don't have virtual destructors but that do
expose public constructors. Aren't these a recipe for disaster?
Generally you inherit privately from NonCopyable classes (like
boost::noncopyable), so there is no likelihood of problems. There is
also no reason to ever have a noncopyable*. How were you envisioning
this disaster occurring? Adding a virtual destructor to
boost::noncopyable would be a terrible thing to do - lots of classes
which don't have virtual functions use noncopyable, and these would
suddenly all gain an unnecessary vtable (and associated RTTI, etc.).


Fair enough. "Just out of curiousity", said the cat, what would you do if
you wanted to define a class that should be non-copyable but which could be
inherited from?
Also, could you give another example of these generic classes that
might have a problem? I suspect that you're seeing danger where there
is none, or only some through serious misuse (such as subclassing a
class that shouldn't be subclassed).
Boost has an 'abstract' class that simply defines a virtual
destructor; is the idea that the programmer tags this on the end of
the inheritence list if they want to be able to 'delete' through a
base class pointer?


Where is this class? I found a class deep in some test header that was
called "abstract", but no others, and no end user ones.

Tom


You're absolutely right; it's in data.hpp, which is underneath the
meta-programming root

class abstract { virtual ~abstract() = 0; };
Jul 22 '05 #5

P: n/a
"Tim Clacy" <no*******@nospamphaseone.nospamdk> wrote:
Having come across a few NonCopyable classes, I just wondered why they don't have virtual destructors. Doesn't this limit there usefulness? In fact,
there seem a whole bunch of generic classes in Boost, for instance, that
don't have virtual destructors but that do expose public constructors.
Aren't these a recipe for disaster?
Not if you *privately* derive from the base class, which should be
the case when deriving from NonCopyable.

Empty base classes are used at times, maybe especially in designs
involving templates, to import a set of declarations in a subclass.
This could be dangerous if public inheritance is used and the
subclass can be instantiated. In practice, however, I do not think
this is a common problem.

Boost has an 'abstract' class that simply defines a virtual destructor; is
the idea that the programmer tags this on the end of the inheritence list
if they want to be able to 'delete' through a base class pointer?


A class that declares a pure virtual destructor does not force
its subclasses to be abstract, so such a class would appear to
be redundant as a tag for abstract classes. Furthermore, a memory
overhead of 1 pointer per instance of the derived class may be incurred.

I would rather derive the top-most base class from 'abstract'.
This could be useful in OO designs to allow classes to share a
common disposal mechanism.

Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
Jul 22 '05 #6

P: n/a
Tim Clacy wrote:
tom_usenet wrote:
On Tue, 18 May 2004 18:53:32 +0200, "Tim Clacy"
<no*******@nospamphaseone.nospamdk> wrote:
Having come across a few NonCopyable classes, I just wondered why
they don't have virtual destructors. Doesn't this limit there
usefulness? In fact, there seem a whole bunch of generic classes in
Boost, for instance, that don't have virtual destructors but that do
expose public constructors. Aren't these a recipe for disaster?


Generally you inherit privately from NonCopyable classes (like
boost::noncopyable), so there is no likelihood of problems. There is
also no reason to ever have a noncopyable*. How were you envisioning
this disaster occurring? Adding a virtual destructor to
boost::noncopyable would be a terrible thing to do - lots of classes
which don't have virtual functions use noncopyable, and these would
suddenly all gain an unnecessary vtable (and associated RTTI, etc.).


Fair enough. "Just out of curiousity", said the cat, what would you
do if you wanted to define a class that should be non-copyable but
which could be inherited from?


Hmm, before someone else points out what an absurd question this is, I would
like to do so.
Jul 22 '05 #7

P: n/a
Tim Clacy wrote:
Jeff Schwab wrote:
Tim Clacy wrote:
Having come across a few NonCopyable classes, I just wondered why
they don't have virtual destructors. Doesn't this limit there
usefulness? In fact, there seem a whole bunch of generic classes in
Boost, for instance, that don't have virtual destructors but that do
expose public constructors. Aren't these a recipe for disaster?


No, why? There's only a problem if someone tries to delete a derived
class through a pointer to a base without a virtual destructor. This
isn't always likely to happen, and the absence of a virtual destructor
pretty much says "don't do that."

Jeff,

I admire you're faith in programmers but, to me, "This isn't always likely
to happen" means it definately will happen and when it does happen you have,
at best, a memory leak :-)


It's not faith, it's respect. If you think you can make your libraries
abuse-proof, then /I/ admire /your/ faith.
Jul 22 '05 #8

P: n/a
"Jeff Schwab" <je******@comcast.net> wrote in message
news:mY********************@comcast.com...
Tim Clacy wrote:
Jeff Schwab wrote:
Tim Clacy wrote:
Having come across a few NonCopyable classes, I just wondered why
they don't have virtual destructors. Doesn't this limit there
usefulness? In fact, there seem a whole bunch of generic classes in
Boost, for instance, that don't have virtual destructors but that do
expose public constructors. Aren't these a recipe for disaster?

No, why? There's only a problem if someone tries to delete a derived
class through a pointer to a base without a virtual destructor. This
isn't always likely to happen, and the absence of a virtual destructor
pretty much says "don't do that."

I happen to see legitimate code that new-s and delete-s instances of
classes that do not have a virtual destructor.
So the absence of a virtual destructor doesn't exclude calling delete.

This is not a theoretical issue, but a real opportunity
for undefined behavior.
( though I agree that this is not a real issue for
'stub' classes such as NonCopyable ).
Jeff,

I admire you're faith in programmers but, to me, "This isn't always likely to happen" means it definately will happen and when it does happen you have, at best, a memory leak :-)


It's not faith, it's respect. If you think you can make your libraries
abuse-proof, then /I/ admire /your/ faith.


Inapropriate deletion through a base class pointer is a good example
of accidental misuse, which IMHO every decent C++ programmer should
seek to prevent.
Cheers,
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
Jul 22 '05 #9

P: n/a
On Tue, 18 May 2004 19:20:05 +0200, "Tim Clacy"
<no*******@nospamphaseone.nospamdk> wrote:
You're absolutely right; it's in data.hpp, which is underneath the
meta-programming root

class abstract { virtual ~abstract() = 0; };
Yup, that's the one I saw.
Boost has an 'abstract' class that simply defines a virtual destructor; is
the idea that the programmer tags this on the end of the inheritence list if
they want to be able to 'delete' through a base class pointer?


I don't think it's really useful for anything much, to be honest.
Boost seems to be using it as a metaprogramming tag to represent the
set of abstract classes.

Adding a tag class to use as a base class for inheritable classes
introduces unnecessary overhead.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.