Boost logo

Boost :

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 13:27:48

Le 10/04/13 19:12, Nathan Crookston a écrit :
> Hi Vicente,
> Vicente J. Botet Escriba wrote:
>> 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.
> If I'm understanding correctly, you're suggesting that compatibility
> problems are the reason result_of doesn't use the decltype-based
> implementation. If so, I don't think it's quite true. The reason why
> decltype isn't used for more compilers is that deduction fails in some
> cases where incomplete types are involved[1]. This isn't so much a
> backwards-compatibility issue since we'd like result_of to work in such
> cases, even today.
> 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.
> Thanks,
> Nate
> [1] -- very
> instructive discussion
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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at