Re: Boost scoped_ptr design question
"James Kanze" <james.kanze@gmail.com>
std::vector doesn't guarantee bounds checking. The way
iterators work is a bit awkward, to say the least (but I guess
you could use std::vector without using iterators). And it's
all too easy to accidentally invalidate an iterator (and have
the code pass all of your tests, because you've invalidated it
by doing push_back into a very large vector, and the probability
of it requiring a reallocation is low).
Most STL implementations have pretty good diag support. Unfortunately it is
not that easy to use -- you may be forced to build the whole project with
special settings -- but tests then can flag many such mistakes.
iterator/reference invalidation is certainly a property of vector, but it is
not part of misdesign by any means -- and the engineer shall chose the
proper collection type with knowledge of that. Node-stable collections are
more hassle to use, but we chose those if invalidation is not contained in
the design.
They're there. They work. Most importantly, you can (or should
be able to) expect any new hire with C++ experience to know them
already. Those are powerful pluses; enough to outweigh the
minuses most of the time.
At least that is the common belief. What puts too much inertia agaist
introducing some better fitting thingy. And the more shame to those who
dumped this low quality thing on the world just because we demanded speed of
standardisation. (myself included. much regret)
The completeness of the library is also an argument. I (and no
one I've worked with) likes the fact that you need two iterators
to do anything.
The iterator concept in STL is just broken. I could not put my finger on it
how -- until Alexandrescu summarized it properly. The fundamental design of
them started from 'a plain pointer must be a first class random access
iterator'. Instead of principles around the iterator as design pattern (say
in GOF).
But we learn the idiom, and use it, because
there's so many useful things in the standard library that
require it.
Are they really that useful? I have a suite of algos that thake a
collection as argument -- and found to use almost exclusively those.
Dealing with sub-ranges in a collection appears to be just very rare. (and
where it isn't, say strings, I never thought using iterators in the first
place.)
(When I have to design a new container, with an
iterator, I make sure that the iterator supports both the STL
and the GoF iterator idioms. The GoF idiom is a lot easier to
use, and a lot more flexible, but there's so much which uses the
STL idiom, you can't avoid it.)
That sounds like 'lock-in' to stuff you also recognised to be less than
good.