Hi, Ron, It is probably the namespace problem. You can check out http://gcc.gnu.org/onlinedocs/libstdc++/faq/#5_4 for compatibility fix. Wei On Tue, 12 Aug 2003, Ron Goodwyn wrote: > Greetings, > > I inherited some code that had last been tested using gcc-2.9.5.3. Now I > am attempting to cimpile it using 3.2.2-5 (the revision of the GNU tools > delivered with RedHat 9.0). Here is the code snippet that is having > problems: > > > 32 // hash function on strings > 33 struct str_hash { > 34 size_t operator()(const char* str) const { > 35 size_t hashval = 0; > 36 for ( ; *str; str++) > 37 hashval = 5*hashval + *str; // shift and add > 38 > 39 return hashval; > 40 } > 41 }; > 42 > 43 > 44 // equal_to function on strings > 45 struct str_equal { > 46 bool operator()(const char* s1, const char* s2) const { > 47 return (strcmp(s1, s2) == 0); > 48 } > 49 }; > 50 > 51 > 52 // convenience template for mapping between name and pointer > 53 template > 54 class DRTINameMap : public hash_map > 56 { > 57 public: > 58 DRTINameMap() : > 59 hash_map() {} > 60 DRTINameMap(const DRTINameMap& nmap) : hash_map(nmap) {} > }; > > Here are the compiler errors: > > In file included from DRTI.hh:12, > from RegionInfo.cc:1: > DRTI_Factories.hh:54: parse error before `<' token > DRTI_Factories.hh:59: parse error before `&' token > DRTI_Factories.hh:59: ISO C++ forbids declaration of `DRTINameMap' with no > type > DRTI_Factories.hh: In function `int DRTINameMap(...)': > DRTI_Factories.hh:59: `int DRTINameMap(...)' redeclared as different kind > of > symbol > DRTI_Factories.hh:54: previous declaration of `template > class DRTINameMap' > DRTI_Factories.hh:54: previous non-function declaration `template class DRTINameMap' > DRTI_Factories.hh:59: conflicts with function declaration `int > DRTINameMap(...) > ' > DRTI_Factories.hh:59: parse error before `<' token > DRTI_Factories.hh:59: only constructors take base initializers > DRTI_Factories.hh:59: confused by earlier errors, bailing out > make: *** [RegionInfo.lo] Error 1 > > > Does anybody have any idea as to what changed from gcc 2.9 to gcc 3.X that > could cause this behavior? Based on my research, similar problems seem to > arise when you forget to specify std:: however, hash_map is not standard, > it's an extension. I'm trying to determine whether the code needs to > change, or if there is some configuration or compiler problem here. > > Many thanks, > Ron Goodwyn > >