Re: [boost] [lexical_cast] A suggestion

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