std destructors

[jquesnelle]

why don't the std classes have virtual destructors?

doesn't it make sense to want to inherit from these classes and
add/change functionality?

[Belebele]

jq********@gmail.com wrote:

why don't the std classes have virtual destructors?

doesn't it make sense to want to inherit from these classes and
add/change functionality?

It is usually not a good idea to derive from concrete classes because
of the partial assignment problem and mixed-type assignment problem. It
also shows the need for new potential abstractions in your design.

Check out item 33 on Scott Meyers' More Effective C++. He explains it
all clearly. (That's a book that we should all keep handy).

"Object Oriented Design Heuristics" also mentions the problem and its
implications.

Belebele

[jquesnelle]

I guess my question is... why are the std classes concrete classes?
Belebele wrote:

jq********@gmail.com wrote:

why don't the std classes have virtual destructors?

doesn't it make sense to want to inherit from these classes and
add/change functionality?

It is usually not a good idea to derive from concrete classes because
of the partial assignment problem and mixed-type assignment problem. It
also shows the need for new potential abstractions in your design.

Check out item 33 on Scott Meyers' More Effective C++. He explains it
all clearly. (That's a book that we should all keep handy).

"Object Oriented Design Heuristics" also mentions the problem and its
implications.

Belebele

[Pete Becker]

jq********@gmail.com wrote:

why don't the std classes have virtual destructors?

doesn't it make sense to want to inherit from these classes and
add/change functionality?

std::exception has a virtual destructor, to name just one of many. If
your concern is the coding style guideline that base classes should have
virtual destructors, that guideline is simplistic. A virtual destructor
is needed only if the design of the class calls for deleting objects of
derived types through pointers to the base type. For beginners that may
be too complicated, hence the broader guideline.

--

Pete Becker
Roundhouse Consulting, Ltd.

[jquesnelle]

Thanks. This resolves an argument with a co-worker (he was under the
false impression that the derived class' constructor wouldn't be called
even if the pointer using to delete it was of the derived class).
Pete Becker wrote:

jq********@gmail.com wrote:

why don't the std classes have virtual destructors?

doesn't it make sense to want to inherit from these classes and
add/change functionality?

std::exception has a virtual destructor, to name just one of many. If
your concern is the coding style guideline that base classes should have
virtual destructors, that guideline is simplistic. A virtual destructor
is needed only if the design of the class calls for deleting objects of
derived types through pointers to the base type. For beginners that may
be too complicated, hence the broader guideline.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Belebele]

Pete Becker wrote:

A virtual destructor
is needed only if the design of the class calls for deleting objects of
derived types through pointers to the base type.

That is always the case when the derivation is public. Public
inheritance is an idiom that states that the derived class object can
be used as a base class object at all times (Liskov Substitution
Principle).

The implementor of the derived class cannot prevent clients from
keeping references to objects of the publicly derived class through
pointers of the base class (and deleting them anytime). It is then a
good practice to make the base class destructor virtual to make it
harder to use that base class incorrectly.

Private and protected inheritance is another matter, as the
substitution principle does not apply.

[Victor Bazarov]

Belebele wrote:

Pete Becker wrote:

A virtual destructor
is needed only if the design of the class calls for deleting objects
of derived types through pointers to the base type.
That is always the case when the derivation is public.

Never say "always".
Public
inheritance is an idiom that states that the derived class object can
be used as a base class object at all times (Liskov Substitution
Principle).

The implementor of the derived class cannot prevent clients from
keeping references to objects of the publicly derived class through
pointers of the base class (and deleting them anytime). It is then a
good practice to make the base class destructor virtual to make it
harder to use that base class incorrectly.

Private and protected inheritance is another matter, as the
substitution principle does not apply.

You're making too many assumptions. Protected inheritance could also
mean substitution, only the region is limited to the members of the
class itself or the derived class[es].

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Pete Becker]

Belebele wrote:

Pete Becker wrote:

A virtual destructor
is needed only if the design of the class calls for deleting objects of
derived types through pointers to the base type.

That is always the case when the derivation is public.

