Re: [boost] [constrained_value] ignore_policy, overhead?

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2008-05-07 17:01:55

> From: Neal Becker
> 
> I'm wondering if I can selectively switch off bounds checking without
> overhead?

In theory, for such simple cases like ints and compile-time bounds, yes. In
practice, of course, it depends on optimisation capabilities of compiler and
compilation options used.

> I added:
> /**
>     Error policy for constrained that ignores bounds.
> */
> struct ignore
> {
[snip documentation comments]
>     template <typename V, class L, class U, class C>
>     void operator () (V & ov, const V & nv, const within_bounds <
>         L, value_generator::integral<bool, true>,
>         U, value_generator::integral<bool, true>,
>         C> & c) const
>     {
>     }
> 
> };
> 
> I'm wondering if the this will eliminate all overhead 
> allowing the speed of
> the underlying ValueType (e.g., int)?

In case of such policy the check would still be performed - if the value is
valid, it is assigned, and if it's not, then the operation is ignored. What you
really want is to assign the value no matter if it's valid or not, so the error
policy should be:

        struct no_error_policy {
            template <typename V, class C>
            void operator () (V & old_val, const V & new_val, C &)
            {
                old_val = new_val;
            }
        };

Note, that this policy is quite unnatural and breaks the constrained class'
invariant when invalid value is assigned. In debug code the constrained class
will fire an assertion, but in release code no action will be performed (i.e.,
the invalid value will be assigned as any other).

In this case there is a chance that a good compiler figures out how to optimise
this. I've checked this with GCC 3.4.5. I've written the following code:

        int main(int argc, char * argv[])
        {
            bounded_int<int, -10, 10, true, true, no_error_policy>::type b;
            b = argc;
            return b;
        }

After compiling it with "-S -O3 -DNDEBUG" (using current library's code, which
differs slightly from the older code available for download), the main function
looked like this:

        _main:
                [snip irrelevant stack manipulation etc.]
                movl	8(%ebp), %eax
                leave
                ret

Which means that for this simple case there is no difference between constrained
and int. It doesn't mean, however, that the compiler will figure optimisation
opportunities in more complex cases (actually it didn't for e.g. initialisation
of b with argc).

BTW, currently I'm working on examples section of the documentation and
performing some code tuning, so there is a chance that the library will be
_finally_ submitted for a review. ;-)

Best regards,
Robert