Boost logo

Boost :

Subject: Re: [boost] [lexical_cast] A suggestion
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-08 17:28:36

on Sun Feb 08 2009, wrote:

>> 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."
> Dave, I am not sure what you see wrong with lexical_cast interface. Could
> you elaborate? I am not using lexical_cast (due to throw, no default value
> and the def.ctor requirement). So, I still keep using the analog I wrote a
> while back and well before I ever heard of lexical_cast. Even though I
> wrote it independently, the interface happened to be very close:
> namespace aux
> {
> namespace string
> {
> template<class Type> std::string from (Type const&);
> template<class Type, class String> bool is (String const&)
> throw();
> template<class Type, class String> Type to (String
> const&);
> template<class Type, class String> Type to (String const&,
> Type const&);
> }
> }

I rather like it.

> That is,
> string str = aux::string::from(-1);
> int i1 = aux::string::to<int>(str); // throw
> int i2 = aux::string::to<int>(str, -1); // no throw
> As you can see it is pretty close to lexical_cast.

Yeah, well it doesn't ever make you type "<string>." But also, it isn't
trying to be lexical_cast. lexical_cast takes one type's lexical
representation and tries to interpret that as another type. That's a
very odd kind of semantics that just happens to line up with something
very useful when one of the types is a string. I've never heard of
anyone using lexical_cast when one of the types was something else.
Have you?

>> ...
>> I just don't think lexical_cast is the interface we need for most
>> convenient string conversions.
> It might be the case. However, I do not see any other practical
> suggestions that we could act on. Therefore, in the end we end up with
> nothing at all... again. That's been dragging for far too long.

Let's start with something like your interface. Propose a utility
library. Jeff Garland had a really nice set of proposed extensions to
std::string that could live in the same space.

>> 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.
> I am not that concerned about the internal design

I said "interface," not "implementation."

> as it can be worked on
> and improved without rush behind the interface. If it is the interface
> that is the issue, then let's look at it. Any suggestions? So far, I do
> not see people arguing against that proposed "extension" offering anything
> practical in return. That is not constructive as people end up with
> nothing at all.
> I am not counting the <optional> suggestion as it seems as an overkill

I think that's kinda twisted. lexical_cast is already _huge_ compared
to optional, since it drags in iostreams. Optional is a very basic

> and it still has the default-constructability requirement.

Actually it doesn't. optional<T> is always default constructible as
empty, and even if T isn't default constructible you could always define

  istream& operator>>(istream&, optional<T>&)

for some particular T.

Have you proposed some way to do away with default constructibility

Dave Abrahams
BoostPro Computing

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