This is simple? This is hideous compared to the natural operator[]
usage.
Still, the STL version is worse:
std::map< X, int >::const_iterator it = hm1.find( key ) ;
int a = it == hm1.end() ? 42 : *hm1 ;
The real problem in reading a map (or a hashmap) is how to
handle missing values. Sometimes, an exception is appropriate,
but it's not a good general solution. So you need something out
of band.
Whatever the documentation for your system tells you. The
latest draft says <unordered_set>, but this is fairly recent,
and it's likely that your implementation still uses something
pre-standard. Which it *should* document.
If you want to be a programmer, you should at least know how to do a
recursive directory search for filenames including *hash*. Really,
kids these days.... ;-P
Given that the correct name is unordered_set, searching for a
file whose name includes *hash* isn't going to help. More
generally, of course, recursive directory search is almost
certainly the wrong way to go about it here.
FWIW, many people just use std::map, which has a similar interface,
the benefit of sorting the elements, is standardised and portable
(just #include <map>), and is unlikely to have a noticeable
performance difference unless you're inserting tens of thousands or
more elements for frequent lookup or the elements are difficult to
compare. Basically, map does a binary lookup which typically requires
approximately log2(N) element comparisons, or 10 for a thousand
elements, 20 for a million....
The advantage of std::map is that it has been in the standard
from the very beginning, and so is standard. The various
pre-standard implementations of hash_map varied somewhat, which
created no end of portability problems. In the near future, of
course, there's std::unordered_map. But I don't think you can
count on it yet.
Note too that std::map guarantees O(n ln n). unordered_set will
be *typically* O(n), but only if you have a good hashing
function on the key. And good hashing functions are not
necessarily trivial to come by.