Subject: Re: [boost] [result_of] Allow result_of to work with C++11 lambdas
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-10 14:09:55
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*
>>> 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.
Thanks for your clarifications,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk