Hi Vicente, Vicente J. Botet Escriba wrote:
Le 10/04/13 19:39, Nathan Crookston a écrit : I think it would be uncommon for the user to define those macros. Here's a
situation where it may be useful:
I have a library which I claim supports VC9 and Clang. I do my development with clang 3.2, and rely on some form of automated testing to verify it works with MSVC. I may commonly forget to add result_type or a nested struct to my functors, since clang uses decltype. After the Nth time, I may, during my own development, #define BOOST_RESULT_OF_USE_TR1, just so that I'm not continually breaking the VC9 build.
So again, I think it's uncommon.
Do you mean that if a library author develops and tests with both compilers an even more at once he would need to define BOOST_RESULT_OF_USE_TR1 from the beginning even if defining BOOST_RESULT_OF_USE_DECTYPE works better on some compilers? But the library author cannot know how the users would define their Functors so it can not define these macros.
No, I don't mean that. I mean the library author may choose to do that during development, just to avoid writing code that can't be used with a less capable compiler. In my mind, it's like enabling certain warnings on MSVC so that my code is more likely portable to g++ later. I think most people should (and will) leave the macros alone, so the best variant is detected for their platform. Nate