the Boost policy for protecting against "too perfect forwarding"
Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-construc... In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy. There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads. (1) appears cleaner, but some compilers might not support SFINAE. My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE. I can see Boost.Any just uses SFINAE for this purpose without any check. Are there any compilers supported by Boost that have rvalue references but no SFINAE? Regards, &rzej
On Friday 25 April 2014 16:48:03 Andrzej Krzemienski wrote:
Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-construc to/
In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy.
There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads.
(1) appears cleaner, but some compilers might not support SFINAE.
My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE.
I can see Boost.Any just uses SFINAE for this purpose without any check.
Are there any compilers supported by Boost that have rvalue references but no SFINAE?
I think you can safely rely on SFINAE with any recent compiler. BOOST_NO_SFINAE was used with ancient compilers and there even was initiative of removing it, if I'm not mistaken.
On 25 April 2014 09:48, Andrzej Krzemienski
There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads.
3. Pass by value 4. Use a tag for the first parameter in the constructor (There are probably more...) (1) appears cleaner, but some compilers might not support SFINAE.
AFAIK, the set of compilers that support C++11 but do not support SFINAE is empty. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404
participants (3)
-
Andrey Semashev -
Andrzej Krzemienski -
Nevin Liber