Re: [boost] [rfc] constrained_value (Was: constrained_value.hpp)

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2007-11-12 20:29:58

> From: Jeff Garland
> Robert Kawulak wrote:
> >> constraints can all be inline and fixed at compile time.  I'd 
> >> rather have 2 
> >> types if need be to allow maximum efficiency for the static cases.
> > 
> > I wouldn't consider this a great issue. My experiments with 
> compilation to
> > assembly code show that compilers are able to optimise-away 
> all (or at least
> > much of) the abstraction easily (e.g. see
> > http://article.gmane.org/gmane.comp.lib.boost.devel/164478).
> 
> Hmm, I'm dubious that this testcase is representative.  
> Because you have a 
> fixed const there is apparently no checking 
> required...unlikely to work in 
> most cases.  Also, you still have the function call 
> overhead...so I'm still 
> leary that instead of 2 compares you get 2 compares plus the 
> overhead in your 
> example.

I'm not sure I understand - why you think there's a function call and 2
comparisons in that example? The function's code simply returns the literal
value of 5 and that's it.

Anyway, I've tried with more representative example - the value is not known at
compile time:

        extern int i;

        void test()
        {
                bounded_int<int, 3, 5>::type b(i);
        }

With #define NDEBUG and -O2 switch, gcc 4.0.1 gave the following code:

        __Z4testv:
        [...] irrelevant stack-manipulation code
                movl	_i, %eax
                movl	%eax, -32(%ebp)
                cmpl	$2, %eax		<== lower bound
                jle	L8
                cmpl	$5, %eax		<== upper bound
                jle	L46
        L8:
        [...] irrelevant error-handling code
        L46:
        [...] irrelevant stack-manipulation code
                ret

With the same options, Borland C++ 5.6.4 gave:

        @@test$qv	proc	near
        [...] lots of seemingly irrelevant code
                mov eax,3		<== lower bound
        [...]
                cmp eax,edx
                setg al
                and eax,1
                test al,al
                jne       short @19
                mov eax,5		<== upper bound
                cmp edx,eax
                setg cl
                and ecx,1
                test cl,cl
                je        @17
        @19:
        [...] irrelevant error-handling code
        @17:
        [...]
                ret 
        @@test$qv	endp

In both cases the compilers were able to optimise-away the abstraction of bounds
generators, using the literal values of bounds in the comparisons. I'm not sure
this is what you were worrying about, but if so, then I think there's no problem
at all. ;-)

Best regards,
Robert