Re: [boost] Re: lexical_cast with default value

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2005-05-29 02:39:05

In message <b80ef8127943216dce23846c4d491ff4_at_[hidden]>, Dave Dribin 
<dave-ml_at_[hidden]> writes
>On May 12, 2005, at 9:05 AM, Kevlin Henney wrote:
>>> Personally, I think there is a need to to specify the default value, 
>>>rather than rely on the default constructed value.  For example:
>>>
>>>  int httpPort = convert_to<int>(aString, 80);
>>>
>>> Maybe that can be done in similar vain to (1) or (2):
>>>
>>>  int httpPort = lexical_cast<int>(default_value<int>(aString, 80));
>>>
>>> I don't know templates well enough to know if that's possible. Seems 
>>>like the implementation would need to convert 80 into a string, and 
>>>then back to an int, though, as  default_value would need to return a 
>>>string in the above example, right?
>>
>> I think that the optional approach (2) would be more appropriate if 
>>this proves to be a killer need. It is lighter in weight in terms of 
>>syntax and implementation, and is ultimately more general purpose.
[...]
>I think it's a killer need.  Yes, in the case above 0 is inappropriate, 
>but there could be cases when you'd rather use -1.  The point is each 
>application and situation is different.  There's not one single 
>inappropriate value for all types.  For strings, would you use the 
>empty string?  This is an issue with value semantics since NULL isn't 
>an option.  And even if there was a universally inappropriate value, 
>now my code is littered with:
>
>  if (var == INAPPROPRIATE_VALUE) {
>      var = DEFAULT_VALUE;
>  }
>
>instead of just supplying it in the lexical_cast<> itself (which is 
>already doing the checking).  This makes the code harder to read than 
>it needs to by, IMO.

Having given this some more thought, I am more convinced that to provide 
this functionality the suggestion of using optional is the better one. 
This makes clear in a declarative sense what is going on, but does not 
get drawn into what a suitable interpretation of non-conversion might be 
(assign a default, log an error, etc).

The next version of lexical_cast is due to be committed to CVS real-soon 
now. It fixes a couple of defects and improvements, but no new key 
functionality. If there is interest in supporting optionality as I've 
just described it, then the version after the next would be the earliest 
appropriate time to introduce it.

Kevlin
-- 
____________________________________________________________
   Kevlin Henney                   phone:  [phone]
   mailto:kevlin_at_[hidden]     mobile: [phone]
   http://www.curbralan.com        fax:    [phone]
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________