Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at