Re: Boost scoped_ptr design question
On Dec 16, 12:22 am, Leigh Johnston <le...@i42.co.uk> wrote:
On 15/12/2010 23:46, Balog Pal wrote:
"Ian Collins" <ian-n...@hotmail.com>
Braindead stuff I use and damn on regular basis: string, map.
What's wrong with std::vector and std::map? I'm sure most C++
programmers use them on a daily basis without complaint.
vector is about the only thing in std I'd say is okay as is. (certainly
we all had everything it offers well before the standard even was
considered.)
map has a broken interface:
- operator[] has no const variant
What would a const operator[] do if the element doesn't exist?
Throw an exception? Not very user friendly.
What does the built-in operator[] do (on a C style array)?
Undefined behavior, I'd say.
In practice, operator[] isn't that useful on map. Big deal:
it's really a case of operator overloading abuse anyway.
- operator[] that is there mutates the collection inserting
the key with a def-constructed value, that is a source of
many bugs
Then use insert.
Or anything else. If function x doesn't do what you want, use
something else.
- insert and iteration over map uses std::pair, that makes client code
unreadable. And mostly unusable with algos that are present in std:: --
Not true; I use std::map with std algorithms with no problems; you
simply have to except that a std::map's value_type is a pair.
Certainly. You can live with just about anything. But that
doesn't mean that it couldn't be cleaner.
I had to write a full suite of their dupes that act on map key or map
value...
In summary, for almost all operations involvng std::map I use some
wrappers, be it insert, lookup to tell presense, lookup to fetch
existing element, iteration.
I have wrapped std::map with a container called "mutable_set"
but this is so you can have a something similar to std::set
but with elements you can mutate; it is not intended as
a replacement for std::map whose interface is fine when you
want "map semantics" (IMHO).
I think most of the standard containers are designed to be low
level building blocks. I think it has to be this way: there is
no one interface for map which is appropriate for all high level
uses.
--
James Kanze