Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Yes, unfortunately, the usability ends there. But as the name suggests, it looks if the key exists, but does not return it.
If you wanted it returned, I would find it easier to check like
Just like a pointer.Code:std::map<K,V>::iterator iter = map.find(key); if (iter) { std::cout << iter->second << std::endl; } else { std::cout << "No such key: " << key << std::endl; }
I'm dead against this kind of encapsulation. has_key is supposed to be a member function of std::map instead, not broken into bits outside.
Actually, I think there's a limitation: suppose you have a std::map<std::string, std::size_t>, as per my word count example. If you try a has_key(map, "word"), the code will not compile since the string literal's type does not match the map's key type.
One solution is to change the call to has_key(map, std::string("word")). A possibly better solution is to change the function template to:
EDIT:Code:template<typename T> bool has_key(const T& map, const typename T::key_type& key) { return map.find(key) != map.end(); }
This is the same thing as discussed in the "std::string is a monolithic type" article by Sutter. has_key() can be implemented as a non-member non-friend.I'm dead against this kind of encapsulation. has_key is supposed to be a member function of std::map instead, not broken into bits outside.
Last edited by laserlight; 04-11-2008 at 05:52 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Are you sure that there is no need to compare the iterator to map.end(), i.e., the one past the end iterator is guaranteed to evaluate to false?Originally Posted by Elysia
No, turning it into a member function would make no difference in terms of efficiency. The problem is simply that the iterator to the element is discarded.Originally Posted by manav
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
No, whether you implement has_key as a direct function in the class implementation or you do it as a external function, it will have to search for that key. [] or find will ALSO have to search for that key - the only way to avoid that would be to cache the searches inside the class, which would only help if you often do things like the above example of
The point being that if you use find() correctly, then you do NOT need to search twice, because you use the original find result to determine if the data is there or not.Code:if(m.has_key(key)) ... m[key] ...
I may not be a template (or map) demon, but I do understand that the key would have to be searched for each of those cases.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Okay so now i got it! due to some strange reasons, i have to, and i will, avoid the more clear syntax of accessing map elements.
and will be using find(), forever ... big alas!
Well, as I said, I don't like it. It may be good, it may have advantages, but I'm not forced to like it. My philosophy is that if it's part of the object, then it's a member function, end of story. Other views differ, of course, this is just my own view.
I don't know, but the optimal implementation in my eyes, is that if operator bool returns true, it guarantees that the iterator is valid and if false, then invalid.
I don't see why you think std classes so lacking.
In Python you might write something like this:
In C++ that would be:Code:try: print map[key] except KeyError: print "No such key"
The main difference is that in C++ you normally check before jumping, and in Python it is OK to jump first and then handle the consequences (you could check first but that would mean the dictionary is searched twice).Code:map<A, B>::iterator it = map.find(key); if (it != map.end()) cout << it->second << '\n'; else cout << "No such key\n";
The C++ code also requires a bit more typing (the iterator declarator could be shortened with a typedef - and the auto keyword in the next standard would make it more convenient), but the basic structure is still quite the same.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
speak about has_key() efficiency, even java has the function, and also another one:
C++ people are sick with efficiency concerns, no doubt, since they are from the older days of scarce resources!containsKey(Object key), containsValue(Object value)
modern technologies, alas, when will C++ people awake!
the standard itself is 10 years old now!
anon: not too much trouble, if, c++ people could just think about it like this:
Code:put(key, val); get(key,defval=...);
Last edited by manav; 04-11-2008 at 06:15 AM.
Apples to oranges. Java doesn't have free functions, so they're not an alternative.even java has the function
Bla, bla, bla.modern technologies, alas, when will C++ people awake!
That's why a new one is in development.the standard itself is 10 years old now!
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I personally am not forcing you to use C++. I presume that if you work for a company for example that they may take an interest in what language you use.
But strictly speaking, efficiency is one reason to use C++ - if you don't care about it, that's another matter. Providing functions that promote efficient use of the underlaying data structures make sense, however.
Yes, modern hardware has lots of memory and lots of clockcycles per second (at least in a PC), which allows the use of "slower" coding practices when that's suitable. Fine - that doesn't mean that C++ should be changed to be slow always, does it?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
i am already *forced* to use C++ by my project!
that's not what i meant. don't make the stuff slower deliberately. i just meant that java, by design, is slow language.Yes, modern hardware has lots of memory and lots of clockcycles per second (at least in a PC), which allows the use of "slower" coding practices when that's suitable. Fine - that doesn't mean that C++ should be changed to be slow always, does it?
hashing, by principle, i think, needs a lot of processor time. if interpreted (by design, there are improvements, but C++ is still more close to processor) java can bear a little in-efficiency, then why can't this be done in super fast (actually fastest possible OO language) language C++.
Hashing a string shouldn't be terribly inefficient - obviously if the string is VERY LONG, then it will be, but in essence it's (most often) just a combination of 32-bit shift and xor operations, and then a truncation to the size of the hash-table.
Java is inefficient because it's an interpreted (through the byte-code form) language, more than because the classes that are implemented in it are inefficient. Properly compiled (to native machine language) Java should be only marginally slower than C++ (commonly because of language structure/implementation differences - e.g. Java has only virtual functions, C++ allows for non-virtual when the programmer so desires, which helps the speed of function calls).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.