Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-05 11:52:04


Oleg Abrosimov wrote:
> Alexander Nasonov:
>
> in the "Lexical Conversion Library Proposal for TR2" (N1973) proposal
> Kevlin Henney and Beman Dawes states:
>
> "Since either the source or target are usually strings, why not provide
> separate to_string(x) and string_to<t>(x) functions?
>
> The source or target isn't always a string. Furthermore, the from/to
> idea cannot be expressed in a simple and consistent form. The illusion
> is that they are easier than lexical_cast because of the name. This is
> theory. The practice is that the two forms, although similarly and
> symmetrically named, are not at all similar in use: one requires
> explicit provision of a template parameter and the other not. This is a
> simple usability pitfall that is guaranteed to catch experienced and
> inexperienced users alike -- the only difference being that the
> experienced user will know what to do with the error message."
>
>
> for me it is reasonable enough to require a symmetric usage of
> from_string/string_from functions I've proposed.

Well, I can buy into the idea that the target is always a 'string'. And
frankly I've never used any other sort of target/source for these kinds
of conversion. But your're still not responding to the core of my
question. The problem is "what's a string"? Some possibilities:

std::wstring
std::string
std::basic_string<uchar> //some sort of unicode string
std::vector<char> //and variants thereof
sti::rope
jeffs_really_cool_string_class // ;-)

I think even if the plan is to limit to 'a string' you will need to
support these sort of options. Which means you need a second templat
argument.

Which probably means you need to clearly define the concept of a string
w.r.t these conversions. And perhaps that's how it differentiates from
lexical_cast. That is lexical_cast
requires Target == InputStreamable, DefaultConstructable and Source ==
OutputStreamable. What are your concept requirements?

Jeff


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