Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-12-01 20:29:49

Zach Laine wrote:
> On Mon, Dec 1, 2008 at 11:57 AM, Sebastian Redl
> <sebastian.redl_at_[hidden]> wrote:
>> Zach Laine wrote:
>>> Quite true.  But the code above is user-supplied, so the user can
>>> write their code so that such collisions do not occur, if they need
>>> identical behavior to int in NDEBUG mode, or the library author could
>>> change the spelling of value() to be something less likely to cause
>>> problems, or both.
>>>
>> Yeah, that would be possible. But you know? I think I'll stick with
>> unconstrained. :-)
> 
> I agree.  In fact, I'd stick with the constrained versions.  But there
> are always some users who will want to throw a switch and get back to
> plain ints, so there is verifiably no performance penalty.  For those
> users, unconstrained might or might not cut it, depending on their
> compiler.
> 

In my experience working with a fixed-point class creating a class that 
has no performance penalty over built-in types is possible but requires 
extremely careful review of the generated code. In some cases the 
compiler will work fine on simple tests and punt in more complex code 
that you're likely to find in production code.

I could very much see users wanting to fallback on builtin types in 
performance critical code because verifying that there is no abstraction 
penalty is a lot of work.  but I suppose they could do this by adding a 
layer to facilitate that change on top of constrained.

-- 
Michael Marcin