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: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2008-12-01 12:55:00

On Mon, Dec 1, 2008 at 11:45 AM, Sebastian Redl
<sebastian.redl_at_[hidden]> wrote:
> 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?

Quite true.  But the code above is user-supplied, so the user can
write their code so that such collisions do not occur, if they need
identical behavior to int in NDEBUG mode, or the library author could
change the spelling of value() to be something less likely to cause
problems, or both.

Zach