From -7939446303788918673 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c0e61b6a667823c0 X-Google-Attributes: gidf78e5,public From: AllanW@my-dejanews.com Subject: Re: no const operator[] in STL map? Date: 1999/01/26 Message-ID: <78ir3g$cin$1@nnrp1.dejanews.com> X-Deja-AN: 436957560 Approved: Fergus Henderson References: <916993358.766341@aloomba.aaii.oz.au> <36ABD140.DAC0F0AA@mindspring.com> X-Snookums: I love you X-Original-Date: Mon, 25 Jan 1999 22:27:07 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) X-Complaints-To: news@news.unimelb.edu.au X-Http-Proxy: 1.1 x9.dejanews.com:80 (Squid/1.1.22) for client 199.125.171.23 X-Trace: izvestia.its.unimelb.edu.au 917323258 17699 128.250.29.16 (26 Jan 1999 04:00:58 GMT) Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Mon Jan 25 22:27:07 1999 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANq09zOEDnX0m9pzZAQEd3gF/VzwSe1Drx09tFwGzWdCpQuA6Tr+RhiXB U+axsGT1LT827k3YyKienM35mN8Nt5GV =UM5U NNTP-Posting-Date: 26 Jan 1999 04:00:58 GMT Newsgroups: comp.std.c++ In article , sbnaran@uiuc.edu wrote: > On 25 Jan 99 02:34:00 GMT, Bruce Visscher wrote: > >Siemel Naran wrote: > >> But there is a logical alternative if const operator[] can't > >> find the object with key_type 'key' in the map. Just throw an > >> exception. > > > >I agree that it would have been nice had the standard provided a const > >operator[]. However, I don't agree that it should throw. To me there is an > >obvious alternative: return by value rather than by reference and return > >mapped_type() if the key is not found. > > This would involve lots of copying if mapped_type were a large > object. Besides, the user may want to know if the lookup of > the object failed as they may write code like this: > > try > { > int i; > cin >> i; > map[i]=9; > } > catch (typeof(map)::non_existent) { } But the catch never hits, because if map[i]=9 is valid then the map must be non-const, so this is the non-const operator[] which creates the element. If what you meant was something like this: try { int i; cin >> i; cout << myMap[i]; } catch (typeof(myMap)::non_existant) { // Do something else } then we could rewrite it as int i; cin >> i; if (myMap.count(i)) { cout << myMap[i]; } else { // Do something else } > >One useful application for map suggested in [Musser & Sauni] is that of a > >sparse array. With a const overload implemented like this you would get > >consistent behavior (m[x] returns mapped_type() if x is not found whether or > >not m is const). In fact, the const overload would be the one to use if > >wherever possible for a sparse vector. You wouldn't want to allocate > >10000000 elements if you did: > > Once one has an operator[] that throws an exception if the object does > not exist, one can write an adaptor that returns a value, and a default > value if the object does not exist. But if one has an operator[] that > returns a value, then one can't engineer this to turn it into a > function that throws if the object didn't exist. myMap::operator[](Key &k) throw(non_existant) { if (count(k)<1) throw(non_existant()); return BaseClass::operator[](k); } > >There is precedence for my suggestion too (typing the following in from my > >pdf copy, I hope I don't make any mistakes): > > > >26.3.2 Template class valarray > >[...] > > template > > class valarray { > >[...] > > // 26.3.2.3 element access: > > T operator[](size_t) const; > > T& operator[](size_t); > >[...] > > > >It's not that unusual in my experience to see non-const overload of > >operator[] return by reference while the const overload returns by value. > > The reason why valarray can have its constant operator[] return > by value is that there is something to return. > > I have no idea why valarray returns by value. It should just > return by const reference. As operator[] is inline, the lvalue > returned (ie, const T&) should be converted at compile time to an > rvalue (ie, T). The const version returns by value so that it can still be used in most places that a read-only reference can be used, and yet it may also return a default-constructed object for which there is no element to refer to. > >This seems to bother some, though, so you could instead return by reference > >to const and statically allocate a default constructed mapped_type when > >needed instead (i.e., the first time map::operator[] const was invoked for a > >non-existant key). I did something similar a few years ago. As I recall, I had trouble convincing my compiler to create a class static object of parameter type, so I ended up creating one extra instance for each class. More modern compilers shouldn't have that trouble. > The use of static objects to represent null objects (so that you > can return a null reference) may makes things harder for > maintainance... [continues about problems with "null object"] Bruce Visscher wasn't writing about a null object, he was writing about a default object. Currently for non-const maps, operator[] initializes the element by calling the null constructor. This allows you to write: ++myMap[key]; If your class initializes itself to some equivalent of 0, and operator++ does the equivalent of adding 1, then this will correctly count how many times each key was incremented. The same thing ought to apply when reading a map, which can be done when the map is read-only. std::cout << myMap[key]; ought to report how many times key was incremented, even if that number is 0 times. ---- AllanW@my-dejanews.com is a "Spam Magnet" -- never read. Please reply in USENET only, sorry. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --- [ 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 ]