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: 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;
>>> #  if IM_FINE_WITH_MACROS
>>> #    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?

Sebastian