From: Dave Dribin (dave-ml_at_[hidden])
Date: 2005-05-09 15:50:01
On May 7, 2005, at 3:50 AM, Kevlin Henney wrote:
> However, when I consider what the most common use of a defaulted value
> would likely be, based on my own experience of similar features, other
> library designs and indeed your example above, it appears that in the
> event of non-conversion the explicitly default constructed value of
> the target type is the most common use. Creating an interface for that
> would be somewhat easier.
> There are essentially three practical options for doing this, as I see
> it (a couple of others come to mind, but don't qualify as being in
> line with the existing design):
> (1) Provide a wrapper type for the source on which lexical_cast is
> overloaded and will handle non-conversion separately, eg
> lexical_cast<T>(defaulted(a)) or lexical_cast<T>(nonthrowing(a)).
> (2) Specify a target type that indicates a non-throwing outcome. The
> following suggestion has come to me from a colleague of Thomas Witt's:
> lexical_cast< optional<T> >(a).
> (3) Define another cast-like function that is specifically named, eg
> In terms of simplicity and directness my preference is for (3),
> although I am not wed to the name. I would be interested to hear any
> thoughts on this.
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk