   hash_map and its non-standardnish - not a word
  I was surprised to learn that hash_map isn't part of the C++ STL, and consequently I'm not sure if I should use it. My compiler (VS 2003 .NET) has an implementation of it but given that hash_map isn't part of the STL, there's probably all sorts of different versions floating around. So... will that present a problem?After reading about hash_map and the advice given, hash_map was made out to be significantly faster than just map (with the appropiate equality function specified) when keeping the elements in order doesn't matter.   
  As far as I know, hash_map is part of the STL. Just look at SGI's STL documentation (clicky).   ;Quote:Original post by George2As far as I know, hash_map is part of the STL. Just look at SGI's STL documentation (clicky).If you actually read the definition part of that page, you'll see:Quote:DefinitionDefined in the header hash_map, and in the backward-compatibility header hash_map.h. This class is an SGI extension; it is not part of the C++ standard.[emphasis mine]load_bitmap_file:  Given the similarity of use of std::map and std::hash_map, I suggest that you use conditional compilation and a typedef to let you switch between them with a #define.  Go with hash_map where it's available (which is most places - even if it isn't included with a compiler's normal STL version, I believe it's included in STLport).  In the very few cases where it isn't available, switch back to std::map - it will (I assume) be slower, but hopefully not slow enough to cause a problem.  If at some point you actually find that you both: a) have to use a compiler where you can't use an existing std::hash_map implementation, and b) the std::map implementation isn't fast enough, then you can always give up an write your own hash_map implementation (probably following the same spec, and switched in with conditional compilation).John B   ;  Because hash_map is not part of the standard, there may be some portability issues. However, if the different versions are all implemented as a standard STL container, then the portability issues are likely to be very minor, if they even exist at all.   ;  hash_map isnt part of STL, SGI just provides an implementation.Quote:This class is an SGI extension; it is not part of the C++ standard.The SGI implementation differers from VC's implementation.  I figured this out the hard way.  So yes, it probably will be an issue if you're looking for portability.Just be careful with hash_maps, you can lose alot of performance if you have alot of matching keys.   ;Quote:Original post by JohnBSmallQuote:Original post by George2As far as I know, hash_map is part of the STL. Just look at SGI's STL documentation (clicky).If you actually read the definition part of that page, you'll see:Quote:DefinitionDefined in the header hash_map, and in the backward-compatibility header hash_map.h. This class is an SGI extension; it is not part of the C++ standard.[emphasis mine]John BIt seems I overlooked that ...   ;  What exactly is the difference between hash_map and a standard map?   ;  hash_maps don't keep their elements in order like maps do and instead of finding elements using the < operator, it uses the == operator. It's also supposed to be faster when used correctly.EDIT: Wah! Almost forget, thanks for all the replies.EDIT(again): I forgot that hash_maps also store data differently than maps. According to my book elements are assigned to places and that it will rarely end up assigning elements to a place where an element is already stored because of probability or something. Because of this, hash_maps are resized when they're at around 75% full so elements will stop being assigned to the same places by chance (when this occurs it's less efficient), and resizing is also costly. Hmm... I hope I didn't butcher the explanation too much. You should probably google hash_map to get a more coherent definition :]   ;  Maps use a binary tree (typically a red-black tree) whereas hash maps use a hash table.   ;  or you could make your own hash function, whatever you think is good enough and use a hash function along with a std::map<int, /*your data type here*/> type. You can hash up a string yourself and store the key inside a map. It will be way faster then storing strings inside a map, and it would be fully compatible.Dont think it will as fast as a hash_map though. but pretty fast  isuppose.   