Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2008-12-01 12:45:02

Zach Laine wrote:
> On Mon, Dec 1, 2008 at 11:32 AM, Sebastian Redl
> <sebastian.redl_at_[hidden]> wrote:
>> Zach Laine wrote:
>>> The docs include some example code on "using constrained objects in
>>> debug mode only", and make reference to using unconstrained<> to allow
>>> use of the .value() member function. Why not replace the .value()
>>> member function with a free function
>>> boost::constrained_value::value(), and then write something like this?
>>> #ifndef NDEBUG
>>> typedef bounded_int<int, 0, 100>::type my_int;
>>> #else
>>> typedef int my_int;
>>> # define value(x) x
>>> # else
>>> inline int value(int x) { return x; }
>>> # endif
>>> #endif
>>> Then, as long as the user always writes "value(x)", letting ADL pick
>>> up the boost::constrained_value::value() free function, the
>>> macro/inline function above will silently kick in instead if defined.
>>> This gets rid of any requirements on the quality of the optimizer in
>>> order to get performance just like an int. Did you already try this
>>> and find it problematic?
>> Intuitively, I'd say this is problematic - the value(int) version wouldn't
>> get picked up by ADL.
> Why is ADL an issue when the parameter type is int? The value(int)
> overload is only declared when we don't care about ADL, since we're
> not using constrained_value types. Am I missing something?
The value overload for int would have to be in the global scope, or else
it won't be found and you'll get compile errors.

Defining a function called "value" in the global scope sounds like a big
no-no to me. Can you imagine a name more likely to collide with
something else?


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