
On Apr 10, 2013, at 2:09 PM, Vicente J. Botet Escriba
Le 10/04/13 19:39, Nathan Crookston a écrit :
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. 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.
I think that I need to re-read the result_of documentation to understand correctly what is proposed.
I had thought of this proposal as a third configuration. So, our established migration path from using TR1 by default to using decltype by default would remain, but we would add a third option: a hybrid that could switch between TR1 mode and decltype mode smartly. - Daniel