Re: Inherite form stl container classes
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.
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.
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.
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.
Come to think of it: I have a case---the FieldArray at my
site---where the constructors and assignment operators are
different from std::vector, but the class does use std::vector
in its implementation, and the non-mutable interface is exactly
that of std::vector. The class goes back to long before the
STL, and is widely used in my code, so I'm not going to change
it now. But thinking about it... the restriction to the
non-mutable interface isn't really necessary, and public
derivation from std::vector< std::string > would make perfect
sense. And thinking about it even more: perhaps just having the
client code declare an std::vector<std::string> directly, and
providing free functions to set its value, would also make
sense.
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. Perhaps the key is the idea that an std::vector
(and its derived classes) shouldn't be allocated dynamically.
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.)
A final real issue with public inheritance from std::vector is
the introduction of additional invariants (e.g., the condition
that the sum of all elements be 0). That cannot work since the
underlying base class allows client code to invalidate the
invariant.
That's a different issue. If you need additional invariants,
then you must derive privately or use containment; since you
also have to replace all modifier functions so that you enforce
the invariant, it's probably just as simple to use containment.
But it does raise an interesting question: is there any way to
promote just the "const" interface of a base class, so that the
derived class "isA" base, but only for clients which don't
modify it in any way. (That would correspond to what I want in
my FieldArray as well.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34