$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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