"Joseph Gottman" <joegottman@worldnet.att.net> wrote:

>
>    Why doesn't the STL map class have an at() member function?  It seems to
>me that such an at() function that acted like similar functions for vectors
>and deques (throwing a range_error exception when an incorrect index was
>input) could be quite useful for several reasons:

I support this idea and also think that there should be a const
operator[] which would work just like your at() function. Unfortunately,
I don't think that this falls in the "defect" category, so it can't be
considered for this round of the standard.

It's a bit tedious, but you could implement a Map class that had this
feature, built on top of (or even derived from) std::map.

---------------------------------------------------------------
Pablo Halpern                              phalpern@newview.org
Check out my new book, The C++ Standard Library from Scratch at
http://www.halpernwightsoftware.com/stdlib-scratch


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

    Why doesn't the STL map class have an at() member function?  It seems to
me that such an at() function that acted like similar functions for vectors
and deques (throwing a range_error exception when an incorrect index was
input) could be quite useful for several reasons:

   1) It would not have to call the default constructor.  operator[]() on
maps works by attempting to insert a default object, and returning a
reference to either the newly created object or the newly created object
that caused the insertion to fail.  The at() member could use find().  Then
it could either throw an exception if the find failed, or else return a
reference to the found object if the find() succeeded.  This would make at()
usable with value types that lack a default constructor, and improve
performance for ones with nontrivial default constructors.

    2)  It would be easy to create const and non-const versions.  It is
impossible to have a const operator[]() because whenever operator[]() is
attempted with a key that is not already in the map a new key is added.
Since at() would throw an exception in this case, it would be easy to create
a const version that returns a const_reference and a non-const version that
returns a regular reference.

   3) One of the hazards of operator[]() is that it can silently add a new
element to a map when this is not what the user wants.  This kind of bug can
be difficult to track down.  By using at() in cases when the user "knows"
that the key is already in the map, the user can make this error much easier
to catch.

Joe Gottman




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]