As of 4.3, gcc/g++ has many deprecated inclusions that should be phased out
As we compile ember pretty much exclusively using g++ we will need to stop using the deprecated entities/includes. I have included the small snip of the backward_warning.h file which documents the specific changes required. Some of these will be trivial, but some ( like auto_ptr ) are riddled throughout the code. We will need to make sure that these structures will serve as drop in replacements.
A list of valid replacements is as follows:
Use: Instead of:
<sstream>, basic_stringbuf <strstream>, strstreambuf
<sstream>, basic_istringstream <strstream>, istrstream
<sstream>, basic_ostringstream <strstream>, ostrstream
<sstream>, basic_stringstream <strstream>, strstream
<unordered_set>, unordered_set <ext/hash_set>, hash_set
<unordered_set>, unordered_multiset <ext/hash_set>, hash_multiset
<unordered_map>, unordered_map <ext/hash_set>, hash_map
<unordered_map>, unordered_multimap <ext/hash_set>, hash_multimap
<functional>, bind <functional>, binder1st
<functional>, bind <functional>, binder2nd
<functional>, bind <functional>, bind1st
<functional>, bind <functional>, bind2nd
<memory>, unique_ptr <memory>, auto_ptr
How backwards compatible are these new symbol names? While most linux and *BSD distros use rather recent versions of gcc, the win32 version still uses version 3.4. Though hopefully mingw will be able to provide more recent gcc version soon.
Some of these names, such as unique_ptr seems to be classes that are completely new in gcc 4.3 and not present in earlier versions. I don't think we can deprecate gcc v4.2- until most distros have moved on.
The deprecation warnings only warns about upcoming deprecation, so it should be safe to use these symbols for at least some years.