Re: inheriting from std::vector bad practice?
On Apr 3, 10:56 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:429045e5-51ab-4100-b065-de5dc8c29cb3@35g2000yqm.googlegroups.com...
One thing is clear: using free functions rather than derivation
is a lot less likely to upset others who have to read your code
(unless they come from a Java background, and expect the C++ to
look like Java). IMHO, that's a very strong argument in favor
of free functions.
Your fondness of free functions probably stems from the fact
that you used to be a C programmer (joke) or that <algorithm>
is full of them.
Or from discussions with Scott Meyer, which convinced me.
More generally, I don't have a particular fondness for free
functions. But in some cases, they are a better solution than
anything else. If the function can apply to any
std::vector<SomeType>, then a free function seems most
appropriate. You're not introducing a new type, with additional
functionality which isn't present in the base class; you're
introducing new functionality over an existing type (or types).
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.
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).
--
James Kanze