Re: inheriting from std::vector bad practice?
On Apr 6, 5:41 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Apr 5, 6:27 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
That's always a problem when you use a standard container. He's
made the choice that his type will have random access iterators,
and will support insertion at the end (but not necessarily
elsewhere) in amortized constant time.
Well, that's what I'm wondering. Ie did he intentionally want
to provide those guarantees or is it something he wasn't fully
aware of and hadn't thought through?
I understand. In a lot of ways, I think I agree with you. At
least, I don't derive from standard containers in header files.
I may have been being a bit too indirect: he has made a choice
to provide a specific interface. Whether it is a good choice,
or even an intentional choice, I don't know (but I suspect that
I could make a pretty good guess---probably similar to yours).
And of course, there's always the possiblity that this is, in
fact, just a helper class, defined in a source file, rather than
a header, where he's in control of everything.
(Seriously, I think your points are good. I'm just in one of
myh ornerary moods, where I try to disagree with everyone.)
[...]
Note that using composition, then using a typedef for the
iterator, has the same problem. I have a couple of classes that
"wrap" the iterator precisely for this reason.
How exactly does wrapping the iterator provide a barrier to
assumptions regarding invalidation semantics?
I wasn't thinking so much of invaliation, as of iterator
category. The wrapper only provides a forward iterator, even
though the underlying iterator is (at present, at least) a
random access iterator.
Do you document the invalidation semantics for your "wrapped"
iterators? And do you document the complexity of the
operations? etc.
In the case in question, the underlying container is immutable
(once the iterators are made available), so invalidation isn't
an issue. But in general, you're right. One should never
provide an iterator without documenting when and if it might be
invalidated. (With regards to complexity: I expect all of the
operations that an iterator supports to have constant time.)
It seems to me, given the current version of C++ (ie without
concepts etc) that documentation (rather than code, wrapping
or otherwise) is the primary source of such semantics.
Largely. Still, if you don't support operator+=, then there's
no issue in how much time it takes:-). And even concepts only
go so far; I don't think they can express complexity guarantees,
for example, and they can't express all of the required semantic
guarantees (e.g. concerning the semantics of assignment and
copy, for example).
--
James Kanze