Re: inheriting from std::vector bad practice?
On Apr 3, 5:16 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Leigh Johnston:
"Alf P. Steinbach" <al...@start.no> wrote in message
news:hp7p5m$6rb$1@news.eternal-september.org...
I repeat: interface augmentation (which is what my reply was referring
to) is quite valid
Sometimes interface augmentation is a good idea, but in this
case there is no interface augmentation.
Strangely enough, I have to agree with Leigh here. (Doesn't
happen very often.) From what little we know of the global
context, this seems very much like what I would call "interface
augmentation". My only objection to the derivation is that in
C++ (unlike the case in e.g. Java), the idiomatic form of
interface augmentation is by using free functions: we have
std::sort, rather than std::vector<>::sort, etc.
Scott Meyers once wrote up a long discussion once about the
trade offs between free functions and members; a large part of
his point was that interface augmentation should have the same
syntax as the basic interface, *but* the types should also be
the same. IIRC, his conclusion was the best design would be to
make even the basic interface friend functions, rather than
members, and forget about the obj.func() syntax completely:-).
For things that are basically containers of data, like the case
here, I think I sort of agree with him, but we're not going to
change the interface to std::vector anytime soon.
[...]
and Bjarne Stroustrup agrees.
This is just an appeal to authority.
Or simply indicating that he's not the only one to think this.
(My books are still in boxes following two recent moves, so I
can't verify anything, but I do seem to recall Bjarne deriving
from std::vector in order to implement and operator[] which
guaranteed bounds checking. If this is what Leigh is thinking
of, of course, it isn't interface augmentation, but changing the
interface. And I'd study the text surrounding the example very
carefully to see whether it is just a suggestion concerning a
general direction, or whether it is presented as an example of
what should be done in production code. Code in pedagogic texts
follows radically different rules than production code.)
[...]
The OP is simply augmenting vector's interface as far as I
can tell (not introducing any new member variables that
contribute to an invariant larger than vector's.)
No. std::vector is a generic type, a template type. The OP is
not augmenting std::vector.
So Leigh didn't express himself as clearly as he should have.
What I understood him to mean (even if it wasn't his exact
words) was that the derived class augmented the interface of
class std::vector<Point2D>, and not of template<typename T,...>
std::vector.
--
James Kanze