Boost logo

Boost :

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.


> 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at