Re: Inherite form stl container classes
James Kanze wrote:
On Jun 3, 12:57 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
[...]
b) As for public inheritance from STL container, there are
two commonly mentioned problems:
b1) STL containers do not have virtual destructors.
This is not really a problem. Just don't delete pointers to
the derived classes through pointers of the base class (and
why would you have any use for such polymorphic container
pointers in the first place). It's about as problematic in
practice as inheriting from std::iterator.
I disagree. There is nothing you could conceivably do with
an std::iterator itself. You'd never have a reference to
std::iterator as a parameter to a function, for example; in
fact, you'd never have a reference or a pointer to an
std::iterator anywhere in any reasonable code. The same
thing cannot be said of std::vector. And while I can't
think of any case where you'd ever dynamically allocate an
std::vector (and thus, invoke delete on a pointer to
std::vector), it's still a risk I'd prefer avoiding.
First, we seem to agree that dynamically allocated vectors are
weird (and would go as far as saying its a smell). That is
_why_ I don't think the absence of a virtual destructor is a
good argument agains public derivation from std::vector.
However, I do see that this very much depends on coding
guidelines and local culture.
Yes. After reading your posting, and thinking it over, I more
or less came to the conclusion that the rule in the guidelines
should be "never allocate a standard container dynamically",
rather than "never derive publicly from a standard container".
This isn't the "generally accepted" rule, however, so it may not
be trivial to get it accepted locally.
That, I think, is just part of a bigger problem: pointer handling. I have
tried various things to make that easier and safer. E.g., at one point I
devised a pointer_to<> template that would trigger compile time failures in
an assignment
pointer_to< Base> <-- pointer_to< Derived >
if Base did not have a virtual destructor. However, none of those tricks
works without discipline and code review. In the end, you need local coding
guidelines; and as long as they are reasonable, many things will work.
Now, I do think that banning dynamic allocation for container is better than
banning derivation from containers; but that might be because I have
encountered the need for the latter and never felt a need for the former.
Someone with a different code base might justifiably come to a different
conclusion.
And if you allow dynamic allocation of a standard container, then you
don't want to derive from it.
Right. Whatever your coding guidelines are, they are meant to keep you from
harm.
[...]
Well, the more general pattern is this: I like the type system
to distinguish types that have different meaning. Now, a
std::vector<double> can _mean_ many things. I like those
things to be different.
Agreed, but in the domains I work in, those different things
also tend to have different behavior; they're not std::vector,
but rather only support a subset of the operations on
std::vector. (But this may be domain specific. I have
practically no experience in scientic processing, for example.)
Thus:
struct xxx_vector : public std::vector< double > {
// boilerplate code
};
is (in some ways) just an alternative to:
typedef std::vector< double > xxx_vector;
The derivation trick has the advantage that I can choose
whether I want to allow conversions or not. Also (although it
is not clear whether it always is an advantage), I can
overload functions on the semantics of vector.
That's the point that's bothering me. I would have imagined
(being somewhat na?ve in this domain) that many of these vectors
would have constraints, and that you'd want to replace all of
the non-const functions of vector to enforce those constraints.
At which point, you don't want the client code to be able to
access it as a vector, and avoid your enforcement (and from the
client's point of view, the isA relation to vector doesn't
exist, since there are operations which would be legal on vector
but are not allowed here). Which argues for private
inheritance, with using declarations for the const functions.
Maybe a look at examples is helpful.
a) Linear Algebra.
[Usually, you would just go with a special library that has matrices and
vectors as ready to use templates and be done with it. So this example is
only for illustration.]
Here, a straight forward thing to consider is std::vector< double >. Now,
such a critter can denote at least two things: (a) a position in a vector
space of some dimension, or (b) a translation. Positions and translations
are semantically distinct. However, both allow for the same handling and
both have no restrictions on the coordinates.
The most common additional invariant that arises in linear algebra is fixing
the dimension. E.g., if you work in 3-space, you will want your vectors to
have size 3. The obvious solution is to use std::array< double, 3 > instead
of std::vector.
Typically, you will not have restrictions on the coordinates. What comes to
mind would be probability matrices: all entries between 0 and 1 and columns
add up to 1. In that case, I would use containment.
b) Word Processing.
There are some interesting algebraic structures whose elements can be
represented as words over a fixed alphabet. Concatenation will be the most
important basic operation. For instance, elements of a "free group of rank
two" can be represented as finite words over the alphabet {a,b,A,B}. To
make life more interesting, there are cancellation rules: pairs of adjacent
aA, Aa, bB, and Bb may be deleted or inserted at will. A word is "reduced"
if it does not contain such a pair. Theorem: every word can be reduced by a
sequence of cancellations (obvious) AND the result does not depend on the
sequence used (non-obvious). It is easy to implement functions like
bool is_reduced ( word const & w );
and
word reduce ( word const & w );
using that theorem.
Now for implementing the word class, one could be inclined to derive from
std::vector< short > with the convention
a = 1 b = 2 A = -1 B = -2
which would make it easy to check for possible cancellations: just add the
two adjacent letters and if the sum is 0, then they cancel. That would,
indeed give rise to additional invariants: all elements of the vector are
supposed to be 1,2,-1, or -2. This is bad, since vector< short > will not
enforce that.
One way to deal with that is to wrap the vector into a class that hides the
public interface. Another way is to create a Letter class that has only
four values (a,b,A,B) and use std::vector< Letter > instead. Both methods
are viable. I find that you will usually want to have the Letter class to
model the underlying alphabet anyway, in which case the second solution
suggests itself.
I rather suspect that this case is fairly frequent, and that
some means of publicly inheriting the const interface, but
keeping the non-const interface private, might be useful. But I
can't think of what it would look like (and you'd really want
the non-const interface to not be inherited at all, so that it
wouldn't be considered in overload resolution).
This idea of
class : public const Base { ... };
is intriguing. I have to think about that some more.
That also prompts the question: with private inheritance and using, is there
a way to only make visile the const member with a given name?
Best
Kai-Uwe Bux