Re: Inherite form stl container classes
James Kanze wrote:
On Jun 2, 10:18 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
ademirzanetti wrote:
On Jun 2, 4:33 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
ademirzanetti wrote:
I would like to listen your opinions about inherit from a
STL class like list. For example, do you think it is a
good approach if I inherit from list to create something
like "myList" as in the example below ?
#include "Sector.h"
using namespace boost;
typedef std::list<Setor>::iterator ListaSetorIterator;
typedef std::list<Setor>::const_iterator ListaSetorConstIterator;
class SectorList: private std::list<Sector> {
public:
using std::list<Sector>::begin;
using std::list<Sector>::end;
SectorList();
~SectorList();
result add( const Sector& );
result modify( const Sector& );
result get( Sector&, const uint32_t ) const;
result remove( const uint32_t );
private:
using std::list<Sector>::push_back;
Just wondering, but what does the above statement do? (As I
understand it, it makes the base class function available for
private use in the derived class. But the base class function
was already available for private use. The using declaration
would make sense if it were public, and it would make sense if
the SectorList class also had a push_back function, which would
otherwise hide the base class function, but neither of those
seems to be the case here.)
};
I do not see a problem on it. I believe it is better to
inherit in this way than try to create my own list from
scratch, but I also want to listen more opinions about
it.
Thanks in advance ;-)
I am not sure what it is you're expecting us to tell you.
Private inheritance is a method of implementing your class
in terms of the other class. You're essentially creating
an Adapter (see Adapter pattern, Goa book or on the web).
Another way to program an Adapter in C++ is containment.
You've followed one of the two ways commonly accepted, why
wouldn't it be a good approach?
I suppose you're not expecting us to criticise your code on
its own merits, like the degree of completeness of the
interface without any given requirements, or typos, or
extraneousness of some declarations...
Actually, the questions is, Is there any issue inheriting
from STL classes ? I read some papers which say that the
"STL classes were not created to be inherited", but they did
not mention the reasons. They says that there are some
pitfalls when it is used in this way that are hard to avoid.
a) That paper probably referred to public inheritance. Private
inheritance from STL containers does not present any problems.
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.
Maybe the solution is to forbid dynamic allocation of such
objects in your coding guidelines, so that any delete of an
std::vector would be considered an error, and caught by code
review.
That would be my inclination.
b2) Functions of the type
template < typename T >
std::vector<T> reverse ( std::vector<T> const & v );
will match any object derived from std::vector but usually
have the wrong return type.
This is a more serious objection. However, it is not at all
clear whether inheritance from std::vector is to blame or
whether the function reverse is just ill-designed. Maybe, it
should be:
template < typename Sequence >
Sequence reverse ( Sequence const & v );
possibly enriched by some template magic to make sure it only
matches sequences.
You mean by maybe using begin() and end() in its implementation
(or more likely rbegin() and rend(), in this case---and the
sequence must support at least bi-directional iteration).
More generally, if I'm deriving publicly from std::vector, I'm
saying my class isA std::vector, so there's probably no problem
with the return type above. All you're seeing is the same sort
of slicing that always occurs when you use derived classes by
value.
Actually, in the cases where I derive from std::vector, there won't be any
slicing since I never add data member. In that case, a function like
reverse is no problem at all. You just add conversions:
template < typename ArithmeticType >
struct arithmetic_vector : public std::vector< ArithmeticType > {
...
arithmetic_vector ( std::vector< ArithmeticType > const & other )
: std::vector< ArithmeticType >( other )
{}
arithmetic_vector &
operator= ( std::vector< ArithmeticType > const & rhs ) {
...
}
};
Then, you can do:
arithmetic_vector< double > v = reverse( w1 + w2 );
In practice, the only cases I've seen where it would make sense
at the design level to publicly derive from std::vector is to
provide special, initializing constructors. Once the object has
been constructed, it *is* an std::vector, for all intents and
purposes.
The cases where I derive from std::vector are a little different, but it is
still true that the derived class *is* a std::vector and in particular does
not add any data members. I usually use it only to distinguish semantically
different vectors in the type system.
[snip]
Therefore, it depends by and large on your code base whether
this problem is easy to avoid or not. If you have functions
like reverse whose signatures have been frozen, it can be
cumbersome to derive from container classes.
With public inheritance from standard containers, you have to
be aware of the above caveats. If you are (and you are
confident that the maintenance programmers who will have to
deal with your code are, too), then inheriting publicly from
standard containers can be justified in certain cases. E.g.,
if you are doing linear algebra, you might want to overload
operator+ to do element wise addition. It would be a bad idea
to just dump that overload into global namespace for all
vectors (e.g., it might interfere with the idea of someone
else to have operator+ denote concatenation of sequences). In
that case, a quick
template < typename ArithmeticType >
struct arithmetic_vector : public std::vector< ArithmeticType > {
// some constructors
};
template < typename ArithmeticType >
arithmetic_vector< ArithmeticType >
operator+ ( arithmetic_vector< ArithmeticType > const & lhs,
arithmetic_vector< ArithmeticType > const & rhs ) {
assert( lhs.size() == rhs.size() );
...
}
can serve as a templated typedef that does not create just an
alias but a true independent type (that will convert
transparently to std::vector in cases needed and with the
right constructor, conversion the other way around is also no
problem). However, private inheritance with a complete set of
forwarding methods is considered cleaner by many.
I very much appreciate this example. It's the sort of thing
that wouldn't occur to me, because it's in a domain I'm not
familiar with.
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. 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.
Perhaps the key is the idea that an std::vector
(and its derived classes) shouldn't be allocated dynamically.
Yup. And why would you want to do that anyway?
Ban such dynamic allocation, and you eliminate the most serious
problem: a delete through the pointer to the base class. (And
you can even ban such allocation, by declaring a private
operator new in your derived class.)
That's an interesting idea. Maybe, I should do that (just as a safeguard).
[snip]
Best
Kai-Uwe Bux