Re: [boost] [review][constrained_value] Review ofConstrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review ofConstrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-09 19:28:35

> From: Gordon Woodhull

> My yes vote is still conditional on your cooperation with us on  
> letting floating points work, because the library would not 
> be useful  to me otherwise.

Technically, there's nothing in the code that would disallow the use of floats,
only that there is the warning in the docs. I have already stated (though maybe
not clearly enough, so I will try again now ;-), that I will explain possible
issues with floats and make the warning sound less categorical. Is this what you
expect?

>  I am now regretting that I didn't look at 
> the code,  
> because I didn't know that there were assertions testing the  
> invariants in a different way from the predicates.

The assertions test the invariant exactly the same way, they use the predicate.

>  Is this only in  
> the bounded part of the library?

No, the constrained class contains those assertions.

> I thought the value was tested after every change using the 
> predicate,  
> and then called the error policy if the predicate failed.  

Value should be changed _after_ calling the predicate to ensure strong excepiton
guarantee.

> Generally I don't think a library should assert on any user input -  
> even an invalid/inconsistent predicate!

If the user of a library breaks the contract, then why not? I'd rather prefer to
see a failed assertion to know as soon as possible that I accidentally used the
library in an inproper way.

>  I figured this was 
> the point  
> of having an error policy - everyone has their own idea how 
> they want  
> to handle errors.

Error policy and the assert are two different things. Error policy guarantees
the invariant, the assertion verifies it (and thus verifies the contract).
Assigning an invalid value is a different kind of error than breaking the
contract.

> Assertions are forbidden in a lot of corporate  environments.

Isn't it what BOOST_DISABLE_ASSERTS is for if you want to prevent a Boost
library from using asserts?

> I guess we have to wait for decltype to be able to use lambda  
> expressions as predicates here?

Why? There are already examples with lambda predicates in the docs.

Best regards,
Robert