Boost logo

Boost :

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

        [...] 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
        [...] irrelevant error-handling code
        [...] irrelevant stack-manipulation code

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
        [...] irrelevant error-handling code
        @@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,

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