Re: [boost] [math-toolkit] Expected release?

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2007-10-18 08:45:13

"John Maddock" <john_at_[hidden]> wrote in message 
news:001701c81183$1fd50020$a4f86d51_at_fuji...
> Gennadiy Rozental wrote:
>> Hi, John
>>
>> Can you please take a look on failures today. I've enabled additional
>> error detection within Boost.Test with floating point operations on
>> WIN32 platform. Does theses look valid to you?
>
> Ahhhh! No, there are quite a lot of tests that are expected to return
> infinity, or underflow to zero.  Enabling floating point hardware 
> exceptions
> will break those: the tests are predicated on 
> numeric_limits<>::has_infinity
> etc, but not on the *runtime* value of the hardware exception flags.  I
> assume you're calling __control87 somewhere to turn these exceptions on?

switch_fp_exceptions( bool on_off )
{
    if( !on_off )
        _clearfp();

    int cw = ::_controlfp( 0, 0 );

    int exceptions_mask = 
_EM_INVALID|_EM_DENORMAL|_EM_ZERODIVIDE|_EM_OVERFLOW|_EM_UNDERFLOW;

    if( on_off )
        cw &= ~exceptions_mask; // Set the exception masks on, turn 
exceptions off
    else
        cw |= exceptions_mask;  // Set the exception masks off, turn 
exceptions on

    if( on_off )
        _clearfp();

    // Set the control word
    ::_controlfp( cw, _MCW_EM );
}

> My gut feeling is that this is the wrong moment to introduce a breaking
> change like this, especially as you're changing the compiler's default
> behaviour.  Given enough time it's work-aroundable, but it's time I'd 
> rather
> not spend just at present, and besides I would expect this to break
> libraries like random and interval as well.  If you want to make this an
> option for Boost.Test that's fine, it's making this the default in the run
> up to a release that I'm not happy with.

Ok. How about if I make this optional and disabled by default for now. But 
make it enabled by default after 1.35?

Gennadiy