On 2014-05-13, at 6:45 AM, Jim Porter <jvp4846@g.rit.edu> wrote:

> I'm a bit less convinced of the use of converting std::wstring to std::string via std::to_string(), but that's more because I think wstring is a bit of a mess. Fixing that would probably be a long and difficult process, though.

As someone recently noted here, to_string doesn't respect localization. It's better suited to serialization than user or OS interfaces.

Although Unicode and UTF-8 are fairly ubiquitous regardless of locale, the specificity vs. genericity of wstring_convert is probably best.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_633_27322197.1399951478715
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, May 12, 2014 7:01:40 PM UTC-5, David Krauss wrote:
>
>
> On 2014=E2=80=9305=E2=80=9313, at 6:45 AM, Jim Porter <jvp...@g.rit.edu <=
javascript:>>=20
> wrote:=20
>
> > I'm a bit less convinced of the use of converting std::wstring to=20
> std::string via std::to_string(), but that's more because I think wstring=
=20
> is a bit of a mess. Fixing that would probably be a long and difficult=20
> process, though.=20
>
> As someone recently noted here, to_string doesn=E2=80=99t respect localiz=
ation.=20
> It=E2=80=99s better suited to serialization than user or OS interfaces.=
=20
>

Localization (e.g. the punctuation you'd use for a floating-point number)=
=20
is one thing; encoding is another. If it were up to me, std::basic_string=
=20
would be an array of code units (e.g. bytes), and there'd be an std::text=
=20
class that handles encodings and represents a sequence of code points.=20
That's certainly beyond the scope of something like this, so I wouldn't=20
argue too hard against an std::tostring(std::wstring) overload; it's just=
=20
not something I particularly care about.

One of these days, I really want to make a proof-of-concept that starts=20
over from scratch on I/O and character encodings for C++, although that=20
might never be standardizable due to the entrenchment of std::string and=20
I/O streams. I've been tinkering with a more printf-like way of formatting=
=20
output, but that's only a small part of the problem.

- Jim

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_633_27322197.1399951478715
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 12, 2014 7:01:40 PM UTC-5, David Krauss wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 2014=E2=80=9305=E2=80=9313, at 6:45 AM, Jim Porter &lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"5IxU9zPYcpIJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">jvp...@g.rit.edu</a>&gt; wrote:
<br>
<br>&gt; I'm a bit less convinced of the use of converting std::wstring to =
std::string via std::to_string(), but that's more because I think wstring i=
s a bit of a mess. Fixing that would probably be a long and difficult proce=
ss, though.
<br>
<br>As someone recently noted here, to_string doesn=E2=80=99t respect local=
ization. It=E2=80=99s better suited to serialization than user or OS interf=
aces.
<br></blockquote><div><br>Localization (e.g. the punctuation you'd use for =
a floating-point number) is one thing; encoding is another. If it were up t=
o me, std::basic_string would be an array of code units (e.g. bytes), and t=
here'd be an std::text class that handles encodings and represents a sequen=
ce of code points. That's certainly beyond the scope of something like this=
, so I wouldn't argue too hard against an std::tostring(std::wstring) overl=
oad; it's just not something I particularly care about.<br><br>One of these=
 days, I really want to make a proof-of-concept that starts over from scrat=
ch on I/O and character encodings for C++, although that might never be sta=
ndardizable due to the entrenchment of std::string and I/O streams. I've be=
en tinkering with a more printf-like way of formatting output, but that's o=
nly a small part of the problem.<br><br>- Jim<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_633_27322197.1399951478715--

.

Em seg 12 maio 2014, =E0s 20:24:38, Jim Porter escreveu:
> Localization (e.g. the punctuation you'd use for a floating-point number)=
=20
> is one thing; encoding is another. If it were up to me, std::basic_string=
=20
> would be an array of code units (e.g. bytes), and there'd be an std::text=
=20
> class that handles encodings and represents a sequence of code points.=20
> That's certainly beyond the scope of something like this, so I wouldn't=
=20
> argue too hard against an std::tostring(std::wstring) overload; it's just=
=20
> not something I particularly care about.
>=20
> One of these days, I really want to make a proof-of-concept that starts=
=20
> over from scratch on I/O and character encodings for C++, although that=
=20
> might never be standardizable due to the entrenchment of std::string and=
=20
> I/O streams. I've been tinkering with a more printf-like way of formattin=
g=20
> output, but that's only a small part of the problem.

You've described QByteArray and QString: one is an array of bytes, the othe=
r=20
contains human text, in a sequence of code points, and can transform them=
=20
according to the Unicode rules. There are two choices for storing text: eit=
her=20
keep the encoding along with the object or convert everything to a single,=
=20
known encoding. QString chooses the latter.

Anyway, I agree with you that std::string is pretty much entrenched as an=
=20
array of arbitrary bytes, of any encoding. Attempting to do text=20
transformations with it might lead to trouble, or at least poorly-written c=
ode=20
(like QByteArray's toLower function: it's documented to behave strangely fo=
r=20
non-ASCII bytes).

However, std::u16string, std::u32string and std::wstring aren't affected.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

2014-05-13 2:01 GMT+02:00 David Krauss <potswa@gmail.com>:
> On 2014-05-13, at 6:45 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
>
> As someone recently noted here, to_string doesn't respect localization. It's better suited to serialization than user or OS interfaces.
>

Unfortunately to_string still provides locale-dependency, albeit not
to grouping symbols, but is not guaranteed to be "pure". It still is
affected by locale effects that influence the decimal separator, for
example.

the to_(w)string functions were provided just as convenience functions
and were not intended to derive a family of ADL-lookup functions from
this.

If we want such a family I would strongly encourage to determine what
is the intend here:

a) Unchanged against any localization/global effects (except memory allocation)
->
This is some important property that I would like to see somewhere. We
cannot use to_string for this, because it doesn't hold for the
built-in types.

b) ?

