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, Vladimir.Batov-AT-wrsa.com.au 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
component.

> 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
somehow?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk