In message <b80ef8127943216dce23846c4d491ff4@dribin.org>, Dave Dribin <dave-ml@dribin.org> 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: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________