Re: Is there a proposal to fix the operator[] (rvalue/lvalue issues)??
Greg Herlihy wrote:
"Gene Bushuyev" wrote:
<jose.diego@gmail.com> wrote in message
news:1155678420.260516.259860@74g2000cwt.googlegroups.com...
I made the following function to access a map elements to simulate the
operator[] in a const map
template<typename MapType>
const MapType::value_type::second_type get(const MapType map, const
MapType::value_type::first_type value) {
MapType::const_iterator it = map.find(value);
if( it == map.end() ) return MapType::value_type::second_type();
return *it;
}
If the std::map<>::operator[] could be used as an rvalue,
it could have the above implementation
What do you think?
Your solution is already problematic because it breaks the
standardized behavior.
The "standardized" behavior - if std::string or std::vector is
any kind of example - is to implement both a non-const and
const operator[]. By implementing only a non-const operator[],
std::map would appear to be the exception.
The "standardized" behavior---if std::string, std::deque,
std::vector and T[] are any kind of example---is for operator[]
to take a unsigned integral type as parameter, and to return a
reference to the (n+1)'th element. std::map is definitly an
exception.
[...]
You seem to be unaware that std::map already implements a
non-const operator[]. Its behavior is to insert a value when
invoked with a key not already present in the map. The
question here is the best analagous behavior were a non-const
operator[] added to std::map.
Don't want to speak for Gene (we disagree often enough), but I
think his point is that there is no analagous behavior.
I personally would prefer exception, but in the final
analysis it's not important. Using iterators is more logical
with associative containers and doesn't have any of these
problems, and that's what people are accustomed to doing -
using find(), lower/upper_bound(), etc.
For programs that currently retrieve values by indexing a
non-const std::map - being able to access a const std::map in
the same way does seem useful.
Except that the semantics of indexing in the current version of
std::map don't make sense for a const object. This may be the
result of an abuse of operator overloading, but it's there, and
we have to live with it. (If we based our specification on the
behavior of [] for vector, deque and built-in arrays, trying to
access an inexisting element would be undefined behavior. And
we'd need some sort of function, say contains(), since size()
obviously wouldn't be the correct name in this case, to
determine beforehand whether the element was present.)
After all, most programmers expect the non-const and const
versions of an object to behave consistently.
There doesn't seem to be any consensus as to what the behavior
of [] on a map should be, so it's hard to say. I would expect
that [] on a const and on a non-const map have the same
behavior, but then, I'd also expect undefined behavior if the
element wasn't present (and I'd expect the argument to be an
integral type, but that's another question).
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ 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.comeaucomputing.com/csc/faq.html ]