4 ms·

What about a preprocessor check based on the __cplusplus value? If it's 199711L, implement the C++03 defines, if not, implement the C++11 defines.

gurkendoktor 11y ago
A quick Google search suggests that this won't work unless you also check for the MSVC version - sigh: http://stackoverflow.com/questions/14131454/visual-studio-2012-cplusplus-and-c-11 http://stackoverflow.com/questions/14131454/visual-studio-20...
- StephanTLavavej 11y ago
  If we changed __cplusplus before implementing every single C++11 feature, the Internet would riot.
  - lmm 11y ago
    If you're exposing __cplusplus=199711L then you really ought to continue to support #include <tr1/memory> (i.e. C++03 style). As long as you do that there's no problem and the suggested thing should work.
    - plorkyeran 11y ago
      VC++ never used <tr1/memory> in the first place. That was purely a libstdc++ thing, and not something that TR1 or any C++ standard ever said to do.
      - StephanTLavavej 11y ago
        Yep. (TR1 was published after C++03, they're totally different things.) What we did with TR1 was actually very friendly to migration - we provided std::tr1::meow in <meow> (in 2008 SP1), then in 2010 we aliased that to std::meow as C++0x was being finalized, then in 2012 we switched the True Name to std::meow and made std::tr1::meow the alias for back-compat. At some point in the future we'll probably remove the tr1 aliases completely. For the Technical Specifications, we're following their header directory and namespace rules (<experimental/meow>).
ridiculous_fish 11y ago
Unfortunately this doesn't handle the libc++ case, which needs #include <memory> even in C++03. What I ended up doing is something like this: // Ensure that _LIBCPP_VERSION is defined if necessary #include <ciso646> #if defined(_LIBCPP_VERSION) || __cplusplus > 199711L // C++11 or libc++ #include <memory> using std::shared_ptr; #else // C++03 or libstdc++ #include <tr1/memory> using std::tr1::shared_ptr; #endif

gurkendoktor 11y ago

A quick Google search suggests that this won't work unless you also check for the MSVC version - sigh: http://stackoverflow.com/questions/14131454/visual-studio-2012-cplusplus-and-c-11 http://stackoverflow.com/questions/14131454/visual-studio-20...

StephanTLavavej 11y ago
If we changed __cplusplus before implementing every single C++11 feature, the Internet would riot.
- lmm 11y ago
  If you're exposing __cplusplus=199711L then you really ought to continue to support #include <tr1/memory> (i.e. C++03 style). As long as you do that there's no problem and the suggested thing should work.
  - plorkyeran 11y ago
    VC++ never used <tr1/memory> in the first place. That was purely a libstdc++ thing, and not something that TR1 or any C++ standard ever said to do.
    - StephanTLavavej 11y ago
      Yep. (TR1 was published after C++03, they're totally different things.) What we did with TR1 was actually very friendly to migration - we provided std::tr1::meow in <meow> (in 2008 SP1), then in 2010 we aliased that to std::meow as C++0x was being finalized, then in 2012 we switched the True Name to std::meow and made std::tr1::meow the alias for back-compat. At some point in the future we'll probably remove the tr1 aliases completely. For the Technical Specifications, we're following their header directory and namespace rules (<experimental/meow>).

ridiculous_fish 11y ago

Unfortunately this doesn't handle the libc++ case, which needs #include <memory> even in C++03. What I ended up doing is something like this: // Ensure that _LIBCPP_VERSION is defined if necessary #include <ciso646> #if defined(_LIBCPP_VERSION) || __cplusplus > 199711L // C++11 or libc++ #include <memory> using std::shared_ptr; #else // C++03 or libstdc++ #include <tr1/memory> using std::tr1::shared_ptr; #endif