[config] BOOST_NO_SFINAE_EXPR and GCC 4.6.4
According to this table http://gcc.gnu.org/projects/cxx0x.html, GCC supports "Solving the SFINAE problem for expressions" since 4.4. According to Boost.Config, it is since 4.5. The following test case works fine with 4.8.1, but fails miserably with 4.6.4: http://ideone.com/RzgXKM Errors include invalid conversion from X const* to X*, and use of non-member-ptr in member-ptr expression. GCC 4.7.3 (tested by zao at #boost) shows similar results: https://www.acc.umu.se/~zao/kbsfinae11.txt Should BOOST_NO_SFINAE_EXPR be adjusted according to the results of this test case? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 25/08/13 03:00, Agustín K-ballo Bergé wrote:
According to this table http://gcc.gnu.org/projects/cxx0x.html, GCC supports "Solving the SFINAE problem for expressions" since 4.4. According to Boost.Config, it is since 4.5. The following test case works fine with 4.8.1, but fails miserably with 4.6.4: http://ideone.com/RzgXKM Errors include invalid conversion from X const* to X*, and use of non-member-ptr in member-ptr expression. GCC 4.7.3 (tested by zao at #boost) shows similar results: https://www.acc.umu.se/~zao/kbsfinae11.txt
Should BOOST_NO_SFINAE_EXPR be adjusted according to the results of this test case?
I believe there were too many bugs with this feature with 4.4 to actually use it reliably. Restricting to 4.8.1 would certainly be a bit annoying, are the bugs that major?
On 25/08/2013 11:15 a.m., Mathias Gaunard wrote:
On 25/08/13 03:00, Agustín K-ballo Bergé wrote:
According to this table http://gcc.gnu.org/projects/cxx0x.html, GCC supports "Solving the SFINAE problem for expressions" since 4.4. According to Boost.Config, it is since 4.5. The following test case works fine with 4.8.1, but fails miserably with 4.6.4: http://ideone.com/RzgXKM Errors include invalid conversion from X const* to X*, and use of non-member-ptr in member-ptr expression. GCC 4.7.3 (tested by zao at #boost) shows similar results: https://www.acc.umu.se/~zao/kbsfinae11.txt
Should BOOST_NO_SFINAE_EXPR be adjusted according to the results of this test case?
I believe there were too many bugs with this feature with 4.4 to actually use it reliably.
That continues to be the case, albeit in more complex scenarios.
Restricting to 4.8.1 would certainly be a bit annoying, are the bugs that major?
I just tested with those versions I had access to, it might be working on an earlier version than 4.8.1. How would I determine the severity of the bugs? The feature is either broken or incomplete and there are no workarounds, so it sounds major to me. My use case is somewhat contrived, I give you that, but that doesn't negate the fact that there is no true SFINAE for expressions support. Maybe this grants having a BOOST_NO_*FULL*_SFINAE_EXPR config macro, drawing some arbitrary line on how much conformance is "enough" conformance. By the way, why is there no CXX11 prefix in that macro name? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Restricting to 4.8.1 would certainly be a bit annoying, are the bugs that major?
I don't believe so: remember that Boost.Config primarily exists to provide workarounds for what Boost libraries are actually doing. In that context I believe the macro to be set correctly - at least in the sense that library authors haven't been complaining that the current settup breaks their stuff.
How would I determine the severity of the bugs? The feature is either broken or incomplete and there are no workarounds, so it sounds major to me. My use case is somewhat contrived, I give you that, but that doesn't negate the fact that there is no true SFINAE for expressions support. Maybe this grants having a BOOST_NO_*FULL*_SFINAE_EXPR config macro, drawing some arbitrary line on how much conformance is "enough" conformance.
Ugh, please no. Is there a use case for this within Boost or is it an arbitrary test case? My gut feeling is that folks that need to do "complex" things can always use a BOOST_WORKAROUND instead? John.
On 25/08/2013 01:24 p.m., John Maddock wrote:
How would I determine the severity of the bugs? The feature is either broken or incomplete and there are no workarounds, so it sounds major to me. My use case is somewhat contrived, I give you that, but that doesn't negate the fact that there is no true SFINAE for expressions support. Maybe this grants having a BOOST_NO_*FULL*_SFINAE_EXPR config macro, drawing some arbitrary line on how much conformance is "enough" conformance.
Ugh, please no. Is there a use case for this within Boost or is it an arbitrary test case? My gut feeling is that folks that need to do "complex" things can always use a BOOST_WORKAROUND instead?
Arbitrary test case. Unless there is enough interest in finally having a `is_callable_with_args` kind of trait. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 25/08/13 18:14, Agustín K-ballo Bergé wrote:
I just tested with those versions I had access to, it might be working on an earlier version than 4.8.1.
Can you try to test with an arbitrary 4.6 or 4.7 at least?
By the way, why is there no CXX11 prefix in that macro name?
Because it's not C++11 specific. SFINAE on expressions is allowed in C++03 too. C++11 is just less vague on the subject.
On 25/08/2013 07:12 p.m., Mathias Gaunard wrote:
I just tested with those versions I had access to, it might be working on an earlier version than 4.8.1.
Can you try to test with an arbitrary 4.6 or 4.7 at least?
As I said in my original mail, the errors happen with both 4.6.4 and 4.7.3. Is that what you are asking for? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 26/08/2013 00:15, Agustín K-ballo Bergé wrote:
On 25/08/2013 07:12 p.m., Mathias Gaunard wrote:
I just tested with those versions I had access to, it might be working on an earlier version than 4.8.1.
Can you try to test with an arbitrary 4.6 or 4.7 at least?
As I said in my original mail, the errors happen with both 4.6.4 and 4.7.3. Is that what you are asking for?
I tested with 4.8.0, and your test passes.
participants (3)
-
Agustín K-ballo Bergé -
John Maddock -
Mathias Gaunard