Re: [boost] [lexical_cast] A suggestion

Subject: Re: [boost] [lexical_cast] A suggestion
From: Vladimir.Batov_at_[hidden]
Date: 2009-02-08 18:03:58

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

Yes, I readily admit that the idea indeed looked very odd when I looked at 
the implementation... then I thought that smarter-than-me people looked 
into it and gave their approval. Still, you are right mentioning that I 
never had any inclanation to use lexical_cast<> beyond to/from-string 
conversions. 

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

OK, I'll investigate.

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

I am not sure I can agree it is twisted. From the user point of view 
lexical_cast is very straightforward. By throwing <optional> into the mix 
you immediately increase overall complexity and the entry level. 

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

At the moment I cannot have another look at optional. When I looked at it 
before, I saw it needed/expected T::T() somewhere to compile. I'll try it 
again when I get a chance. 

> Have you proposed some way to do away with default constructibility
> somehow?

Foo default_foo;
Foo foo = lexical_cast(str, default_foo);

(or whatever instead of lexical_cast) has no Foo::Foo() requirement.

Best,
V.