I have been using ext::hash_map
in a C++ project and notice that in g++ 4.3 it is deprecated in favor of unordered_map
. I need to maintain compatibility with old systems that do not have unordered_map
available. It occurs to me that this is just the sort of thing that could be handled by autoconf, which I am already using. I have been unsuccessful in finding documentation on doing so, however.
I would guess that I need to do something like the following:
- Replace all instances of ext::hash_map
in my code with MY_HASH_MAP
- Replace all instances of ext/hash_map
in my code with MY_HASH_INCLUDE
- Include a line in configure.ac using some combination of AC_CHECK_HEADERS
and AC_DEFINE
I have not been able to figure out exactly the proper autoconf magic to make this work, and am wondering if it is even the best solution anyway. Surely this is the sort of thing that many other people will have dealt with and there might be some standard solution that I have been unable to find?
So, three related questions:
- Is there a standard way of handling this that I should be using?
- How do I do this in autoconf?
- Should I just use -Wno-deprecated and assume the C++ standard is not going to be updated within my lifetime?
-
I would consider leaving the code as is and turning off the 'deprecated' warning instead, especially if you have to support older systems where you only have ext::hash_map available.
IIRC ext::hash_map is not part of the standard anyway, so the main harm that could be done is that (eventually) the G++ maintainers will remove support for it. However if you rejig the code to include both hash_map and the tr1 unordered_map, you've suddenly doubled the testing effort for this particular bit of code. Unless there is a specific reason that might require you do duplicate the effort, save it for something more worthwhile.
-
You could use
AC_CHECK_HEADERS([my_header_file])
to see which files are present -- then create a newclass MyApp::hash_map
which depending on how what defines are used wraps the functionality accordingly.
0 comments:
Post a Comment