Boost logo

Boost :

Subject: Re: [boost] [lexical_cast] A suggestion
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-08 16:20:23

David Abrahams wrote:
> on Sun Feb 08 2009, Ben Muzal <> 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."

I disagree. lexical_cast was designed to be simple to use, and I think
it does it very well. The "to-string" and "from-string" conversions, in
their simple form, are just corner cases. If I want to simply parse an
int, I don't want to make up a Spirit grammar for that or even use
scanf. I need a C++-style of strtol, which is safe in terms of buffer
allocation and types. This is what lexical_cast tries to achieve and it
does, to some degree. I don't know of any other tools that come this
close to this goal, neither in Boost, nor outside of it.

>> 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've already expressed myself on this. I just want to add that optional
does define its streaming operators, and the way they work is no
compatible with the goal we're trying to achieve with this extension.

>> 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.

Do you have a better interface in mind?

>> 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.

The point is, often I don't care if the default was actually read from
the string or taken from the argument. And I don't want to care (which
would be necessary if optional was used).
If I care whether the string was actually read, I use the throwing
version of lexical_cast.

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