Re: [boost] Checking interest in to_string functions

Subject: Re: [boost] Checking interest in to_string functions
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2011-09-30 14:29:55

I`ll try to answer all the questions one by one.

2011/9/30 Mathias Gaunard <mathias.gaunard_at_[hidden]>:
> 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_at_[hidden]>:
> 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_at_[hidden]>:
> 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_at_[hidden]>:
> 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_at_[hidden]>:
> 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