Re: inheriting from std::vector bad practice?

From:

Stuart Golodetz <sgolodetz@NdOiSaPlA.pMiPpLeExA.ScEom>

Newsgroups:

comp.lang.c++

Date:

Tue, 06 Apr 2010 13:44:10 +0100

Message-ID:

<6c-dnd3R-_UHsSbWnZ2dnUVZ8rKdnZ2d@pipex.net>

Leigh Johnston wrote:

"Stuart Golodetz" <sgolodetz@NdOiSaPlA.pMiPpLeExA.ScEom> wrote in
message news:YfWdneGYbNE75yfWnZ2dnUVZ7oadnZ2d@pipex.net...

Kai-Uwe Bux wrote:

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

I suspect I can't provide an example, because I think I missed a trick
in regard to vector's member functions being non-virtual(!) Thanks for
pointing that out :) I'm inclining to the view that LSP is satisfied
in that case -- what you have are essentially two views on the same
sequence, depending on whether you view it as a vector or a
base_vector, which I guess was what was intended.

Cheers,
Stu

I think that in Java (correct me if I am wrong) all "overridden"
functions are in effect virtual so LSP would be broken in that case for
Java? Silly Java.

/Leigh

I guess the problem only arises were you to write the same sort of thing
in Java *knowing* that that's how Java does things :) The decision to
make all non-static, non-final member functions implicitly virtual is
certainly open to question on some grounds (though personally I find I
don't mind it), but it's not a questionable decision on the grounds of
this example not working the same way in Java -- if you're writing in
Java, you just have to play by its rules.

Stu