Boost logo

Boost :

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:
> }
>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 Henney                   phone:  +44 117 942 2990
   mailto:kevlin_at_[hidden]     mobile: +44 7801 073 508        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review

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