Revision 129442 http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00547.html moved a few header files from include/ext to include/backward, which introduced a new libstdc++ API. If a C++ applications want to support both 4.2 and 4.3 APIs, it needs a way to tell different APIs, something like #if GLIBCXX_API == 43 #include <ext/hash_set> #else #include <backward/hash_set> #endif
I believe we should add those deleted ext/xxx header files with #warning __FILE__ is deprecated .... #include <backward/xxx> if we want to move ext/xxx to backward/xxx. It is never a good idea to break the existing C++ applications for no very good reasons.
Any news on this issue?
Hasn't the comment from hjl@lucon.org been implemented? AFAIK <ext/hash_set> works in 4.3 and generates the deprecation warning.
I reported the bug below to Debian. I'm not that familiar with those headers, but I think it'd be a good idea to not deprecate them until the replacements have been available for quite a while. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455199 Package: g++-4.3 Version: 4.3-20071130-1 Severity: normal Hi, <ext/hash_set> is deprecated in 4.3, but it's replacement, <unordered_set> doesn't appeart to be available in 4.2. Using <unordered_set> doesn't sound like a good plan (at the moment), so wouldn't it make sense to postpone the deprecation until it's replacement has been available for some time? The extreme would be to wait until 4.3 is in oldstable. Greetings, Olaf
(In reply to comment #4) > <ext/hash_set> is deprecated in 4.3, but it's replacement, <unordered_set> > doesn't appeart to be available in 4.2. Just use <tr1/unordered_set>
HJ: this and 33831 are the same thing. I would appreciate it if you could either clarify why you think they are separate, or close one of them. I suggest closing 33832. This PR I will treat as "How HJ can fix eon in SPEC 2000". I suspect this is what motivated this bug report. Here's the bit from SPEC, courtesy of Vlad. /home/cygnus/vmakarov/perf/sbox/gcc/local.spec2000.x86_64/inst.toolbox/bin/g++ -c -o ggCoverageSolidTexture.o -DHAS_ERRLIST -DSPEC_STDCPP -DFMAX_IS_DOUBLE -DUSE_STRERROR -Wno-deprecated -DSPEC_CPU2000_LP64 -fpermissive -I. -DNDEBUG -O2 -mtune=generic ggCoverageSolidTexture.cc Ie: 1) -Wno-deprecated 2) -fpermissive Fixing -Wno-deprecated would have been/is still easy. change #include <iostream.h> to # include <iostream> using namespace std; Yay! Safe for the millennium. I don't know what it would take to fix -fpermissive. You can find more information about this, and an autoconf macro that tests for this, here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html Look for "Pre-ISO headers moved to backwards or removed" best, benjamin
This one is for "moved" header files. One can include different header files for gcc 4.3. PR 33831 is for "removed" header files. I don't know if gcc 4.3 provides the identical functionality as the old one. One may needs more than including different header files for gcc 4.3. BTW, not all applications use autoconf.
Changed the tile to something unique.
HJ: "I don't know if gcc 4.3 provides the identical functionality as the old one." We've all answered this multiple times by now. Quick answer: yes. See #5. -benjamin
> Just use <tr1/unordered_set> It'd be nice if the deprecated warning mentioned that file.
I'd like to close this (since ext/hash_map and ext/hash_set exist now, and merge the bits about better error messages into 34015.
I declare this fixed.