is gcc going nuts?

June 24, 2008 at 8:24 pm | Posted in Uncategorized | 9 Comments

Note: I’m no gcc expert, nor am I C++ standards expert so please bear with me if this reads a little bit like a rant. I’m really just surprised ๐Ÿ™‚

So I’ve just built kdevelop and noticed an new warning:

/usr/include/c++/4.3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.

Ok, no problem, it even tells me where to look to fix it. Very nice. So I went to the file and saw that one is supposed to use “unordered_map” instead of ext/hash_map. So I changed the relevant files to do that and rebuilt (I’m now using gcc 4.3 as Debian decided to change that recently). Now I’m getting:

/usr/include/c++/4.3/c++0x_warning.h:36:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

And that leaves me pretty much stuck.

How come gcc developers deemed it a good idea to deprecate something and thus encourage users to change to non-deprecated code but at the same time mark this code as highly experimental and thus not ready for wide usage? That doesn’t look good, even if gcc won’t drop the header next week, at the point we’ll probably have to change a lot more code using it than we have now.

Ok, enough of that, I’ll revert my local changes and live happily with the warning, in the hope that I won’t be around when it gets dropped from gcc ๐Ÿ™‚


  1. #include tr1/unordered_map

    ciao robe

  2. Try including .
    It is likely the same as , but it is fetched from the technical report 1 of the c++ standard committee (intended as an “upgrade” to the current C++ standard). You probably want to wrap this inside a macro, since gcc <= 3.4 won’t provide this header (I think…).

  3. Whops… I meant to include the header “tr1/unordered_map” with angle brackets in place of quotation marks (I suppose the angle brackets were eaten as html tags?)

  4. If you use you won’t have those problems. You’re using which uses C++0x special features.

  5. Ooops, that was meant to say:

    If you use “tr1/unordered_map” you wonโ€™t have those problems. Youโ€™re using “unordered_map” which uses C++0x special features.

  6. Wow, that was a lot comments in so little time ๐Ÿ™‚

    Thanks for the hints to tr/unordered_map, but as I don’t want to actively break compilation with gcc 3.3 I’m not going to change that for now (and I can’t check wether it does have that class/header).

    I’ll keep this in mind though, in case we ever find enough reasons to drop gcc 3.x support in KDevelop.

  7. Here is the list of all those different headers:

    1) ext/hash_map is a non-standard g++ library extension (though other compilers will have separate extensions). It will likely cause problems on other compilers. (Hence stuff in it being in the _gnu_cxx namespace, and not std)

    2) unordered_map is a header from the upcoming new revision of C++. It will not work on older compilers, probably not even g++-4.2.x

    3) TR1 and tr1/unordered_map is a separate recent standard draft that provides a lot of new library features on top of existing C++-98. Again, compile support varies.

    My suggestion: stick to C++-98 and use an outside hash class, like QHash or something from boost.

  8. Thanks SadEagle for the extensive information. I’ll forward that to the relevant devs, so they can try boost’s hash class (QHash is apparently too slow).

  9. Well, IIRC current Boost libs do not support unordered_map in their TR1 implementation. I read in the mailing list that such support is planned for Boost 1.36, which should be out real soon ™. If you have tight time constraints, you can use the boost multiindex class with a single, hashed index. I’ve found it to perform more or less like ext/hash_map, tr1/unordered_map, etc.

Sorry, the comment form is closed at this time.

Blog at
Entries and comments feeds.

%d bloggers like this: