$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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 12:26:35
Le 10/04/13 18:16, Nathan Crookston a écrit :
> Hi Vicente,
>
> Vicente J. Botet Escriba wrote:
>
>> Le 09/04/13 07:50, Nathan Crookston a écrit :
>>
>> Jeff Hellrung suggested[1] a fallback to decltype *only* for compilers
>>> which had nonconforming decltype operators. Thus the only behavioral
>>> change would be that some code which before would produce an error would
>>> now compile and run correctly.
>>>
>>>
>> Hi,
>>
>> how a Boost library as Boost.Thread could use the new boost::result_of?
>> Should it provide different implementations depending on whether
>> BOOST_RESULT_OF_USE_DECLTYPE, BOOST_RESULT_OF_USE_TR1, or
>> BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK are defined?
>>
> I'm not sure I understand what you mean. Which piece of boost thread would
> need to provide different implementations depending on the macro defined?
> I don't think users usually care about which version of result_of is
> actually selected -- unless deduction doesn't work, which is the case for
> C++11 lambdas currently. Do you have an example where the user would need
> to write their code differently depending on the chosen result_of
> implementation? I can only think of times where a user may wish to
> explicitly select one type.
>
>
The problem is that result_of for compatibility problems is not able to
choose the version of result_of that works the better. So the user needs
to define one of these macros to select the best adapted to his needs.
But a Boost library needs to be portable and needs a result_of that
works the best depending on the compiler and the context used. Maybe we
need another result_of that has no backward compatibility issues.
Please let me know if I'm not enough clear or even wrong.
Best,
Vicente