on Sun Feb 08 2009, Ben Muzal <bmuzal-AT-gmail.com> wrote:
In fact, if we put together all the badly needed functionality that overlaps with lexical_cast, and give it appropriate interfaces, I'm not entirely convinced that there would be much use for lexical_cast anymore.
Really what is with all of the "slippery slope" arguments?
That's not my concern. My concern is that I don't think lexical_cast is a particularly good interface for its main uses, which could be thought of as "to-string" and "from-string."
People are not asking for the kitchen sink. We just want a nothrow version of the cast and to do that, a default value is needed.
I wouldn't say that. boost::optional is another option. In fact, if boost::optional doesn't already provide the exact streaming operator you need, I'd be a little surprised. If it has no streaming operator, we could consider adding the needed one. If it has the wrong streaming operator, it would be pretty easy to invent template nothrow, such that you can write optional<Foo> = lexical_cast<nothrow<Foo> >( something )
I always use my own extension "lexical_cast_nothrow" operator anyway that just catches the exception and returns a supplied default value if necessary.
I think you can easily avoid that problem.
Lots of times there are cases when a default value simply will not be acceptable, but quite often one will. Why can't it be easy to support both models?
I just don't think lexical_cast is the interface we need for most convenient string conversions.
I had not even heard of the <optional> library until reading this thread. I might update my little boost extension after checking to see how <optional> affects performance and code bloat -- but really, <optional> looks rather more complicated than necessary.
It has exactly the right semantics, and it tells you more than the version with the default does. With the default, you can't tell whether there was any valid input there or not, because the value represented in the input could be the same as the default.
I heard once that google was experimented with the number of search results that it returned. If they returned 100 results instead of 10, the search took .4 seconds longer. They found that the extra delay reduced the number of searches by 20% within the experimental group.
The moral of the story: some times it is the little conveniences that count.
No doubt.
I think that supplying a 'nothrow' version of lexical_cast is one of those little conveniences that would definitely count.
Maybe so, but I don't think lexical_cast is all that well-designed for convenience to begin with, and tacking on little convenience features isn't likely to yield a very clean interface. -- Dave Abrahams BoostPro Computing http://www.boostpro.com