Boost logo

Boost :

From: Dave Dribin (dave-ml_at_[hidden])
Date: 2005-05-27 14:57:23


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.
>
> However, the example above doesn't seem to be quite the killer example
> given that 0 is readily identifiable as an inappropriate port number.
> Yes, it's a convenience, but the convert_to (or perhaps convert_else)
> syntax is simpler than using either (2) or (3).

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.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk