Checking interest in to_string functions

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Checking interest in to_string functions

Antony Polukhin
As was mentioned in `[boost] to_string(v)`
1) Functions to_string and to_wstring are part of the upcoming C++0x
standard. However, there are no functions for char16_t and char32_t
conversions.
2) Some users can't use C++11 in some projects for quite some time,
but can use boost.
3) "to_string(5)" is a lot shorter than
"lexical_cast<std::string>(5)". Some users would like to use a shorter
form.

Is there interest in stoi, stoll, stof, to_string, to_wstring,
to_u16string, stod and other functions for char, wchar_t, char16_t and
char32_t conversions?
Shall I add them to lexical_cast library, or as a separate conversion library?

Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Mathias Gaunard-2
On 30/09/2011 06:20, Antony Polukhin wrote:

> As was mentioned in `[boost] to_string(v)`
> 1) Functions to_string and to_wstring are part of the upcoming C++0x
> standard. However, there are no functions for char16_t and char32_t
> conversions.
> 2) Some users can't use C++11 in some projects for quite some time,
> but can use boost.
> 3) "to_string(5)" is a lot shorter than
> "lexical_cast<std::string>(5)". Some users would like to use a shorter
> form.
>
> Is there interest in stoi, stoll, stof, to_string, to_wstring,
> to_u16string, stod and other functions for char, wchar_t, char16_t and
> char32_t conversions?
> Shall I add them to lexical_cast library, or as a separate conversion library?

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Olaf van der Spek-3
In reply to this post by Antony Polukhin
On Fri, Sep 30, 2011 at 6:20 AM, Antony Polukhin <[hidden email]> wrote:
> Is there interest in stoi, stoll, stof, to_string, to_wstring,
> to_u16string, stod and other functions for char, wchar_t, char16_t and
> char32_t conversions?
> Shall I add them to lexical_cast library, or as a separate conversion library?

I'd definitely like to see to_string and to_wstring. I use int to string a lot.
Are stoi, stoll etc standard names?
I was thinking of to_int instead of stoi. t_long_long is a bit long
compared to stoll though, but not unreasonable IMO.

Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Vicente Botet
In reply to this post by Antony Polukhin
Antony Polukhin wrote
As was mentioned in `[boost] to_string(v)`
1) Functions to_string and to_wstring are part of the upcoming C++0x
standard. However, there are no functions for char16_t and char32_t
conversions.
2) Some users can't use C++11 in some projects for quite some time,
but can use boost.
3) "to_string(5)" is a lot shorter than
"lexical_cast<std::string>(5)". Some users would like to use a shorter
form.

Is there interest in stoi, stoll, stof, to_string, to_wstring,
to_u16string, stod and other functions for char, wchar_t, char16_t and
char32_t conversions?
Sure. But I suspect that you couldn't use lexical_cast for this purpose. Whether you could Boost.Spirit for that or just sprintf, and the strtoxx family functions is up to you provided the implementation satisfy the C++11 standard requirements.

Shall I add them to lexical_cast library, or as a separate conversion library?
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.

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Stewart, Robert
In reply to this post by Antony Polukhin
Antony Polukhin wrote:

>
> As was mentioned in `[boost] to_string(v)`
> 1) Functions to_string and to_wstring are part of the upcoming
> C++0x standard. However, there are no functions for char16_t
> and char32_t conversions.
> 2) Some users can't use C++11 in some projects for quite some
> time, but can use boost.
> 3) "to_string(5)" is a lot shorter than
> "lexical_cast<std::string>(5)". Some users would like to use a
> shorter form.
>
> Is there interest in stoi, stoll, stof, to_string, to_wstring,
> to_u16string, stod and other functions for char, wchar_t,
> char16_t and char32_t conversions?
> Shall I add them to lexical_cast library, or as a separate
> conversion library?

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.

I have no idea whether to_wstring(), to_u16string(), etc. would be useful.  I've heard too many conflicting things about which string types work or don't for Unicode, etc., and have no firsthand experience.

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.

_____
Rob Stewart                           [hidden email]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com




________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Olaf van der Spek-3
On Fri, Sep 30, 2011 at 6:54 PM, Stewart, Robert <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Vicente Botet
Le 30/09/11 19:13, Olaf van der Spek a écrit :
> On Fri, Sep 30, 2011 at 6:54 PM, Stewart, Robert<[hidden email]>  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.
>
BTW, this recall me that during the Boost.Conversion review we stated
that we don't have a best way to convert builtin types to and from
strings. It seems that the people writing the standard have decided to
choose one of the possible conversions without too much trouble.

Best,
Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Josh Juran
In reply to this post by Olaf van der Spek-3
On Sep 30, 2011, at 10:13 AM, Olaf van der Spek wrote:

> On Fri, Sep 30, 2011 at 6:54 PM, Stewart, Robert  
> <[hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

John Bytheway-2
In reply to this post by Mathias Gaunard-2
On 30/09/11 09:35, Mathias Gaunard wrote:

> On 30/09/2011 06:20, Antony Polukhin wrote:
>> As was mentioned in `[boost] to_string(v)`
>> 1) Functions to_string and to_wstring are part of the upcoming C++0x
>> standard. However, there are no functions for char16_t and char32_t
>> conversions.
>> 2) Some users can't use C++11 in some projects for quite some time,
>> but can use boost.
>> 3) "to_string(5)" is a lot shorter than
>> "lexical_cast<std::string>(5)". Some users would like to use a shorter
>> form.
>>
>> Is there interest in stoi, stoll, stof, to_string, to_wstring,
>> to_u16string, stod and other functions for char, wchar_t, char16_t and
>> char32_t conversions?
>> Shall I add them to lexical_cast library, or as a separate conversion
>> library?
>
> Fast implementations of these things are already available from Spirit,
> do you plan on reusing them?

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.

[1] N3290 [string.conversions] p7
[2] N1570 7.1.1 p2

John Bytheway


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

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

2011/9/30 Mathias Gaunard <[hidden email]>:
> 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 <[hidden email]>:
> 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 <[hidden email]>:
> 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 <[hidden email]>:
> 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 <[hidden email]>:
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Mathias Gaunard-2
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Antony Polukhin
2011/10/1 Mathias Gaunard <[hidden email]>:

> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Vicente Botet
Hi,

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

Best,
Vicente
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Antony Polukhin
2011/10/13 Vicente J. Botet Escriba <[hidden email]>:
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Vicente Botet
Antony Polukhin wrote
2011/10/13 Vicente J. Botet Escriba <[hidden email]>:
> 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.
I think a lot of people will be more than happy to have char and wchar versions of these function.

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?

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

Thanks for your effort,
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: Checking interest in to_string functions

Antony Polukhin
2011/10/13 Vicente Botet <[hidden email]>:
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost