Re: [boost] [optional] optional(Expr&&) is insufficiently constrained
2016-02-18 23:03 GMT+01:00 Stephan T. Lavavej
Hi,
A user reported a bug (VSO#191303/Connect#2351203, see [1]) using Boost.Optional with MSVC 2015 Update 2. The original test case involved a minor bug in VC's tuple, which I'll look into fixing in the future (specifically, N-tuples recursively construct (N - 1)-tuples, in a way that's visible to overload resolution). However, there is also a bug in boost::optional.
Hi, I have created a ticket abut this problem: https://svn.boost.org/trac/boost/ticket/12002 Frankly, I do not know how to implement it in a portable way (considering older compilers) without type trait boost::is_constructible. I am currently blocked on it: https://svn.boost.org/trac/boost/ticket/12003. As an aside, the "prevent_binding" stuff should probably be expressed as a
SFINAE constraint, not a static_assert.
About this remark, I am not sure. I understand that you want the constructors to be SFINAE-friendly, but at the same time I would loose the opportunity to convey a text message to the user-programmers, as to what the problem is. Now I do it with the static_assert. I wish I had the feature "delete for a reason" Optional::Optional(R&&r) = delete("because it would cause..."); Regards, &rzej
On Thursday, February 18, 2016 at 6:19:54 PM UTC-6, Andrzej Krzemienski wrote:
2016-02-18 23:03 GMT+01:00 Stephan T. Lavavej
javascript:>: Hi,
A user reported a bug (VSO#191303/Connect#2351203, see [1]) using Boost.Optional with MSVC 2015 Update 2. The original test case involved a minor bug in VC's tuple, which I'll look into fixing in the future (specifically, N-tuples recursively construct (N - 1)-tuples, in a way that's visible to overload resolution). However, there is also a bug in boost::optional.
Hi, I have created a ticket abut this problem: https://svn.boost.org/trac/boost/ticket/12002 Frankly, I do not know how to implement it in a portable way (considering older compilers) without type trait boost::is_constructible. I am currently blocked on it: https://svn.boost.org/trac/boost/ticket/12003.
As an aside, the "prevent_binding" stuff should probably be expressed as a
SFINAE constraint, not a static_assert.
About this remark, I am not sure. I understand that you want the constructors to be SFINAE-friendly, but at the same time I would loose the opportunity to convey a text message to the user-programmers, as to what the problem is. Now I do it with the static_assert.
You can add a message to the end of boolean clause in `enable_if` in C++11,
like this:
template
optional(T&&); So when the compiler notes that the constructor was disabled by `enable_if`, it will point to the boolean clause which contains your message. At least on clang, it shows a preview of the line where the diagnostic occured, so the message is shown as well. I don't how other compilers work. One issue with this approach is that it requires a fairly compliant C++11 compiler(allowing literal strings in template parameters). Gcc 4.9 or earlier does not support this. Clang does. I don't about other compilers.
I wish I had the feature "delete for a reason"
Optional::Optional(R&&r) = delete("because it would cause...");
Well there is no need for another new feature, just better diagnostics from current compilers. Paul
[Andrzej Krzemienski]
I have created a ticket abut this problem: https://svn.boost.org/trac/boost/ticket/12002
Thanks!
Frankly, I do not know how to implement it in a portable way (considering older compilers) without type trait boost::is_constructible. I am currently blocked on it: https://svn.boost.org/trac/boost/ticket/12003.
The simplest solution would be to add the additional constraint when Boost.Config tells you that a modern is_constructible is available. (Older toolsets will lack the intense metaprogramming that makes this constraint necessary in the first place.) STL
2016-02-19 2:54 GMT+01:00 Stephan T. Lavavej
[Andrzej Krzemienski]
I have created a ticket abut this problem: https://svn.boost.org/trac/boost/ticket/12002
Thanks!
Frankly, I do not know how to implement it in a portable way (considering older compilers) without type trait boost::is_constructible. I am currently blocked on it: https://svn.boost.org/trac/boost/ticket/12003.
The simplest solution would be to add the additional constraint when Boost.Config tells you that a modern is_constructible is available. (Older toolsets will lack the intense metaprogramming that makes this constraint necessary in the first place.)
I have implemented a temporary patch: the constructor is SFINAE-friendly, but only on the latest compilers (MSVC 12.0). It is available for tests in the develop branch. Regards, &rzej
[Andrzej Krzemienski]
I have implemented a temporary patch: the constructor is SFINAE-friendly, but only on the latest compilers (MSVC 12.0). It is available for tests in the develop branch.
Thanks, that should be sufficient. Even restricting it to VC 14.0 would be OK. STL
Andrzej Krzemienski wrote
I have implemented a temporary patch: the constructor is SFINAE-friendly, but only on the latest compilers (MSVC 12.0). It is available for tests in the develop branch.
Works for me for me with the reduced test cases as well as with the original production code that triggered the issue (I was the original reporter of the problem after updating MSVC14 to Update 2 CTP.) Thank you! Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/optional-optional-Expr-is-insufficiently-... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (4)
-
Andrzej Krzemienski
-
Marcel Raad
-
Paul Fultz II
-
Stephan T. Lavavej