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] http://lists.boost.org/Archives/boost/2010/04/164714.php -- 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? Vicente