I`ll try to answer all the questions one by one. 2011/9/30 Mathias Gaunard <mathias.gaunard@ens-lyon.org>:

Fast implementations of these things are already available from Spirit, do you plan on reusing them?

Spirit implementation does not conform to the standard, because it does not use std::locale. Some conversion implementations already exist in lexical_cast library, and it is as fast as spirit for most cases. 2011/9/30 Olaf van der Spek <ml@vdspek.org>:

Are stoi, stoll etc standard names?

Yes, they have the signatures: int stoi(const string& str, size_t *idx = 0, int base = 10); long stol(const string& str, size_t *idx = 0, int base = 10); unsigned long stoul(const string& str, size_t *idx = 0, int base = 10); long long stoll(const string& str, size_t *idx = 0, int base = 10); unsigned long long stoull(const string& str, size_t *idx = 0, int base = 10); float stof(const string& str, size_t *idx = 0); double stod(const string& str, size_t *idx = 0); long double stold(const string& str, size_t *idx = 0); And also have overloads for wstring type. No overloads for char16_t and char32_t, but they must be there (may be they will be added in next standard, after the C++0x) 2011/9/30 Vicente Botet <vicente.botet@wanadoo.fr>:

I would add them the Boost Numeric Conversion library as these functions take in account only numeric types or Create a new Boost.String.NumericConversion library.

I also prefer idea of a separate library. 2011/9/30 Stewart, Robert <Robert.Stewart@sig.com>:

I think it is reasonable to capture to_string() as a standard, extrinsic function template that returns a std::string from T. Each T must supply a specialization that does the right thing, of course, and there would be implementations for built-in types. This means the mechanism is extensible to UDTs. Obviously, to_string<T>(T const &) isn't flexible. It just provides a quick-and-dirty conversion.

to_string functions are in standard, and have the following signature: string to_string(int val); string to_string(unsigned val); string to_string(long val); string to_string(unsigned long val); string to_string(long long val); string to_string(unsigned long long val); string to_string(float val); string to_string(double val); string to_string(long double val); There are also to_wstring functions with the same signature. But no functions to_u16string and to_u32string

stoi(), stoll(), stof(), stod() seem less useful, though providing a portable C++03 implementation wouldn't be bad. I don't know how those functions in C++11 compare to functions like strtod(), but that one in particular is painful to use correctly because of the error semantics. I generally wrap such functions behind a function template interface to simplify usage, select the right function for the type being converted, and throw exceptions or return bool on failure.

I also dislike the error semantics of strtod. New stoi like functions throw exceptions instead, but these functions are not really good documented in standard, and can be implemented in multiple ways. I bet there will be some troubles with them because of different implementations on different platforms. 2011/9/30 John Bytheway <jbytheway+boost@gmail.com>:

to_string is defined in terms of sprintf [1], which depends on the locale (at least for the decimal point character [2], possibly for other things), so I doubt that the Spirit implementations would be correct (at least, not if used naively). I think lexical_cast would also not be correct, since it has a different locale-dependence from sprintf.

Spirit implementations would not be correct. lexical_cast implementation match more, but still some work required. Best regards, Antony Polukhin

2011/10/1 Mathias Gaunard <mathias.gaunard@ens-lyon.org>:

On 09/30/2011 08:29 PM, Antony Polukhin wrote:

...

Some conversion implementations already exist in lexical_cast library, and it is as fast as spirit for most cases.

Not really.

As for dependence to a locale, that's a shame. Yet another slow string/number conversion facility, as if there weren't enough already.

Consider the performance section of lexical_cast library documentation (trunk/libs/conversion/doc/lexical_cast.qbk). Latest version (the one, that is in the trunk) of Boost.Lexical_cast outperforms pure C functions, however still uses std::locale. Best regards, Antony Polukhin

2011/10/13 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:

Hi,

have you had time to work on the to_string standard function?

I have. The main problem here, that there is no compiler that supports char16_t, char32_t and std::locale for them. There is no printf like functions for char16_t, char32_t. So I can not test to_u16string and to_u32string functions and can not implement some conversions. Until there is no full char16_t, char32_t support I`ll make some patches to Boost.Lexical_cast that will be required in to_string functions and implement to_string, stoX and to_wstring functions. When there will be some more work done, I`ll commit the sources to sandbox or to git and post a link here. Best regards, Antony Polukhin

2011/10/13 Vicente Botet <vicente.botet@wanadoo.fr>:

In particular I want to use them in Boost.Chrono. Of course, in the mean time I'm using lexical_cast. Have you already a clear idea of the namespace of these functions? boost? boost::string_conversions?

Have no idea about the namespace name. I`ll think about it later. Function overloads for boost::containers::basic_string will be in namespace boost::containers (to allow ADL), and will be imported in the namespace of the to_string library.

IMO, I would prefer just boost, as these are standard functions.

Some of the boost users write "using namespace boost; using namespace std;" in their projects, so I think it would be better to place thous functions in a separate namespace to avoid ambiguity. Best regards, Antony Polukhin

On Fri, Sep 30, 2011 at 6:54 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:

I think it is reasonable to capture to_string() as a standard, extrinsic function template that returns a std::string from T.  Each T must supply a specialization that does the right thing, of course,

I was expecting it to be a wrapper around lexical_cast.

stoi(), stoll(), stof(), stod() seem less useful, though providing a portable C++03 implementation wouldn't be bad.

Don't those functions require std::string as input? I'd be nice to have generic variants. Olaf

On Sep 30, 2011, at 10:13 AM, Olaf van der Spek wrote:

On Fri, Sep 30, 2011 at 6:54 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:

...

I think it is reasonable to capture to_string() as a standard, extrinsic function template that returns a std::string from T. Each T must supply a specialization that does the right thing, of course,

I was expecting it to be a wrapper around lexical_cast.

...

stoi(), stoll(), stof(), stod() seem less useful, though providing a portable C++03 implementation wouldn't be bad.

Don't those functions require std::string as input? I'd be nice to have generic variants.

I wouldn't use any of these. The functions I wrote for this purpose take either a const char*, or a const char** if you want the iterator advanced. For int-to-string, you pass begin and end pointers, and the digits are written from right to left, padding with zeroes or truncating the numeral as necessary. A function taking just the int and returning a string is a trivial wrapper around this one. Josh