Re: [boost] [review][constrained_value] ReviewofConstrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] ReviewofConstrained ValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-10 22:13:44

> From: Gordon Woodhull

> I've looked at the code now (it's very clear!), and I 
> understand what  
> the assertions do: they double-check that the error handler is  
> fulfilling the contract of not returning if the constraint fails.

Right.

> I think this is a valuable feature in debug mode but would 
> not be wanted
> 1) in performance critical apps (the extra test matters)

I thought in that case one would turn assertions off globally.

> 2) if we've established that there's no way a floating point 
> predicate  
> is always going to provide consistent results.  (I know 
> you're laying  
> your hopes on consistent truncation.)

Right, but I will try to elegantly solve it for this case too. ;-)

> Of course, if you allow the asserts to be disabled by macro 
> or policy,  
> then you're also allowing the monitored values use case.  I 
> understand  
> that you don't want to support this (certainly the nomenclature is  
> wrong), but it would be nice if you would allow people to experiment.

Got it.

> BTW, I find the ignore example confusing because it's 
> checking whether  
> the old value still satisfies the constraint.  (Doesn't it know this  
> by now?)  To be honest, I had to compile it and say "huh?" to figure  
> this out.

The explanation in the tutorial covers this, is it not clear enough and should
be improved?

>  This results in three invocations of the predicate on a  
> successful assign.

Yes, one of them being the assertion. The policy in the example is protective
and tries to prevent construction of invalid object even in non-debug mode. It
could be empty and then this situation would be handled by the assertion,
leaving only one predicate call in release mode.

Best regards,
Robert