[config] gcc-4.4 and BOOST_NO_SFINAE_EXPR
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions. Can we get BOOST_NO_SFINAE_EXPR defined for it? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ? Regards, Michel
On 9/22/2012 6:26 PM, Michel Morin wrote:
Eric Niebler wrote:
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
I choose not to fight that battle. :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
I choose not to fight that battle. :-)
Sounds fair to me :-) Do you want to make the change? John.
On 9/23/2012 1:50 AM, John Maddock wrote:
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
I choose not to fight that battle. :-)
Sounds fair to me :-)
Do you want to make the change?
Done. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 09/23/2012 03:26 AM, Michel Morin wrote:
Eric Niebler wrote:
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
Shouldn't whether this macro is defined or not depend on whether the associated test fails or succeeds, rather than what the compiler claims to support? If the test is not strict enough, it could be modified.
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
Shouldn't whether this macro is defined or not depend on whether the associated test fails or succeeds, rather than what the compiler claims to support?
Ideally, yes that should always be the case. It's always a bit tricky knowing where to draw the line when the feature works "most of the time" but fails in tricky cases.
If the test is not strict enough, it could be modified.
Patches welcome. Also, if the test does actually pass for compiler X but we define the defect macro anyway because enough real world cases fail, then there should be a comment in the config file for that compiler stating why the macro is set. Otherwise some helpful person will likely unset the macro in future ;-) John.
On 9/24/2012 8:33 AM, John Maddock wrote:
As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions.
Then, wouldn't it be nice to ask gcc developers to change the availability of "Solving the SFINAE problem for expressions" from gcc 4.4 to gcc 4.5 in http://gcc.gnu.org/projects/cxx0x.html ?
Shouldn't whether this macro is defined or not depend on whether the associated test fails or succeeds, rather than what the compiler claims to support?
Ideally, yes that should always be the case. It's always a bit tricky knowing where to draw the line when the feature works "most of the time" but fails in tricky cases.
If the test is not strict enough, it could be modified.
Patches welcome.
Also, if the test does actually pass for compiler X but we define the defect macro anyway because enough real world cases fail, then there should be a comment in the config file for that compiler stating why the macro is set. Otherwise some helpful person will likely unset the macro in future ;-)
I confess to not understanding how the config tests work. When I run "bjam toolset=gcc-4.4 config_test" in libs/config/tests, the tests pass whether or not BOOST_NO_SFINAE_EXPR is defined for gcc-4.4. I'm clearly doing something wrong. Anyway, here is a test for sfinae-expr that fails with gcc-4.4: template<typename T> T declval(); struct not_incrementable {}; struct inc { template<typename T> auto operator()(T t) const -> decltype(t++) { return t++; } }; template<typename T> struct wrap {}; template<typename A> int try_inc(wrap<decltype(declval<inc>()(declval<A>()))> *) { return 0; } template<typename A> not_incrementable try_inc(...) { return not_incrementable(); } struct X {}; int main() { int x = try_inc<int>(0); // OK not_incrementable y = try_inc<X>(0); // OK, not_incrementable } -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 09/24/2012 08:15 PM, Eric Niebler wrote:
I confess to not understanding how the config tests work. When I run "bjam toolset=gcc-4.4 config_test" in libs/config/tests, the tests pass whether or not S_NO_SFINAE_EXPR is defined for gcc-4.4. I'm clearly doing something wrong.
Looks like the test is not good enough then. (I was the one who wrote that particular test, but I don't quite understand the Boost.Config testing mechanism either)
Anyway, here is a test for sfinae-expr that fails with gcc-4.4:
template<typename T> T declval();
struct not_incrementable {};
struct inc { template<typename T> auto operator()(T t) const -> decltype(t++) { return t++; } };
template<typename T> struct wrap {};
template<typename A> int try_inc(wrap<decltype(declval<inc>()(declval<A>()))> *) { return 0; }
template<typename A> not_incrementable try_inc(...) { return not_incrementable(); }
struct X {};
int main() { int x = try_inc<int>(0); // OK not_incrementable y = try_inc<X>(0); // OK, not_incrementable }
SFINAE for expressions also works in C++03, so it would be better if you could have a C++03 testcase.
I confess to not understanding how the config tests work. When I run "bjam toolset=gcc-4.4 config_test" in libs/config/tests, the tests pass whether or not S_NO_SFINAE_EXPR is defined for gcc-4.4. I'm clearly doing something wrong.
Looks like the test is not good enough then. (I was the one who wrote that particular test, but I don't quite understand the Boost.Config testing mechanism either)
Sigh... it's very imperfect: * By default the only tests that are run check that config_test.cpp compiles, which means either: the macro is set or the code compiles and runs. * There are tests that check the reverse (ie which will fail if a macro is set when it should not be), but they are not run by default because they aren't 100% reliable - in large part because we don't have a suitable Boost.Build testing rule. John.
participants (4)
-
Eric Niebler -
John Maddock -
Mathias Gaunard -
Michel Morin