RE: [boost] Proposal: string_cast

From: Bjorn.Karlsson_at_[hidden]
Date: 2002-04-05 04:21:51

> From: Jeff Garland [mailto:jeff_at_[hidden]]
> > although the archive seems to handle some threads 
> incorrectly, i read
> > through the mentioned messages and there are several 
> requests for this
> > simple change and there are no serious concerns. the only 
> question is
> > whether to make it a new function to_string or to specialize
> > lexical_cast for std::string.
> 
> I think you're right.  And I think things seemed to be 
> leaning towards to_string.  I happen to
> prefer it -- it is used extensively in GDTL.

One obvious advantage of to_string is that it is non-intrusive to
lexical_cast, however, most people also seemed to agree that it would be a
shame to leave lexical_cast as is, with awkward (erroneous?) behavior that
makes it unusable in some situations. Personally I'm very much in favor of
alternatives that add expressive power and code clarity, so my vote would
definitely go to fixing lexical_cast *and* providing to_string.

[Jan Langer] 
> > so why isn't it done?
> >
> > is there more need for discussion or is there no one who 
> wants to do the
> > actual work? or does it need a formal review ;-) ?

Well, this is not the only issue, and it's not as trivial as it would seem.
Solving the std::string problem would be easy with partial specialization,
but that would effectively cut off quite a few current and potential
lexical_cast users. I've started working on a traits solution that would
allow for extension (for example, when using a custom allocator for
basic_string, or proprietary string classes), and doesn't need partial
specialization (it also incorporates solutions to the other issues). I'm
currently swamped, but if there's interest I'll upload it in a week or two,
maybe giving the discussions something more concrete to revolve around. 

Although the other issues that have been discussed don't necessarily have
impact on this change (but to some extent, they do), it would be convenient
to bundle some (or all) of them together. From the top of my head, here are
some other opportunities for improvement that we have been discussing:

* A non-throwing version of lexical_cast (lexical_conversion)
* Correct stream precision depending on floating point type (currently
default, which is 6)
* to_string convenience function
* to_wstring convenience function
* Support for wide strings and streams
* Automatic detection of base (just read a note with an easy cure - nice!)

Bjorn Karlsson