Hello.

Searching around before posting this message revealed that the issue has=20
been brought up a significant number of times (here are two related=20
threads [1] [2]). So /std::map<>/ does not provide a const version of=20
its /operator[]/ member function because that function is supposed to=20
modify the map in case the passed key is not present. The question which=20
follows is: why not provide a const overload which would throw when the=20
given key would not exist? It seems like a natural and easy-to-implement=20
solution which would contribute to map's associative array role.

In spite of having found several discussions on this topic, I could not=20
find mention of whether this issue is going to be addressed when C++=20
gets its next major revision. Could anyone provide some information=20
(comments, links, etc.) on this?

[1] http://groups.google.com/groups?hl=3Den&lr=3D&th=3D47b92be5c9ed558c&r=
num=3D1
[2] http://groups.google.com/groups?hl=3Den&lr=3D&th=3D698e93dddf8b22d0&r=
num=3D5

Thank you very much,

--=20
Ney Andr=E9 de Mello Zunino

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ney Andr=E9 de Mello Zunino wrote:

> Hello.
>=20
> Searching around before posting this message revealed that the issue ha=
s=20
> been brought up a significant number of times (here are two related=20
> threads [1] [2]). So /std::map<>/ does not provide a const version of=20
> its /operator[]/ member function because that function is supposed to=20
> modify the map in case the passed key is not present. The question whic=
h=20
> follows is: why not provide a const overload which would throw when the=
=20
> given key would not exist?=20

Because it would violate the important principle that adding
const to code should not change its behaviour (except for
propogation of constness to other code), although it may
cause it to no longer compile.  The language doesn't enforce
that in isolation; good library design is also necessary.

> It seems like a natural and easy-to-implement=20
> solution which would contribute to map's associative array role.

But it's too fragile, for the reason above.

> In spite of having found several discussions on this topic, I could not=
=20
> find mention of whether this issue is going to be addressed when C++=20
> gets its next major revision.=20

I find it enormously unlikely that this would be changed in the
next revision of C++.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:YWxrd.191852$hj.44035@fed1read07...

> In spite of having found several discussions on this topic, I could not
> find mention of whether this issue is going to be addressed when C++
> gets its next major revision.

|I find it enormously unlikely that this would be changed in the
|next revision of C++.

yes true. but we are already looking into adding

T& map<K,T>::at( const Key& );
const T& map<K,T>::at( const Key& ) const;

which should throw if nothing is found.
Alternatively, I guess we could use operator()().

-Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:

> "James Dennett" <jdennett@acm.org> wrote in message
> news:YWxrd.191852$hj.44035@fed1read07...
>
>
>>In spite of having found several discussions on this topic, I could not
>>find mention of whether this issue is going to be addressed when C++
>>gets its next major revision.
>
>
> |I find it enormously unlikely that this would be changed in the
> |next revision of C++.
>
> yes true. but we are already looking into adding
>
> T& map<K,T>::at( const Key& );
> const T& map<K,T>::at( const Key& ) const;

This is reasonable and somewhat consistent with the at
member in other standard library class templates.

> which should throw if nothing is found.
> Alternatively, I guess we could use operator()().

I wouldn't like that:
   mymap[1] = 3;
and
   mymap(1) = 3;
would then both be valid, with different semantics in
the case mymap.find(1) == mymap.end(); and identical
semantics otherwise, but they look too similar.  Let's
be consistent, and use "at" when we mean range-checked
access which throws if an element is absent.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri,  3 Dec 2004 02:54:24 GMT, nesotto@cs.auc.dk ("Thorsten
Ottosen") wrote:

>"James Dennett" <jdennett@acm.org> wrote in message
>news:YWxrd.191852$hj.44035@fed1read07...
>
>> In spite of having found several discussions on this topic, I could not
>> find mention of whether this issue is going to be addressed when C++
>> gets its next major revision.
>
>|I find it enormously unlikely that this would be changed in the
>|next revision of C++.
>
>yes true. but we are already looking into adding
>
>T& map<K,T>::at( const Key& );
>const T& map<K,T>::at( const Key& ) const;
>
>which should throw if nothing is found.

I like the symmetry with vector::at.

>Alternatively, I guess we could use operator()().

I don't like that, since operator() hasn't been used like that
elsewhere and is usually used for functors.

Tom

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

    If anything is done to "operator[]", it should be given
the same syntax as "operator()", so we can have classes that
support multiple subscripts.  Inconsistently,

 foo(a,b)

is a two-argument call, but

 foo[a,b]

is an invocation of the comma operator followed by a
one-argument call.  One of the more obscure features
of the language.

        John Nagle
    Animats

Tom Widmer wrote:

> On Fri,  3 Dec 2004 02:54:24 GMT, nesotto@cs.auc.dk ("Thorsten
> Ottosen") wrote:
>
>
>>"James Dennett" <jdennett@acm.org> wrote in message
>>news:YWxrd.191852$hj.44035@fed1read07...
>>
>>
>>>In spite of having found several discussions on this topic, I could not
>>>find mention of whether this issue is going to be addressed when C++
>>>gets its next major revision.
>>
>>|I find it enormously unlikely that this would be changed in the
>>|next revision of C++.
>>
>>yes true. but we are already looking into adding
>>
>>T& map<K,T>::at( const Key& );
>>const T& map<K,T>::at( const Key& ) const;
>>
>>which should throw if nothing is found.
>
>
> I like the symmetry with vector::at.
>
>
>>Alternatively, I guess we could use operator()().
>
>
> I don't like that, since operator() hasn't been used like that
> elsewhere and is usually used for functors.
>
> Tom
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]