Re: [boost] [config] [regression] Regression test failures due to compiler bugs -- your advice needed

Subject: Re: [boost] [config] [regression] Regression test failures due to compiler bugs -- your advice needed
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-21 16:27:20

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.

However, if you're able to reliably detect this case under C++11 using 
rvalue references, it might make sense to leave optional<int const&> 
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<int const&> 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.