Archived

This topic is now archived and is closed to further replies.

Ziphnor

Redhat8.0/g++ 3.2 hash_map woes!

Recommended Posts

Argghh, i make frequent use of the STL hash_map and curse the fact that it isnt part of the C++ standard... Anyway, in Win32 ive been using STLPort / SGI STL, and hash_maps like for example #include <hash_map> int main() { hash_map h; } First off, g++ complains about the above, saying it cant find the hash_map include file. So i looked it up, and its in /usr/include/c++/3.2/ext/, so i add that to the include path for g++, and it finds the file just fine. BUT now it complains that ''hash_map'' is undeclared.... What am i doing wrong here? Am i using the wrong header? If i use hash_map.h instead(old style) i get a warning about using oldstyle includes, but it compiles.[and i DONT want to change all my hash_map includes to hash_map.h for many reasons ] Any ideas?

Share this post


Link to post
Share on other sites
Ooops, but that was a mistake in what i posted here, not in the code i was actually trying to compile(dont know how i managed to screw up a copy-paste? , it was actually

      
#include <hash_map>

using namespace std;

int main()
{
hash_map<int,int> h;
return 0;
}


Anyway, im still getting the (same) error, any ideas?


[edited by - ziphnor on October 18, 2002 5:42:48 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
hash_map is an extension and as such is found in the ext/ directory. Therefore, you''ll have to include ext/hash_map. Also, note that the GNU libstdc++ is actually correct: given that hash_map isn''t standard, it doesn''t belong to the std namespace. You''ll find it in the __gnu_cxx namespace (since g++ 3.0 anyway).

Finally, the following will fail (at least it does on my systems) :


  

#include <ext/hash_map>

#include <string>


int main( ) {
__gnu_cxx::hash_map< std::string, std::string > hm;
}



You''ll have to specialize the hash for it to work with std::string, like this:


  

#include <ext/hash_map>

#include <string>

// ideally you''ll put this in another namespace as to not

// pollute __gnu_cxx, and provide it as a template

// parameter to hash_map.

namespace __gnu_cxx {
template<>
struct hash< std::string > {
size_t operator( )( std::string const & s ) const {
return __stl_hash_string( s.c_str( ) );
}
};
}


int main( ) {
__gnu_cxx::hash_map< std::string > hm;
}



Of course you could also use your own hashing function/functor.

Hope this helps.

Share this post


Link to post
Share on other sites
That does indeed explain whats been going on.
The old style, worked in Redhat 7.3, but that was gcc 2.95, RH 8 is 3.2.
Im not opposed to it being in /ext in any way, seems fair enough, but im not too happy about it, or the namespace, since im trying to write code that compiles on both linux and windows(VS.net)[using SDL+OpenGL].
The hashmap introduces plenty of problems there already as the VS.NET STL library(Dinkum or whatever its called) doesnt use the same syntax as STLPort/SGI.
But i thought i had solved this issue by using STLPort with VS.NET.

Now i have to include different files depending on the OS, not very neat. Maybe i should just write my own hashmap.....

But thanks a lot(!) for clearing this up for me.

Share this post


Link to post
Share on other sites