2015-01-21 16:41 GMT+01:00 Peter Dimov :

Andrzej Krzemienski wrote:

...

A number of tests of Boost.Optional fail. (see here: http://www.boost.org/development/tests/develop/developer/optional.html) These are the failures in optional (optional references), because quite a lot of compilers implement reference binding in a non-standard-conforming manner. (For details of these bugs see here: http://www.boost.org/doc/libs/develop/libs/optional/doc/ html/boost_optional/dependencies_and_portability/ optional_reference_binding.html ).

On the doc page, you state that these bugs are present in all MSVC versions, but on the tests page, I only see one failure, with msvc-10.0, everything else is green (or, in some cases, missing.)

You are right. I need to check if I didn't loose some tests. But back to my original request, did what I say makes sense?

2015-01-21 21:56 GMT+01:00 Peter Dimov :

Andrzej Krzemienski wrote:

...

2015-01-21 16:41 GMT+01:00 Peter Dimov :

...

On the doc page, you state that these bugs are present in all MSVC > versions, but on the tests page, I only see one failure, with msvc-10.0, > everything else is green (or, in some cases, missing.)

You are right. I need to check if I didn't loose some tests. But back to my original request, did what I say makes sense?

I'd like to know more about what is failing where before I venture an opinion about your original request.

An optional that fails silently for certain T's in a quite insidious way on a wide array of popular compilers, including all versions of MSVC, should perhaps be disabled for those T's outright, instead of the failures being marked. Users do not consult the markup when using optional<> and even if they did, optional is most likely to occur in generic code, not on its own. This will result in some very hard to track bugs.

Are you saying that on a compiler where an operation on optional might give wrong run-time result, the operation should be disabled (render a compile-time error)? If so, I agree, and intend to do it at some point. But even then I should indicate somehow in regression tests that I expect different results in gcc and in msvc. Regards, &rzej

2015-01-21 22:14 GMT+01:00 Andrey Semashev :

On Thu, Jan 22, 2015 at 12:10 AM, Andrzej Krzemienski wrote:

...

2015-01-21 21:56 GMT+01:00 Peter Dimov :

...

An optional that fails silently for certain T's in a quite insidious way on a wide array of popular compilers, including all versions of

MSVC,

...

should perhaps be disabled for those T's outright, instead of the failures being marked. Users do not consult the markup when using optional<> and even if they did, optional is most likely to occur in generic code, not on its own. This will result in some very hard to track bugs.

Are you saying that on a compiler where an operation on optional might give wrong run-time result, the operation should be disabled (render a compile-time error)? If so, I agree, and intend to do it at some point. But even then I should indicate somehow in regression tests that I expect different results in gcc and in msvc.

What kind of errors are we talking about? Does optional behave plain wrong on MSVC or is there a misbehavior in some narrow case? Does it compile invalid code, does it not compile valid one, or is there a miscompilation?

In most of the cases the program compiles but we have a run-time misbehavior: we store a reference to an unexpected temporary rather than to the original object.

Andrzej Krzemienski wrote:

Are you saying that on a compiler where an operation on optional might give wrong run-time result, the operation should be disabled (render a compile-time error)?

I think that am I saying that if an operation on optional is apt to result in dangling pointers on many popular compilers, the operation should be disabled for all compilers for consistency, not just those that will exhibit the failure. This interface is obviously too dangerous to be of any use and, while it will work on some compilers, its use will not be portable. However, if you're able to reliably detect this case under C++11 using rvalue references, it might make sense to leave optional available there, with just the int&& overload disabled. The answer to the question of whether and how to mark the failures will obviously depend on the road taken. If optional is just disabled across the board, it's easy, just make the test compile-fail. If it's available somewhere but not everywhere, well, things will be trickier. A third option, besides using explicit markup and configuration checks, is to just #ifdef the whole test to int main() {} when it doesn't apply (that is, would have been marked out.) It's a bit of cheating, but it works well in practice since you can #ifdef on the exact compiler versions, in addition to Boost.Config macros. And if you want to check explicitly for compile-fail on some compilers, you can add a separate compile-fail test that is #ifdef-ed out to #error on the compilers to which it does not apply.

Andrey Semashev-2 wrote

On Thu, Jan 22, 2015 at 12:27 AM, Peter Dimov <

lists@

> wrote:

...

Andrzej Krzemienski wrote:

...

Are you saying that on a compiler where an operation on optional<T&> might give wrong run-time result, the operation should be disabled (render a compile-time error)?

I think that am I saying that if an operation on optional<T&> is apt to result in dangling pointers on many popular compilers, the operation should be disabled for all compilers for consistency, not just those that will exhibit the failure. This interface is obviously too dangerous to be of any use and, while it will work on some compilers, its use will not be portable.

It's also possible to make the feature optional, so that it can be enabled by a macro.

On a recent project I did come across this with optional references: we decided to do exactly that: disabled them with optional macro to re-enable them. Mind that optional references are easily replaceable by raw pointers -> yield almost the same syntax as optionals and are plain simple. -- View this message in context: http://boost.2283326.n4.nabble.com/config-regression-Regression-test-failure... Sent from the Boost - Dev mailing list archive at Nabble.com.