No, it's only the case when your design calls for deleting derived
objects through pointers to the base.
Public
inheritance is an idiom that states that the derived class object can
be used as a base class object at all times (Liskov Substitution
Principle).
It doesn't follow that you need to delete derived objects through
pointers to the base. Further, that's not the only use for public
inheritance.

The implementor of the derived class cannot prevent clients from
keeping references to objects of the publicly derived class through
pointers of the base class (and deleting them anytime). It is then a
good practice to make the base class destructor virtual to make it
harder to use that base class incorrectly.

If the design of the base class doesn't call for deleting derived
objects through pointers to the base, then making the destructor virtual
doesn't make it harder to use the class incorrectly. It just removes one
of the symptoms.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Belebele]

Victor Bazarov wrote:

Belebele wrote:

That is always the case when the derivation is public.
Never say "always".

That's true. You can frequently find bizarre uses of the public
inheritance idiom. When those pop up in my head, I try hard to sit back
and wait for them to go away, with mixed results.
You're making too many assumptions. Protected inheritance could also
mean substitution, only the region is limited to the members of the
class itself or the derived class[es].

I would classify such uses as bizarre, if anything, due to my lack of
understanding.

[Default User]

jq********@gmail.com wrote:

Thanks. This resolves an argument with a co-worker (he was under the
false impression that the derived class' constructor wouldn't be
called even if the pointer using to delete it was of the derived
class).

Please don't top-post. See item 4 of the FAQ entry below:

<http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.4>

Brian

[Roland Pibinger]

On 21 Jun 2006 16:37:25 -0700, jq********@gmail.com wrote:

Belebele wrote:

jq********@gmail.com wrote:

> why don't the std classes have virtual destructors?
> doesn't it make sense to want to inherit from these classes and
> add/change functionality?

It is usually not a good idea to derive from concrete classes because
of the partial assignment problem and mixed-type assignment problem. It
also shows the need for new potential abstractions in your design.

Check out item 33 on Scott Meyers' More Effective C++. He explains it
all clearly. (That's a book that we should all keep handy).

"Object Oriented Design Heuristics" also mentions the problem and its
implications.

I guess my question is... why are the std classes concrete classes?

Some are. The C++ Standard library consists of 3 larger libraries
which have been introduced successively in the last 20 or so years.
Each of those libraries follows a different 'paradigm':
1. The C-Standard part is a procedural library
2. iostreams are designed according to the OO paradigm
3. the standardized subset of STL obeys to the generic and
value-semantics (which are not the same) dogma.

What confuses most beginners and many experts is the mix of C++ styles
that is presented in books, articles and newsgroups without any
further discussion of the underlying 'paradigms'.
Of course, there could be Java-like containers in C++ (they would
certainly be prefered to STL containers by many real-world
programmers). Also, the procedural stdio is more usable for many cases
than the OO experiment called iostreams. Alas, fundamental design
questions simply are not conducted in C++. Hence the permanent
confusion.

Best wishes,
Roland Pibinger

[Jerry Coffin]

In article <44*************@news.utanet.at>, rpbg123
@yahoo.com says...

[ ... ]

Of course, there could be Java-like containers in C++ (they would
certainly be prefered to STL containers by many real-world
programmers).
Spoken like somebody who either doesn't know or has long
forgotten most of the early history of C++. C++ had
containers a lot like those in Java _long_ before Java
did. If you look, you can probably still find a copy of
Keith Gorlen's ancient NIH class library, for one obvious
example.

Based on my experience and your usage, when you say
"real-world", what you really mean is "ignorant and
misguided."
Also, the procedural stdio is more usable for many cases
than the OO experiment called iostreams.
Each has strengths and weaknesses, that's true. That's
probably at least part of why the C++ standard retains
the stdio library as part of the C++ standard library.
Every library starts as an experiment, and (given time)
progresses to production use. Clearly iostreams have been
put to production use for a long time, so your
description of them as an experiment is clearly no longer
accurate.

If you don't like them, so be it. That doesn't wind the
clock back 20 years...
Alas, fundamental design
questions simply are not conducted in C++. Hence the permanent
confusion.

You seem to be the one suffering from confusion.

--
Later,
Jerry.

The universe is a figment of its own imagination.