request: BOOST_NO_SFINAE_EXPR macro
It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html GCC supports this feature since 4.4 both for C++03 and C++0x for example.
On Thu, Jul 30, 2009 at 10:20 AM, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:
It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html
GCC supports this feature since 4.4 both for C++03 and C++0x for example.
Yes, such a macro is needed Also, it turns out that the ability to provide a default template parameter for function templates markedly clarifies code using enable_if. (I learned this Howard Hinnant, but I think he may have gotten the idea from Peter Dimov.) Thus we need a BOOST_NO_DEFAULT_TEMPLATE_ARGUMENT_FOR_FUNCTION_TEMPLATE. Or maybe BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_PARAMETER. (or is the correct term "argument"? Need to look that up. I'm overloaded. If you'd like to submit a patch, that would be great. Thanks, --Beman
Beman Dawes wrote:
On Thu, Jul 30, 2009 at 10:20 AM, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:
It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html
GCC supports this feature since 4.4 both for C++03 and C++0x for example.
Yes, such a macro is needed
So we could do this instead of use mpl and? template <typename T1, typename T2> enable_if_c<is_a_A<T1>::value && is_a_B<T2>::value>::type foo();
Also, it turns out that the ability to provide a default template parameter for function templates markedly clarifies code using enable_if. (I learned this Howard Hinnant, but I think he may have gotten the idea from Peter Dimov.)
This sounds interesting. Can you explain how? Thanks, Luke
Simonson, Lucanus J wrote:
It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html
GCC supports this feature since 4.4 both for C++03 and C++0x for example. Yes, such a macro is needed
So we could do this instead of use mpl and?
template <typename T1, typename T2> enable_if_c<is_a_A<T1>::value && is_a_B<T2>::value>::type foo();
This doesn't require SFINAE extended to expressions. This already works fine.
Also, it turns out that the ability to provide a default template parameter for function templates markedly clarifies code using enable_if. (I learned this Howard Hinnant, but I think he may have gotten the idea from Peter Dimov.)
This sounds interesting. Can you explain how?
I assume he refers to template< typename T, typename Enable = typename boost::enable_if<...>::type
void foo(T);
On Fri, Jul 31, 2009 at 11:52 AM, Simonson, Lucanus J<lucanus.j.simonson@intel.com> wrote:
Beman Dawes wrote:
On Thu, Jul 30, 2009 at 10:20 AM, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:
It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html
GCC supports this feature since 4.4 both for C++03 and C++0x for example.
Yes, such a macro is needed
So we could do this instead of use mpl and?
template <typename T1, typename T2> enable_if_c<is_a_A<T1>::value && is_a_B<T2>::value>::type foo();
Also, it turns out that the ability to provide a default template parameter for function templates markedly clarifies code using enable_if. (I learned this Howard Hinnant, but I think he may have gotten the idea from Peter Dimov.)
This sounds interesting. Can you explain how?
The example from Howard is below. Note that the enable_if code is moved out of the function signature and into a default template parameter. --Beman #define requires(...) class = typename std::enable_if<(__VA_ARGS__)>::type template <class T> struct underlying { typedef typename remove_cv<typename remove_reference<T>::type>::type type; }; // forward with <type_traits> template <class T, class U, requires(!is_lvalue_reference<T> || is_lvalue_reference<T> && is_lvalue_reference<U>), requires(is_same<typename underlying<T>::type, typename underlying<U>::type>)> inline T&& forward(U&& t) { return static_cast<T&&>(t); }
Beman Dawes wrote:
I'm overloaded. If you'd like to submit a patch, that would be great.
I wouldn't mind contributing, but I don't have access to all compilers (17 I believe) to test which ones support or don't support the features (albeit I suppose that the automatic testing on the trunk would eventually give the answer). Is defining BOOST_NO_* in all compilers for which I don't know whether they support it good enough?
On Fri, Jul 31, 2009 at 11:59 AM, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:
Beman Dawes wrote:
I'm overloaded. If you'd like to submit a patch, that would be great.
I wouldn't mind contributing, but I don't have access to all compilers (17 I believe) to test which ones support or don't support the features (albeit I suppose that the automatic testing on the trunk would eventually give the answer).
Is defining BOOST_NO_* in all compilers for which I don't know whether they support it good enough?
Yes! I'd suggest you test with at least one compiler that supports the feature and one that doesn't. But in general just default to BOOST_NO_*. --Beman
Beman Dawes wrote:
Yes! I'd suggest you test with at least one compiler that supports the feature and one that doesn't. But in general just default to BOOST_NO_*.
Ok, here is the patch. I chose to name the macros BOOST_NO_SFINAE_EXPR as I initially suggested and BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_PARAMETER since the other suggested name was really too long. I also changed the GCC config header so that GCC 4.4 is not an unknown version anymore.
participants (3)
-
Beman Dawes -
Mathias Gaunard -
Simonson, Lucanus J