Deriving a regular class from a template?

[Julie]

There's nothing advanced about the technique. It's simply error-prone, and so
should be avoided by anyone who doesn't understand the pitfalls and
limitations.


It is a bad practice. The mitigating factor is that an expert will be able to
make bad practices work and will know how to limit the scope. Obviously, anyone
who has worked with a tool for a substantial amount of time will know how to
use otherwise inappropriate shortcuts to good effect, but that's an attribute
of the practitioner, not of the technique. I would certainly be more confident
of something unorthodox from Victor than I would from a completely orthodox
implementation from newbie-come-lately. That doesn't change that the practice
is frowned upon in a larger context. It's not because Evel Knievel can
successfully and reproducibly jump a motorcycle over a row of buses that
suddenly it becomes an acceptable practice for all bikers. It's an acceptable
practice for Evel Knievel.

I really don't get your point. At first, you say that it isn't an advanced
technique, then you go off to essentially say that it is acceptable for
experienced/expert users to use it???

Maybe you misinterpreted my intended meaning of advanced: intended to be used
by experienced programmers that recognize and understand the pitfalls and
limitations.

 

[Julie]

The "pitfalls" are:

1. the behavior is undefined if you delete an object of a derived type
through a pointer to the base type.

The "limitations" are:

1. don't do that.

Of course, if you don't read documentation or don't design your code
before you write it you may well run afoul of these "pitfalls and
limitations". Too bad. Programming is a profession. If you can't pay
enough attention to do it right, don't do it at all.

Pete, no one is advocating not reading the documentation or not designing
code. However, I'd like to know where in the documentation (i.e. standard) it
says that standard containers should not be derived from.

Second: if the answer is an unconditional "don't do that", then why is it
possible? What is the cost of making the containers 'sealed' (so that they
_can't_ be derived from)? If the cost is low or nonexistent, why didn't the
committee make that the case?

 

[Julie]

Pete Becker wrote:
[snip]

Of course, if you don't read documentation or don't design your code
before you write it you may well run afoul of these "pitfalls and
limitations". Too bad. Programming is a profession. If you can't pay
enough attention to do it right, don't do it at all.

I hope that you aren't *serious* about this statement... If you are, then I
really hope that you and the rest of the committee are making concerted efforts
to make sure that everything is completely and thoroughly documented so that
there is no misinterpretation in the usage of *ANY* language construct or
library element.

If you can't pay
enough attention to do it right, don't do it at all.

Pretty harsh words. Shall I go dig up all the corrections, retractions, etc.
from your column?

 

[Pete Becker]

Pete, no one is advocating not reading the documentation or not designing
code. However, I'd like to know where in the documentation (i.e. standard) it
says that standard containers should not be derived from.

It doesn't. This discussion was about the derived types, not the base
types. As I said, because the standard containers don't have virtual
destructors, if you delete a derived object through a pointer to the
base, the behavior of the code is undefined.

Second: if the answer is an unconditional "don't do that", then why is it
possible?

As with most undefined behavior, the reason is that it's too expensive
to check.

What is the cost of making the containers 'sealed' (so that they
_can't_ be derived from)? If the cost is low or nonexistent, why didn't the
committee make that the case?

There's little, if any, benefit from doing that, and there are
reasonable uses for it. What dangers do you see in deriving from
standard containers that would justify such a restriction?

 

[Pete Becker]

Pete Becker wrote:
[snip]

Of course, if you don't read documentation or don't design your code
before you write it you may well run afoul of these "pitfalls and
limitations". Too bad. Programming is a profession. If you can't pay
enough attention to do it right, don't do it at all.

I hope that you aren't *serious* about this statement... If you are, then I
really hope that you and the rest of the committee are making concerted efforts
to make sure that everything is completely and thoroughly documented so that
there is no misinterpretation in the usage of *ANY* language construct or
library element.

That is, indeed, a large part of what writing a standard is about.

With regard to the point under discussion, the standard (5.3.5/3) is
quite clear: "In the first alternative (delete object), if the static
type of the operand is different from its dynamic type, the static type
shall be a base class of the operand’s dynamic type and the static type
shall have a virtual destructor or the behavior is undefined."

 

[Julie]

There's little, if any, benefit from doing that, and there are
reasonable uses for it. What dangers do you see in deriving from
standard containers that would justify such a restriction?

I'm lost.

I thought that we were talking about deriving from std containers, your answer
was "don't do that", now it looks like you are saying "there are reasonable
uses for it".

Please clarify.

 

[Pete Becker]

I'm lost.

I thought that we were talking about deriving from std containers, your answer
was "don't do that", now it looks like you are saying "there are reasonable
uses for it".

Please clarify.

I was talking about deleting derived objects through pointers to bases
without virtual destructors.

 

[Julie]

I was talking about deleting derived objects through pointers to bases
without virtual destructors.

Ok, that is understood.

Now, what are your feelings about deriving from std containers? A 'bad thing'
or 'advanced* technique'?

(*Advanced meaning for programmers that fully understand the ramifications of
such)

 

[Richard Herring]

There's little, if any, benefit from doing that, and there are
reasonable uses for it. What dangers do you see in deriving from
standard containers that would justify such a restriction?

I'm lost.

I thought that we were talking about deriving from std containers, your answer
was "don't do that", now it looks like you are saying "there are reasonable
uses for it".

Please clarify.[/QUOTE]

FWIW I got the impression that PB's use of "don't do that" was not a
recommendation for how to code, but the "limitation" that should
therefore appear in the documentation - i.e. not "don't derive from
std:: containers" but "don't delete the result through base pointers".
The "pitfall" -- sliced deletion -- is countered by the "limitation" --
documentation forbids such deletion.

But maybe I'm more confused than the rest of you ;-(