Re: [boost] [lexical_cast] A suggestion

Subject: Re: [boost] [lexical_cast] A suggestion
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-08 14:57:50

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