Boost logo

Boost :

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

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


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