Java's toString implementations of the "primitive" types and their
corresponding Object reference types guarantees (a), which I consider
as a very reasonable strategy.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2935_16534955.1399960261669
Content-Type: text/plain; charset=UTF-8

(Google Groups ate my draft, so I'll keep this one brief...)

On Monday, May 12, 2014 10:54:10 PM UTC-5, Thiago Macieira wrote:
>
> Anyway, I agree with you that std::string is pretty much entrenched as an
> array of arbitrary bytes, of any encoding. Attempting to do text
> transformations with it might lead to trouble, or at least poorly-written
> code
> (like QByteArray's toLower function: it's documented to behave strangely
> for
> non-ASCII bytes).
>
> However, std::u16string, std::u32string and std::wstring aren't affected.
>

I'd agree for std::u(16|32)string, but with std::wstring, you're not even
guaranteed a particular character width. While you might have some
reasonable expectations of the encoding for std::wstring on a given
platform, it's difficult to write cross-platform code with it unless you
rely on platform-specific code to pick the right encoding for each
platform. Especially given the lack of a defined encoding for std::string,
I'd be worried about converting a std::wstring to a std::string unless the
process was "ignore all non-ASCII characters".

That said, this is getting a bit off-topic from the original proposal,
which I think is overall a good idea. I'd just have to see what the spec is
for std::to_string(std::wstring). I doubt it would make things any worse
than they already are, though.

- Jim

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2935_16534955.1399960261669
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(Google Groups ate my draft, so I'll keep this one brief..=
..)<br><br>On Monday, May 12, 2014 10:54:10 PM UTC-5, Thiago Macieira wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">Anyway, I agree with you that =
std::string is pretty much entrenched as an=20
<br>array of arbitrary bytes, of any encoding. Attempting to do text=20
<br>transformations with it might lead to trouble, or at least poorly-writt=
en code=20
<br>(like QByteArray's toLower function: it's documented to behave strangel=
y for=20
<br>non-ASCII bytes).
<br>
<br>However, std::u16string, std::u32string and std::wstring aren't affecte=
d.
<br></blockquote><div><br>I'd agree for std::u(16|32)string, but with std::=
wstring, you're not even guaranteed a particular character width. While you=
 might have some reasonable expectations of the encoding for std::wstring o=
n a given platform, it's difficult to write cross-platform code with it unl=
ess you rely on platform-specific code to pick the right encoding for each =
platform. Especially given the lack of a defined encoding for std::string, =
I'd be worried about converting a std::wstring to a std::string unless the =
process was "ignore all non-ASCII characters".<br><br>That said, this is ge=
tting a bit off-topic from the original proposal, which I think is overall =
a good idea. I'd just have to see what the spec is for std::to_string(std::=
wstring). I doubt it would make things any worse than they already are, tho=
ugh.<br><br>- Jim<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2935_16534955.1399960261669--

.

Em seg 12 maio 2014, =E0s 22:51:01, Jim Porter escreveu:
> I'd agree for std::u(16|32)string, but with std::wstring, you're not even
> guaranteed a particular character width. While you might have some
> reasonable expectations of the encoding for std::wstring on a given
> platform, it's difficult to write cross-platform code with it unless you
> rely on platform-specific code to pick the right encoding for each
> platform. Especially given the lack of a defined encoding for std::string=
,
> I'd be worried about converting a std::wstring to a std::string unless th=
e
> process was "ignore all non-ASCII characters".

