
Hi Vicente, Vicente J. Botet Escriba wrote:
Le 10/04/13 19:12, Nathan Crookston a écrit :
I think individual boost libraries shouldn't need to worry about the
macros. Users may need to explicitly define one of the macros if they develop on a compiler which supports decltype-based result_of, but wish to support compilers without decltype.
In short, I think that (with the decltype fallback) result_of *will* choose the best implementation, and (if the patch is applied) defining a macro to explicitly select a back end should be done for cross-platform compatibility reasons.
If you are right and after the patch result_of would provide the best we can do now, why the user would need to define any of these macros?
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. Thanks, Nate