"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.
... // non-const version, at()