Any conversion to std::string must have possible failure modes. Whether tha=
t's=20
an exception, a return value or silent replacement with U+FFFD, it's someth=
ing=20
to be decided later.

Technically speaking, the wide character execution charset is also left to =
the=20
implementation, which means std::wstring could have any encoding too. So,=
=20
strictly speaking, conversion to std::wstring should also be allowed to fai=
l.

Then again, converting from std::u16string or std::u32string can also fail =
if=20
they contain bad data (improperly paired surrogate codepoints for UTF-16, n=
on-
Unicode entries in std::u32string) and conversion to them can also fail if =
the=20
source is improperly encoded.

In other words, any conversion between string formats needs to have a=20
reporting system for failures.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_633_21850462.1399960794139
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, May 13, 2014 12:35:07 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> If we want such a family I would strongly encourage to determine what=20
> is the intend here:=20
>
> a) Unchanged against any localization/global effects (except memory=20
> allocation)=20
> ->=20
> This is some important property that I would like to see somewhere. We=20
> cannot use to_string for this, because it doesn't hold for the=20
> built-in types.=20
>
> b) ?=20
>
> Java's toString implementations of the "primitive" types and their=20
> corresponding Object reference types guarantees (a), which I consider=20
> as a very reasonable strategy.=20
>

Yes, something locale-independent would be nice. In some of my experiments,=
=20
I've tried creating a set of functions of the form=20
to_string<StringType>(ArgType), e.g. to_string<std::string>(123) =3D>=20
std::string("123"). This expands on the original proposal's notion of using=
=20
this for generic functions, since you can now parameterize on the string=20
type as well as the argument type.

For locale-dependent stringification, I think using I/O streams makes more=
=20
sense, since you can define the locale via the stream. Globally-defined=20
locales are really just a good way to introduce machine-specific bugs.

- Jim

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_633_21850462.1399960794139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, May 13, 2014 12:35:07 AM UTC-5, Daniel Kr=C3=
=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If we want such =
a family I would strongly encourage to determine what
<br>is the intend here:
<br>
<br>a) Unchanged against any localization/global effects (except memory all=
ocation)
<br>-&gt;
<br>This is some important property that I would like to see somewhere. We
<br>cannot use to_string for this, because it doesn't hold for the
<br>built-in types.
<br>
<br>b) ?
<br>
<br>Java's toString implementations of the "primitive" types and their
<br>corresponding Object reference types guarantees (a), which I consider
<br>as a very reasonable strategy.
<br></blockquote><div><br>Yes, something locale-independent would be nice. =
In some of my experiments, I've tried creating a set of functions of the fo=
rm to_string&lt;StringType&gt;(ArgType), e.g. to_string&lt;std::string&gt;(=
123) =3D&gt; std::string("123"). This expands on the original proposal's no=
tion of using this for generic functions, since you can now parameterize on=
 the string type as well as the argument type.<br><br>For locale-dependent =
stringification, I think using I/O streams makes more sense, since you can =
define the locale via the stream. Globally-defined locales are really just =
a good way to introduce machine-specific bugs.<br><br>- Jim<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_633_21850462.1399960794139--

.

--Apple-Mail=_51339D63-12D3-4B67-8FAC-ADA9C0CE2D1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-05-13, at 1:35 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wro=
te:

> 2014-05-13 2:01 GMT+02:00 David Krauss <potswa@gmail.com>:
>>=20
>> As someone recently noted here, to_string doesn't respect localization. =
It's better suited to serialization than user or OS interfaces.
>>=20
>=20
> Unfortunately to_string still provides locale-dependency, albeit not
> to grouping symbols, but is not guaranteed to be "pure". It still is
> affected by locale effects that influence the decimal separator, for
> example.

I've never used a compliant locales implementation (my OS of choice, Mac, i=
s barely functional), but my impression of the spec is that to_string depen=
ds on the C library locale as set by setlocale, which is supposed to be ind=
ependent of the C++ standard library (but isn't, at least on my OS, where t=
he C library is the *only* way to set the C++ locale).

> the to_(w)string functions were provided just as convenience functions
> and were not intended to derive a family of ADL-lookup functions from
> this.
>=20
> If we want such a family I would strongly encourage to determine what
> is the intend here:
>=20
> a) Unchanged against any localization/global effects (except memory alloc=
ation)
> ->
> This is some important property that I would like to see somewhere. We
> cannot use to_string for this, because it doesn't hold for the
> built-in types.

