Re: Boost scoped_ptr design question
On Dec 15, 10:51 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 12/16/10 11:24 AM, Balog Pal wrote:
"Leigh Johnston" <le...@i42.co.uk>
And the realistic approach to std:: is to use just parts of it in any
case.
What? Don't talk nonsense. I use most of the standard library.
For example I never used std's allocator. Or codecvt, locale. custom
streambuf. Quite sure will never use them in my life.
Some stuff I used only as temporary measure before importing proper
libraries: bind1st, bind2nd, auto_ptr.
Don't recall ever actively using: deque, priority_queue,
reverse_iterator, complex, valarray, slice
Braindead stuff I use and damn on regular basis: string, map.
What's wrong with std::vector and std::map?
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). And certainly, for many
(most?) uses, a hash table would be preferable to std::map (but
in this case, I understand why the standard didn't use one).
I'm sure most C++
programmers use them on a daily basis without complaint.
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.
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. But we learn the idiom, and use it, because
there's so many useful things in the standard library that
require it. (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.)
--
James Kanze