Deriving a regular class from a template?

[Steven T. Hatton]

This may be another question having an obvious answer, but I'm not seeing
it. I'm trying to create a class that derives from
std::valarray<s td::string>. I don't need a template, and I haven't come
across any examples of a construct like what I show below. Perhapes it's
simply a bad idea. If there is something fundamentally wrong with this
approach please let me know.

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

This is the point where it fails:

g++ -o stringer main.o -L/usr/lib/ -L/usr/lib/qt3/lib/ -L/usr/X11R6/lib/
-lqt -lXext -lX11 -lm
main.o(.text+0x d7): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 155): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 196): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `__gnu_cxx::__e xchange_and_add (int volatile*, int)'

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Julie]

Claudio Puviani wrote:

"Julie" <ju***@nospam.c om> wrote

Victor Bazarov wrote:

A note: I often find it helpful to derive privately. Then I can
control what functionality is exposed and I definitely prevent such
blunders as accidental polymorphic deletion.

Victor

So, if that is the case, then deriving from std containers should *NOT* be
labeled as a bad practice (bad design, etc.), but rather as an 'advanced
construct or idiom'.

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.

I'm sure that _misnaming_ something 'bad practice/design' causes a lot more
problems that it is intended to solve.

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]

Pete Becker wrote:

Claudio Puviani wrote:

"Julie" <ju***@nospam.c om> wrote

Victor Bazarov wrote:
> A note: I often find it helpful to derive privately. Then I can
> control what functionality is exposed and I definitely prevent such
> blunders as accidental polymorphic deletion.
>
> Victor

So, if that is the case, then deriving from std containers should *NOT* be
labeled as a bad practice (bad design, etc.), but rather as an 'advanced
construct or idiom'.

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.

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 "limitation s" 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 misinterpretati on 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]

Julie wrote:

Pete Becker wrote:

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.

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
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Julie wrote:

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 misinterpretati on 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."

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Julie]

Pete Becker wrote:

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?

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]

Julie wrote:

Pete Becker wrote:

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?

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Julie]

Pete Becker wrote:

Julie wrote:

Pete Becker wrote:

> 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?

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.

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]

In message <40************ **@nospam.com>, Julie <ju***@nospam.c om>
writes

Pete Becker wrote:

> 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?

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.

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 ;-(

--
Richard Herring