Moreover, locale dependencies if any should be specified, along with genera=
l functionality, in terms of the C++ library, not C. The only reason I can =
imagine for definition in terms of sprintf was as a lazy attempt to avoid l=
ocale dependency.

There could be an optional locale argument which, if omitted, defaults to t=
he "C" locale rather than the default locale. This would allow for eliminat=
ion of dynamic dispatches, which is the only way to obtain satisfactory per=
formance in string generation intensive applications.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_51339D63-12D3-4B67-8FAC-ADA9C0CE2D1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05&ndash;13, at 1:35 PM, Daniel Kr=FCgler &lt;<a href=3D"mailto:danie=
l.kruegler@gmail.com">daniel.kruegler@gmail.com</a>&gt; wrote:</div><br cla=
ss=3D"Apple-interchange-newline"><blockquote type=3D"cite">2014-05-13 2:01 =
GMT+02:00 David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gmail=
..com</a>&gt;:<br><blockquote type=3D"cite"><br>As someone recently noted he=
re, to_string doesn't respect localization. It's better suited to serializa=
tion than user or OS interfaces.<br><br></blockquote><br>Unfortunately to_s=
tring still provides locale-dependency, albeit not<br>to grouping symbols, =
but is not guaranteed to be "pure". It still is<br>affected by locale effec=
ts that influence the decimal separator, for<br>example.<br></blockquote><d=
iv><br></div>I&rsquo;ve never used a compliant locales implementation (my O=
S of choice, Mac, is barely functional), but my impression of the spec is t=
hat <font face=3D"Courier">to_string</font> depends&nbsp;on the C library l=
ocale as set by <font face=3D"Courier">setlocale</font>, which is supposed =
to be independent of the C++ standard library (but isn&rsquo;t, at least on=
 my OS, where the C library is the *<i>only</i>* way to set the C++ locale)=
..</div><div><br><blockquote type=3D"cite">the to_(w)string functions were p=
rovided just as convenience functions<br>and were not intended to derive a =
family of ADL-lookup functions from<br>this.<br><br>If we want such a famil=
y I would strongly encourage to determine what<br>is the intend here:<br><b=
r>a) Unchanged against any localization/global effects (except memory alloc=
ation)<br>-&gt;<br>This is some important property that I would like to see=
 somewhere. We<br>cannot use to_string for this, because it doesn't hold fo=
r the<br>built-in types.<br></blockquote><div><br></div><div>Moreover, loca=
le dependencies if any should be specified, along with general functionalit=
y, in terms of the C++ library, not C. The only reason I can imagine for de=
finition in terms of <font face=3D"Courier">sprintf</font> was as a lazy at=
tempt to avoid locale dependency.</div></div><div><br></div><div>There coul=
d be an optional locale argument which, if omitted, defaults to the <font f=
ace=3D"Courier">&ldquo;C&rdquo;</font> locale rather than the default local=
e. This would allow for elimination of dynamic dispatches, which is the onl=
y way to obtain satisfactory performance in string generation intensive app=
lications.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_51339D63-12D3-4B67-8FAC-ADA9C0CE2D1B--

.

2014-05-13 11:58 GMT+02:00 David Krauss <potswa@gmail.com>:
> On 2014-05-13, at 1:35 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.com> w=
rote:
> 2014-05-13 2:01 GMT+02:00 David Krauss <potswa@gmail.com>:
> As someone recently noted here, to_string doesn't respect localization. I=
t's
> better suited to serialization than user or OS interfaces.
>
> Unfortunately to_string still provides locale-dependency, albeit not
> to grouping symbols, but is not guaranteed to be "pure". It still is
> affected by locale effects that influence the decimal separator, for
> example.
>
> I've never used a compliant locales implementation (my OS of choice, Mac,=
 is
> barely functional), but my impression of the spec is that to_string depen=
ds
> on the C library locale as set by setlocale, which is supposed to be
> independent of the C++ standard library (but isn't, at least on my OS, wh=
ere
> the C library is the *only* way to set the C++ locale).

It is exactly the dependency on std::setlocale() I was referring to.
It is part of the C++ Standard library by inclusion and whether this
is a C dependency or a C++ dependency, is irrelevant for me. And any
(named) changes to the global std::local can also impact the
std::sprintf behaviour (22.3.1.5 [locale.statics]) p2:

"Effects: Causes future calls to the constructor locale() to return a
copy of the argument. If the
argument has a name, does

std::setlocale(LC_ALL, loc.name().c_str());

otherwise, the effect on the C locale, if any, is implementation-defined."

- Daniel

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.