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