Re: inheriting from std::vector bad practice?

From:

Kai-Uwe Bux <jkherciueh@gmx.net>

Newsgroups:

comp.lang.c++

Date:

Tue, 06 Apr 2010 01:46:41 +0200

Message-ID:

<hpdsp2$f0a$1@news.doubleSlash.org>

Stuart Golodetz wrote:

Kai-Uwe Bux wrote:

Leigh Johnston wrote:

"James Kanze" <james.kanze@gmail.com> wrote in message
news:c8f0c071-402c-45cd-8f93-089b4dd11e21@z3g2000yqz.googlegroups.com...

which is fine as those functions are generic whereas you can
argue that an augmented operator[] for std::vector is specific
to that container and so quite rightly should be part of a
class augmenting std::vector especially as it comes with state
that is not dependent on the vector's state (so LSP still
holds).

You've lost me again. std::vector already has an operator[], so
providing a new one *isn't* augmenting the interface, it's
changing it. Unless, of course, you're somehow weakening the
pre-conditions, or strengthening the post-conditions of the
function. And of course, operator[] has to be a member, so you
really have no choice.

When I say "augmenting interfaces" I also I include "adjusting
interfaces". I am neither strengthening nor weakening conditions as LSP
still holds and either the std::vector operator[] or the derived
operator[] can be used depending on the context.

So for a vector which supports 1-based indexing (instead of
0-based):
int f = bounded_vector[10];
is an improvement on than:
int f = access_bounded_vector(v, 1, 10);

A vector which uses 1-based indexing isn't an std::vector, so
inheritence doesn't really come into consideration. It might
be implemented in terms of a std::vector, but that would use
containment, and not inheritance.

This example simply doesn't work as a free function as what
could be state in a class (for the value 1 above) now has to
be passed to the stateless free function.

Agreed, but it doesn't work using inheritance either. You're
defining a totally new, unrelated type. If std::vector appears
at all, it is as part of the implementation (a private data
member).

It does work using inheritance as the lower bound (1 in this example) is
stored as state in the derived class (this is Stroustrup's example not
mine) and is used if the derived class operator[] is called.

Just for concreteness (so that I can follow), are you proposing something
like this:

  template < typename T >
  class based_vector : public std::vector<T> {

    std::vector<T>::size_type base;

  public:

    based_vector ( std::vector<T>::size_type b )
      : std::vector<T> ()
      , base ( b )
    {}

    T const & operator[] ( std::vector<T>::size_type n ) const {
      assert( base <= n );
      return ( std::vector<T>::operator[]( n - b ) );
    }

    ... // non-const version, at()

  };

Best

Kai-Uwe Bux

If that is what is being proposed, it violates LSP -- because a
based_vector can be passed to a function expecting a vector but it can't
be used in every way a vector can (in particular, the function can't
access its 0th element). In other words, it's not substitutable for a
vector.

Could you provide an example? I was thinking along the same lines, and
pondered the following:

  template < typename ArithmeticType >
  ArithemticType total_sum ( std::vector<ArithmeticType> const & v ) {
    typedef typename std::vector<ArithmeticType>::size_type size_type;
    ArithmeticType result = 0;
    for ( size_type n = 0; n < v.size(); ++ n ) {
      result += v[n];
    }
    return ( result );
  }

Now, if you pass a based_vector<int> into that function, I think, it will
behave "just fine". Strangely enough, the reason is that the member
functions involved are _not_ virtual.

Now, I think there are several possible reactions to this phenomenon. One is
to rethink the role of LSP another is to condemn the public derivation from
std::vector because the above seems strange and unexpected (and a third
would be to adjust expectations:-).

Best

Kai-Uwe Bux