Re: Overhead of subscript operator for STL maps
On Oct 17, 7:05 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Stephen Horne wrote:
I realise that scripting languages do it, but they get to
handle the [] differently depending on whether its on the
left side of an assignment or not. They still complain if
you try to read a non-existent key.
Actually in many languages (such as for example PHP)
relational maps work exactly that way. That is, you add an
element to the map by "indexing" it with the key and assigning
the element. This is a very common idiom eg. in PHP.
Such languages don't have const. All of the ones I know, for
that matter, are untyped, and don't require variable
declarations either. So there is always a well defined value
which can be used for initialization.
In C++, logically, you should be able to use [] on a const map
(if you're just reading). And you should be able to use [] even
if the mapped type doesn't have a default constructor.
On the other hand, one can easily argue that operator[] isn't
part the basic interface defined by std::map. It's just an
added convenience (or even an example of operator overload
abuse:-)). Most of the time, you'll wrap std::map in a class
which provides a more convenient interface for what it's being
used for, which is application specific. The presence of
operator[] is just as a convenience, for one common use, and
this particular use was chosen precisely because it happens to
be supported in a couple of other common languages (AWK, perl,
etc.)
And even with the [] on the left of an assignment, I still
think it's a bit bad, since to me the obvious intent is to
overwrite the data for an existing key.
It might be "obvious" to you because you are used to think
like that.
I think the point of something like std::map is that it is
reallly a low level building block, with a number of (sometimes
contradicting) "obvious" uses. In this sense, operator[]
doesn't really belong, so who cares what semantics it has. (In
practice, I rarely use it, relying much more on map<>::find().)
However, in many languages (such as PHP) it's obvious that you
are building a relational map by indexing it. That is, when
you say:
myMap[key] = value;
Except that that's not at all the way you build a map in C++
(and it's a very bad way of building it in other languages). In
C++, the idiomatic fashion would be something like:
while ( more elements ) {
if ( ! myMap.insert(
MapType::value_type(
element.key, element.value ) ).second ) {
// error handling...
}
}
Correctly used, find, insert and erase allow you to implement
whatever idiomatic use you need in a particular case.
when you are doing is adding 'value' at the "position" 'key'
of the map. Or if there was already such a key, you are
replacing its data with the new value.
In other words, you might be overwriting an existing value when
you don't want to.
std::map has that exact same idea (although it's not as
flexible as PHP because the type of the key and the value are
fixed). As exemplified by Erik, this can be quite handy in
some cases,
In a very few cases, yes.
C++ and PHP have very different goals. In C++, you're supposed
to be able to write robust code. This means taking advantage of
the stricter type system, const, etc. And it generally means
more thorough error checking---in most data base use, insertion
is a distinct action from update, and when you want one,
accidentally getting the other is an error.
for example because you can write things like:
words[word]++;
One single command adds a new 'word' to the map and increments
its value.
If you want to check if a key exists in the map, that's what the
find() member function is for.
And if you want to access in a way that distinguishes between
update and insert, you wrap std::map in a class that uses find
(and insert). If you want an assertion failure, or an
exception, or a returned error code for a failed update, you can
then have it.
The problem with operator[] isn't really what it does. The
problem is that it is even there, since there is no one
universally useful semantics for it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34