Topic: to_string(string)
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 14:06:36 -0300
Raw View
Is there any reason for the lack of an overloaded version of to_string
receiving a string? (in which case would work as the identity)
This is useful when the argument is a template argument.
For example:
template <class T>
void f(T t)
{
auto x =3D "Hello " + std::to_string(t);
}
then call it with t=3D1, t=3D"World", etc.
Sorry if I'm missing something too obvious.
Daniel.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 29 May 2015 12:13:59 -0500
Raw View
--e89a8ff2528284b9c505173b9c0d
Content-Type: text/plain; charset=UTF-8
On 29 May 2015 at 12:06, dgutson . <danielgutson@gmail.com> wrote:
> Is there any reason for the lack of an overloaded version of to_string
> receiving a string? (in which case would work as the identity)
> This is useful when the argument is a template argument.
> For example:
>
> template <class T>
> void f(T t)
> {
> auto x = "Hello " + std::to_string(t);
> }
>
> then call it with t=1, t="World", etc.
>
> Sorry if I'm missing something too obvious.
Perhaps to avoid an unintentional copy?
No real idea why, though.
Nevin :-)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--e89a8ff2528284b9c505173b9c0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
9 May 2015 at 12:06, dgutson . <span dir=3D"ltr"><<a href=3D"mailto:dani=
elgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Is there any reason for the lack =
of an overloaded version of to_string<br>
receiving a string? (in which case would work as the identity)<br>
This is useful when the argument is a template argument.<br>
For example:<br>
<br>
template <class T><br>
void f(T t)<br>
{<br>
=C2=A0 =C2=A0 auto x =3D "Hello " + std::to_string(t);<br>
}<br>
<br>
then call it with t=3D1, t=3D"World", etc.<br>
<br>
Sorry if I'm missing something too obvious.</blockquote><div><br></div>=
<div>Perhaps to avoid an unintentional copy?</div><div><br></div><div>No re=
al idea why, though.</div><div>=C2=A0Nevin :-)=C2=A0</div></div>-- <br><div=
class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <mail=
to:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilov=
erlord.com</a>>=C2=A0 (847) 691-1404</div>
</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" 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 />
--e89a8ff2528284b9c505173b9c0d--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 14:23:19 -0300
Raw View
On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 29 May 2015 at 12:06, dgutson . <danielgutson@gmail.com> wrote:
>>
>> Is there any reason for the lack of an overloaded version of to_string
>> receiving a string? (in which case would work as the identity)
>> This is useful when the argument is a template argument.
>> For example:
>>
>> template <class T>
>> void f(T t)
>> {
>> auto x =3D "Hello " + std::to_string(t);
>> }
>>
>> then call it with t=3D1, t=3D"World", etc.
>>
>> Sorry if I'm missing something too obvious.
>
>
> Perhaps to avoid an unintentional copy?
It shouldn't be necessary if the argument is const string& and the
return type is also const reference.
(the following snippet works for me:
namespace std
{
const string& to_string(const string& x)
{
return x;
}
}
)
>
> No real idea why, though.
> Nevin :-)
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 29 May 2015 13:02:54 -0500
Raw View
--089e013d04ee7722ba05173c4bed
Content-Type: text/plain; charset=UTF-8
On 29 May 2015 at 12:23, dgutson . <danielgutson@gmail.com> wrote:
> On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > On 29 May 2015 at 12:06, dgutson . <danielgutson@gmail.com> wrote:
> >>
> >> Is there any reason for the lack of an overloaded version of to_string
> >> receiving a string? (in which case would work as the identity)
> >> This is useful when the argument is a template argument.
> >> For example:
> >>
> >> template <class T>
> >> void f(T t)
> >> {
> >> auto x = "Hello " + std::to_string(t);
> >> }
> >>
> >> then call it with t=1, t="World", etc.
> >>
> >> Sorry if I'm missing something too obvious.
> >
> >
> > Perhaps to avoid an unintentional copy?
>
> It shouldn't be necessary if the argument is const string& and the
> return type is also const reference.
>
Having everything else return by value while this returns by const
reference is a hack which is ultimately a bad design for generic code. For
instance, this now returns a dangling reference:
auto& r = to_string("Ok"); // ok
auto& s = to_string(string("Oops")); // oops
While you can fix the dangling reference problem with yet another overload
(string to_string(string const&&)), you still have to understand the
lifetime extension rules for references to use it efficiently in generic
code.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--089e013d04ee7722ba05173c4bed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
9 May 2015 at 12:23, dgutson . <span dir=3D"ltr"><<a href=3D"mailto:dani=
elgutson@gmail.com" target=3D"_blank">danielgutson@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span>On Fri, May 29, 2015 at 2:1=
3 PM, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_=
blank">nevin@eviloverlord.com</a>> wrote:<br>
> On 29 May 2015 at 12:06, dgutson . <<a href=3D"mailto:danielgutson@=
gmail.com" target=3D"_blank">danielgutson@gmail.com</a>> wrote:<br>
>><br>
>> Is there any reason for the lack of an overloaded version of to_st=
ring<br>
>> receiving a string? (in which case would work as the identity)<br>
>> This is useful when the argument is a template argument.<br>
>> For example:<br>
>><br>
>> template <class T><br>
>> void f(T t)<br>
>> {<br>
>>=C2=A0 =C2=A0 =C2=A0auto x =3D "Hello " + std::to_string(=
t);<br>
>> }<br>
>><br>
>> then call it with t=3D1, t=3D"World", etc.<br>
>><br>
>> Sorry if I'm missing something too obvious.<br>
><br>
><br>
> Perhaps to avoid an unintentional copy?<br>
<br>
</span>It shouldn't be necessary if the argument is const string& a=
nd the<br>
return type is also const reference.<br></blockquote><div><br></div><div>Ha=
ving everything else return by value while this returns by const reference =
is a hack which is ultimately a bad design for generic code.=C2=A0 For inst=
ance, this now returns a dangling reference:</div><div><br></div><div>auto&=
amp; r =3D to_string("Ok"); =C2=A0// ok</div><div>auto& s =3D=
to_string(string("Oops")); =C2=A0// oops</div><div><br></div><di=
v>While you can fix the dangling reference problem with yet another overloa=
d (string to_string(string const&&)), you still have to understand =
the lifetime extension rules for references to use it efficiently in generi=
c code.</div></div>-- <br><div>=C2=A0Nevin ":-)" Liber=C2=A0 <=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>>=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"=
+18476911404" target=3D"_blank">(847) 691-1404</a></div>
</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" 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 />
--089e013d04ee7722ba05173c4bed--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 29 May 2015 11:09:28 -0700
Raw View
--089e013c69d28dc6fa05173c6035
Content-Type: text/plain; charset=UTF-8
On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com>
wrote:
>
> Having everything else return by value while this returns by const
> reference is a hack which is ultimately a bad design for generic code. For
> instance, this now returns a dangling reference:
>
> auto& r = to_string("Ok"); // ok
> auto& s = to_string(string("Oops")); // oops
>
> While you can fix the dangling reference problem with yet another overload
> (string to_string(string const&&)), you still have to understand the
> lifetime extension rules for references to use it efficiently in generic
> code.
>
Agreed.
I do think an overload for strings is good, though, even though it implies
a copy or at least a move.
--
---
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/.
--089e013c69d28dc6fa05173c6035
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 29, 2015 at 11:02 AM, Nevin Liber <span dir=3D"ltr"><<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>Having everything else re=
turn by value while this returns by const reference is a hack which is ulti=
mately a bad design for generic code.=C2=A0 For instance, this now returns =
a dangling reference:</div><div><br></div><div>auto& r =3D to_string(&q=
uot;Ok"); =C2=A0// ok</div><div>auto& s =3D to_string(string("=
;Oops")); =C2=A0// oops</div><div><br></div><div>While you can fix the=
dangling reference problem with yet another overload (string to_string(str=
ing const&&)), you still have to understand the lifetime extension =
rules for references to use it efficiently in generic code.</div></div></di=
v></div></blockquote><div><br></div><div>Agreed.</div><div><br></div><div>I=
do think an overload for strings is good, though, even though it implies a=
copy or at least a move.</div></div></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" 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 />
--089e013c69d28dc6fa05173c6035--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 15:11:23 -0300
Raw View
On Fri, May 29, 2015 at 3:02 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 29 May 2015 at 12:23, dgutson . <danielgutson@gmail.com> wrote:
>>
>> On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>> > On 29 May 2015 at 12:06, dgutson . <danielgutson@gmail.com> wrote:
>> >>
>> >> Is there any reason for the lack of an overloaded version of to_strin=
g
>> >> receiving a string? (in which case would work as the identity)
>> >> This is useful when the argument is a template argument.
>> >> For example:
>> >>
>> >> template <class T>
>> >> void f(T t)
>> >> {
>> >> auto x =3D "Hello " + std::to_string(t);
>> >> }
>> >>
>> >> then call it with t=3D1, t=3D"World", etc.
>> >>
>> >> Sorry if I'm missing something too obvious.
>> >
>> >
>> > Perhaps to avoid an unintentional copy?
>>
>> It shouldn't be necessary if the argument is const string& and the
>> return type is also const reference.
>
>
> Having everything else return by value while this returns by const refere=
nce
> is a hack which is ultimately a bad design for generic code. For instanc=
e,
> this now returns a dangling reference:
>
> auto& r =3D to_string("Ok"); // ok
> auto& s =3D to_string(string("Oops")); // oops
Right, shame on me.
>
> While you can fix the dangling reference problem with yet another overloa=
d
> (string to_string(string const&&)), you still have to understand the
> lifetime extension rules for references to use it efficiently in generic
> code.
I do. Thanks anyway.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 15:14:06 -0300
Raw View
On Fri, May 29, 2015 at 3:09 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>>
>> Having everything else return by value while this returns by const
>> reference is a hack which is ultimately a bad design for generic code. =
For
>> instance, this now returns a dangling reference:
>>
>> auto& r =3D to_string("Ok"); // ok
>> auto& s =3D to_string(string("Oops")); // oops
>>
>> While you can fix the dangling reference problem with yet another overlo=
ad
>> (string to_string(string const&&)), you still have to understand the
>> lifetime extension rules for references to use it efficiently in generic
>> code.
>
>
> Agreed.
>
> I do think an overload for strings is good, though, even though it implie=
s a
> copy or at least a move.
Since I won't go to Lenexa, could someone champion this for me please?
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 29 May 2015 13:22:13 -0500
Raw View
--001a11c3393a8729da05173c9071
Content-Type: text/plain; charset=UTF-8
On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>>
>> Having everything else return by value while this returns by const
>> reference is a hack which is ultimately a bad design for generic code. For
>> instance, this now returns a dangling reference:
>>
>> auto& r = to_string("Ok"); // ok
>> auto& s = to_string(string("Oops")); // oops
>>
>> While you can fix the dangling reference problem with yet another
>> overload (string to_string(string const&&)), you still have to understand
>> the lifetime extension rules for references to use it efficiently in
>> generic code.
>>
>
> Agreed.
>
> I do think an overload for strings is good, though, even though it implies
> a copy or at least a move.
>
Of course, the purpose of to_string is to convert a numeric value to a
string, and adding a string overload doesn't meet that purpose.
That being said, I probably wouldn't vote against such a thing, but I don't
plan on championing it either (especially in Lenexa, as that was a few
weeks ago :-)).
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a11c3393a8729da05173c9071
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
9 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future=
Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org=
" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D"">On Fri, May 29, 2015 at 11:02 AM, Ne=
vin Liber <span dir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>></span> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><div>Having everything else return by value while this returns=
by const reference is a hack which is ultimately a bad design for generic =
code.=C2=A0 For instance, this now returns a dangling reference:</div><div>=
<br></div><div>auto& r =3D to_string("Ok"); =C2=A0// ok</div>=
<div>auto& s =3D to_string(string("Oops")); =C2=A0// oops</di=
v><div><br></div><div>While you can fix the dangling reference problem with=
yet another overload (string to_string(string const&&)), you still=
have to understand the lifetime extension rules for references to use it e=
fficiently in generic code.</div></div></div></div></blockquote><div><br></=
div></span><div>Agreed.</div><div><br></div><div>I do think an overload for=
strings is good, though, even though it implies a copy or at least a move.=
</div></div></div></div></blockquote><div><br></div><div>Of course, the pur=
pose of to_string is to convert a numeric value to a string, and adding a s=
tring overload doesn't meet that purpose.</div><div><br></div><div>That=
being said, I probably wouldn't vote against such a thing, but I don&#=
39;t plan on championing it either (especially in Lenexa, as that was a few=
weeks ago :-)).</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nev=
in ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1=
404</div>
</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" 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 />
--001a11c3393a8729da05173c9071--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 16:02:23 -0300
Raw View
On Fri, May 29, 2015 at 3:22 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>>
>> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>>>
>>> Having everything else return by value while this returns by const
>>> reference is a hack which is ultimately a bad design for generic code. =
For
>>> instance, this now returns a dangling reference:
>>>
>>> auto& r =3D to_string("Ok"); // ok
>>> auto& s =3D to_string(string("Oops")); // oops
>>>
>>> While you can fix the dangling reference problem with yet another
>>> overload (string to_string(string const&&)), you still have to understa=
nd
>>> the lifetime extension rules for references to use it efficiently in ge=
neric
>>> code.
>>
>>
>> Agreed.
>>
>> I do think an overload for strings is good, though, even though it impli=
es
>> a copy or at least a move.
>
>
> Of course, the purpose of to_string is to convert a numeric value to a
> string, and adding a string overload doesn't meet that purpose.
>
> That being said, I probably wouldn't vote against such a thing, but I don=
't
> plan on championing it either (especially in Lenexa, as that was a few we=
eks
> ago :-)).
:) my brain is burnt.
Anyway, since I'm not sure if I will attend Kona either (until we come up w=
ith a
full battery of proposals related to the embedded domain), anyone intereste=
d?
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Patrice Roy <patricer@gmail.com>
Date: Fri, 29 May 2015 15:18:17 -0400
Raw View
--001a11c3c836a2f3a905173d56b9
Content-Type: text/plain; charset=UTF-8
I'm planning on being there. If there are embedded system-related proposals
to present there (presuming I don't strongly disagree with them), I can do
it. Cheers!
2015-05-29 15:02 GMT-04:00 dgutson . <danielgutson@gmail.com>:
> On Fri, May 29, 2015 at 3:22 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future
> > Proposals <std-proposals@isocpp.org> wrote:
> >>
> >> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com>
> >> wrote:
> >>>
> >>> Having everything else return by value while this returns by const
> >>> reference is a hack which is ultimately a bad design for generic
> code. For
> >>> instance, this now returns a dangling reference:
> >>>
> >>> auto& r = to_string("Ok"); // ok
> >>> auto& s = to_string(string("Oops")); // oops
> >>>
> >>> While you can fix the dangling reference problem with yet another
> >>> overload (string to_string(string const&&)), you still have to
> understand
> >>> the lifetime extension rules for references to use it efficiently in
> generic
> >>> code.
> >>
> >>
> >> Agreed.
> >>
> >> I do think an overload for strings is good, though, even though it
> implies
> >> a copy or at least a move.
> >
> >
> > Of course, the purpose of to_string is to convert a numeric value to a
> > string, and adding a string overload doesn't meet that purpose.
> >
> > That being said, I probably wouldn't vote against such a thing, but I
> don't
> > plan on championing it either (especially in Lenexa, as that was a few
> weeks
> > ago :-)).
>
> :) my brain is burnt.
>
> Anyway, since I'm not sure if I will attend Kona either (until we come up
> with a
> full battery of proposals related to the embedded domain), anyone
> interested?
>
> > --
> > Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
> >
> > --
> >
> > ---
> > 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/.
>
>
>
> --
> Who's got the sweetest disposition?
> One guess, that's who?
> Who'd never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c3c836a2f3a905173d56b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm planning on being there. If there are embedded sys=
tem-related proposals to present there (presuming I don't strongly disa=
gree with them), I can do it. Cheers!<br></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">2015-05-29 15:02 GMT-04:00 dgutson . <span di=
r=3D"ltr"><<a href=3D"mailto:danielgutson@gmail.com" target=3D"_blank">d=
anielgutson@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an class=3D"">On Fri, May 29, 2015 at 3:22 PM, Nevin Liber <<a href=3D"m=
ailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:<br>
> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard=
- Future<br>
> Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-proposal=
s@isocpp.org</a>> wrote:<br>
>><br>
>> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <<a href=3D"mailt=
o:nevin@eviloverlord.com">nevin@eviloverlord.com</a>><br>
>> wrote:<br>
>>><br>
>>> Having everything else return by value while this returns by c=
onst<br>
>>> reference is a hack which is ultimately a bad design for gener=
ic code. For<br>
>>> instance, this now returns a dangling reference:<br>
>>><br>
>>> auto& r =3D to_string("Ok"); // ok<br>
>>> auto& s =3D to_string(string("Oops")); // =
oops<br>
>>><br>
>>> While you can fix the dangling reference problem with yet anot=
her<br>
>>> overload (string to_string(string const&&)), you still=
have to understand<br>
>>> the lifetime extension rules for references to use it efficien=
tly in generic<br>
>>> code.<br>
>><br>
>><br>
>> Agreed.<br>
>><br>
>> I do think an overload for strings is good, though, even though it=
implies<br>
>> a copy or at least a move.<br>
><br>
><br>
> Of course, the purpose of to_string is to convert a numeric value to a=
<br>
> string, and adding a string overload doesn't meet that purpose.<br=
>
><br>
> That being said, I probably wouldn't vote against such a thing, bu=
t I don't<br>
> plan on championing it either (especially in Lenexa, as that was a few=
weeks<br>
> ago :-)).<br>
<br>
</span>:) my brain is burnt.<br>
<br>
Anyway, since I'm not sure if I will attend Kona either (until we come =
up with a<br>
full battery of proposals related to the embedded domain), anyone intereste=
d?<br>
<span class=3D"im HOEnZb"><br>
> --<br>
> Nevin ":-)" Liber <mailto:<a href=3D"mailto:n=
evin@eviloverlord.com">nevin@eviloverlord.com</a>> <a href=3D"tel:=
%28847%29%20691-1404" value=3D"+18476911404">(847) 691-1404</a><br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups<br>
> "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an<br>
> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
<br>
<br>
</span><span class=3D"im HOEnZb">--<br>
Who’s got the sweetest disposition?<br>
One guess, that’s who?<br>
Who’d never, ever start an argument?<br>
Who never shows a bit of temperament?<br>
Who's never wrong but always right?<br>
Who'd never dream of starting a fight?<br>
Who get stuck with all the bad luck?<br>
<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c3c836a2f3a905173d56b9--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 29 May 2015 16:28:56 -0300
Raw View
On Fri, May 29, 2015 at 4:18 PM, Patrice Roy <patricer@gmail.com> wrote:
> I'm planning on being there. If there are embedded system-related proposa=
ls
> to present there (presuming I don't strongly disagree with them), I can d=
o
> it. Cheers!
Thanks Patrice. I was referring to the to_string(string) proposal (are
you interested?).
Regarding the embedded stuff, let's continue talking in the mailing
list (where we'll
post some new stuff by the weekend) and let's see.
Thanks!
Daniel.
>
> 2015-05-29 15:02 GMT-04:00 dgutson . <danielgutson@gmail.com>:
>>
>> On Fri, May 29, 2015 at 3:22 PM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>> > On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Futur=
e
>> > Proposals <std-proposals@isocpp.org> wrote:
>> >>
>> >> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <nevin@eviloverlord.com=
>
>> >> wrote:
>> >>>
>> >>> Having everything else return by value while this returns by const
>> >>> reference is a hack which is ultimately a bad design for generic cod=
e.
>> >>> For
>> >>> instance, this now returns a dangling reference:
>> >>>
>> >>> auto& r =3D to_string("Ok"); // ok
>> >>> auto& s =3D to_string(string("Oops")); // oops
>> >>>
>> >>> While you can fix the dangling reference problem with yet another
>> >>> overload (string to_string(string const&&)), you still have to
>> >>> understand
>> >>> the lifetime extension rules for references to use it efficiently in
>> >>> generic
>> >>> code.
>> >>
>> >>
>> >> Agreed.
>> >>
>> >> I do think an overload for strings is good, though, even though it
>> >> implies
>> >> a copy or at least a move.
>> >
>> >
>> > Of course, the purpose of to_string is to convert a numeric value to a
>> > string, and adding a string overload doesn't meet that purpose.
>> >
>> > That being said, I probably wouldn't vote against such a thing, but I
>> > don't
>> > plan on championing it either (especially in Lenexa, as that was a few
>> > weeks
>> > ago :-)).
>>
>> :) my brain is burnt.
>>
>> Anyway, since I'm not sure if I will attend Kona either (until we come u=
p
>> with a
>> full battery of proposals related to the embedded domain), anyone
>> interested?
>>
>> > --
>> > Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>> >
>> > --
>> >
>> > ---
>> > 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/.
>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
>
> --
>
> ---
> 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/.
--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=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/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Sat, 30 May 2015 11:48:18 +0200
Raw View
On 2015-05-29 20:22, Nevin Liber wrote:
> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals <std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>>
> wrote:
>
> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber
> <nevin@eviloverlord.com <mailto:nevin@eviloverlord.com>> wrote:
>
> Having everything else return by value while this returns by
> const reference is a hack which is ultimately a bad design for
> generic code. For instance, this now returns a dangling reference:
>
> auto& r = to_string("Ok"); // ok
> auto& s = to_string(string("Oops")); // oops
>
> While you can fix the dangling reference problem with yet
> another overload (string to_string(string const&&)), you still
> have to understand the lifetime extension rules for references
> to use it efficiently in generic code.
>
>
> Agreed.
>
> I do think an overload for strings is good, though, even though it
> implies a copy or at least a move.
>
>
> Of course, the purpose of to_string is to convert a numeric value to a
> string, and adding a string overload doesn't meet that purpose.
>
Right. If widening the scope of to_string, why just add it for
std::string? What about all the other standard library types? >:)
Bo Persson
--
---
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/.
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Sat, 30 May 2015 10:32:37 -0300
Raw View
--001a1139d5a449a6df05174ca0f7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El 30/5/2015 6:48, "Bo Persson" <bop@gmb.dk> escribi=C3=B3:
>
> On 2015-05-29 20:22, Nevin Liber wrote:
>>
>> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Future
>> Proposals <std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>>
>>
>> wrote:
>>
>> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber
>> <nevin@eviloverlord.com <mailto:nevin@eviloverlord.com>> wrote:
>>
>> Having everything else return by value while this returns by
>> const reference is a hack which is ultimately a bad design for
>> generic code. For instance, this now returns a dangling
reference:
>>
>> auto& r =3D to_string("Ok"); // ok
>> auto& s =3D to_string(string("Oops")); // oops
>>
>> While you can fix the dangling reference problem with yet
>> another overload (string to_string(string const&&)), you still
>> have to understand the lifetime extension rules for references
>> to use it efficiently in generic code.
>>
>>
>> Agreed.
>>
>> I do think an overload for strings is good, though, even though it
>> implies a copy or at least a move.
>>
>>
>> Of course, the purpose of to_string is to convert a numeric value to a
>> string, and adding a string overload doesn't meet that purpose.
>>
>
> Right. If widening the scope of to_string, why just add it for
std::string? What about all the other standard library types? >:)
For example?
We used to do this with a strinstream and all the formatting manipulators
complexity.
String-to-string conversion is trivial.
What other types would you convert and with which criteria?
>
>
> Bo Persson
>
>
>
>
> --
>
> --- 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/.
--=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/.
--001a1139d5a449a6df05174ca0f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
El 30/5/2015 6:48, "Bo Persson" <<a href=3D"mailto:bop@gmb.dk"=
>bop@gmb.dk</a>> escribi=C3=B3:<br>
><br>
> On 2015-05-29 20:22, Nevin Liber wrote:<br>
>><br>
>> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Stan=
dard - Future<br>
>> Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-prop=
osals@isocpp.org</a> <mailto:<a href=3D"mailto:std-proposals@isocpp.org"=
>std-proposals@isocpp.org</a>>><br>
>><br>
>> wrote:<br>
>><br>
>> =C2=A0 =C2=A0 On Fri, May 29, 2015 at 11:02 AM, Nevin Liber<br>
>> =C2=A0 =C2=A0 <<a href=3D"mailto:nevin@eviloverlord.com">nevin@=
eviloverlord.com</a> <mailto:<a href=3D"mailto:nevin@eviloverlord.com">n=
evin@eviloverlord.com</a>>> wrote:<br>
>><br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Having everything else return by value=
while this returns by<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 const reference is a hack which is ult=
imately a bad design for<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 generic code.=C2=A0 For instance, this=
now returns a dangling reference:<br>
>><br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto& r =3D to_string("Ok&quo=
t;);=C2=A0 // ok<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto& s =3D to_string(string("=
;Oops"));=C2=A0 // oops<br>
>><br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 While you can fix the dangling referen=
ce problem with yet<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 another overload (string to_string(str=
ing const&&)), you still<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 have to understand the lifetime extens=
ion rules for references<br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 to use it efficiently in generic code.=
<br>
>><br>
>><br>
>> =C2=A0 =C2=A0 Agreed.<br>
>><br>
>> =C2=A0 =C2=A0 I do think an overload for strings is good, though, =
even though it<br>
>> =C2=A0 =C2=A0 implies a copy or at least a move.<br>
>><br>
>><br>
>> Of course, the purpose of to_string is to convert a numeric value =
to a<br>
>> string, and adding a string overload doesn't meet that purpose=
..<br>
>><br>
><br>
> Right. If widening the scope of to_string, why just add it for std::st=
ring? What about all the other standard library types?=C2=A0 >:)</p>
<p dir=3D"ltr">For example?<br>
We used to do this with a strinstream and all the formatting manipulators c=
omplexity.<br>
String-to-string conversion is trivial.<br>
What other types would you convert and with which criteria?</p>
<p dir=3D"ltr">><br>
><br>
> Bo Persson<br>
><br>
><br>
><br>
><br>
> -- <br>
><br>
> --- You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1139d5a449a6df05174ca0f7--
.
Author: Bo Persson <bop@gmb.dk>
Date: Sat, 30 May 2015 17:36:22 +0200
Raw View
On 2015-05-30 15:32, dgutson . wrote:
>
> El 30/5/2015 6:48, "Bo Persson" <bop@gmb.dk <mailto:bop@gmb.dk>> escribi=
=C3=B3:
> >
> > On 2015-05-29 20:22, Nevin Liber wrote:
> >>
> >> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard - Futu=
re
> >> Proposals <std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org> <mailto:std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>>>
> >>
> >> wrote:
> >>
> >> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber
> >> <nevin@eviloverlord.com <mailto:nevin@eviloverlord.com>
> <mailto:nevin@eviloverlord.com <mailto:nevin@eviloverlord.com>>> wrote:
> >>
> >> Having everything else return by value while this returns by
> >> const reference is a hack which is ultimately a bad design fo=
r
> >> generic code. For instance, this now returns a dangling
> reference:
> >>
> >> auto& r =3D to_string("Ok"); // ok
> >> auto& s =3D to_string(string("Oops")); // oops
> >>
> >> While you can fix the dangling reference problem with yet
> >> another overload (string to_string(string const&&)), you stil=
l
> >> have to understand the lifetime extension rules for reference=
s
> >> to use it efficiently in generic code.
> >>
> >>
> >> Agreed.
> >>
> >> I do think an overload for strings is good, though, even though i=
t
> >> implies a copy or at least a move.
> >>
> >>
> >> Of course, the purpose of to_string is to convert a numeric value to =
a
> >> string, and adding a string overload doesn't meet that purpose.
> >>
> >
> > Right. If widening the scope of to_string, why just add it for
> std::string? What about all the other standard library types? >:)
>
> For example?
> We used to do this with a strinstream and all the formatting
> manipulators complexity.
> String-to-string conversion is trivial.
> What other types would you convert and with which criteria?
>
YOU are changing the criteria. I just try to play the devil's advocate.
So, if to_string is not just for built-in numeric types, what about=20
std::complex? std::bitset has a to_string member function, why not add a=20
free function for the symmetry? The same for upcoming string_view and=20
filesystem::path?
A proposal might include some reasoning about why or why not adding more=20
functions.
Bo Persson
--=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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 30 May 2015 09:35:08 -0700 (PDT)
Raw View
------=_Part_1691_14714919.1433003708969
Content-Type: multipart/alternative;
boundary="----=_Part_1692_353024228.1433003708969"
------=_Part_1692_353024228.1433003708969
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, May 30, 2015 at 11:36:50 AM UTC-4, Bo Persson wrote:
>
> On 2015-05-30 15:32, dgutson . wrote:=20
> >=20
> > El 30/5/2015 6:48, "Bo Persson" <b...@gmb.dk <javascript:> <mailto:
> b...@gmb.dk <javascript:>>> escribi=C3=B3:=20
> > >=20
> > > On 2015-05-29 20:22, Nevin Liber wrote:=20
> > >>=20
> > >> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C++ Standard -=20
> Future=20
> > >> Proposals <std-pr...@isocpp.org <javascript:>=20
> > <mailto:std-pr...@isocpp.org <javascript:>> <mailto:std-pr...@isocpp.or=
g=20
> <javascript:>=20
> > <mailto:std-pr...@isocpp.org <javascript:>>>>=20
> > >>=20
> > >> wrote:=20
> > >>=20
> > >> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber=20
> > >> <ne...@eviloverlord.com <javascript:> <mailto:
> ne...@eviloverlord.com <javascript:>>=20
> > <mailto:ne...@eviloverlord.com <javascript:> <mailto:
> ne...@eviloverlord.com <javascript:>>>> wrote:=20
> > >>=20
> > >> Having everything else return by value while this returns b=
y=20
> > >> const reference is a hack which is ultimately a bad design=
=20
> for=20
> > >> generic code. For instance, this now returns a dangling=20
> > reference:=20
> > >>=20
> > >> auto& r =3D to_string("Ok"); // ok=20
> > >> auto& s =3D to_string(string("Oops")); // oops=20
> > >>=20
> > >> While you can fix the dangling reference problem with yet=
=20
> > >> another overload (string to_string(string const&&)), you=20
> still=20
> > >> have to understand the lifetime extension rules for=20
> references=20
> > >> to use it efficiently in generic code.=20
> > >>=20
> > >>=20
> > >> Agreed.=20
> > >>=20
> > >> I do think an overload for strings is good, though, even though=
=20
> it=20
> > >> implies a copy or at least a move.=20
> > >>=20
> > >>=20
> > >> Of course, the purpose of to_string is to convert a numeric value t=
o=20
> a=20
> > >> string, and adding a string overload doesn't meet that purpose.=20
> > >>=20
> > >=20
> > > Right. If widening the scope of to_string, why just add it for=20
> > std::string? What about all the other standard library types? >:)=20
> >=20
> > For example?=20
> > We used to do this with a strinstream and all the formatting=20
> > manipulators complexity.=20
> > String-to-string conversion is trivial.=20
> > What other types would you convert and with which criteria?=20
> >=20
>
> YOU are changing the criteria. I just try to play the devil's advocate.=
=20
>
> So, if to_string is not just for built-in numeric types, what about=20
> std::complex? std::bitset has a to_string member function, why not add a=
=20
> free function for the symmetry? The same for upcoming string_view and=20
> filesystem::path?=20
>
> A proposal might include some reasoning about why or why not adding more=
=20
> functions.
>
So the question you seem to be asking is, "do we want a generalized=20
convert-any-type-to-string" mechanism?
Last time I checked *we have that*. It's called `operator<<(ostream &, T);`
Now, I can't say that I much care for that particular mechanism. But that's=
=20
mainly because I dispose iostream's seeming need to make string formatting=
=20
as slow and painful as possible.
`to_string` was never intended to be a replacement for operator<< so much=
=20
as simply a convenience function for a few simple, common string conversion=
=20
operations. I don't think it's appropriate to co-opt that into a=20
generalized mechanism.
At least, not without some serious thought about it.
Personally, I'd much rather see iostream get supplanted, and then build the=
=20
string conversion based on that. That way, you can deal with things like=20
optimizing buffer allocation based on knowing how big the converted string=
=20
will be, string_view interop, etc.
--=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_1692_353024228.1433003708969
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, May 30, 2015 at 11:36:50 AM UTC-4, Bo=
Persson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-05-30 1=
5:32, dgutson . wrote:
<br>>
<br>> El 30/5/2015 6:48, "Bo Persson" <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">b...@gmb.dk</a> <mailto:<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">b...@gmb.dk</a>>> escribi=C3=B3:
<br>> >
<br>> > On 2015-05-29 20:22, Nevin Liber wrote:
<br>> >>
<br>> >> On 29 May 2015 at 13:09, 'Matt Calabrese' via ISO C=
++ Standard - Future
<br>> >> Proposals <<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">std-pr...@isocpp.org</a>
<br>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.<wbr>org</a>> <mailto:<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">std-pr...@isocpp.<wbr>org</a>
<br>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.<wbr>org</a>>>>
<br>> >>
<br>> >> wrote:
<br>> >>
<br>> >> On Fri, May 29, 2015 at 11:02 AM, Nev=
in Liber
<br>> >> <<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">ne...@eviloverlord.com</a> <mailto:<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">ne...@eviloverlord.com</a><wbr>>
<br>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">n=
e...@eviloverlord.com</a> <mailto:<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"7QD_JBqRIOoJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">ne...@eviloverlord.com</a><wbr>>>> wrote:
<br>> >>
<br>> >> Having everything else =
return by value while this returns by
<br>> >> const reference is a ha=
ck which is ultimately a bad design for
<br>> >> generic code. For=
instance, this now returns a dangling
<br>> reference:
<br>> >>
<br>> >> auto& r =3D to_stri=
ng("Ok"); // ok
<br>> >> auto& s =3D to_stri=
ng(string("Oops")); // oops
<br>> >>
<br>> >> While you can fix the d=
angling reference problem with yet
<br>> >> another overload (strin=
g to_string(string const&&)), you still
<br>> >> have to understand the =
lifetime extension rules for references
<br>> >> to use it efficiently i=
n generic code.
<br>> >>
<br>> >>
<br>> >> Agreed.
<br>> >>
<br>> >> I do think an overload for strings is=
good, though, even though it
<br>> >> implies a copy or at least a move.
<br>> >>
<br>> >>
<br>> >> Of course, the purpose of to_string is to convert a=
numeric value to a
<br>> >> string, and adding a string overload doesn't meet t=
hat purpose.
<br>> >>
<br>> >
<br>> > Right. If widening the scope of to_string, why just add=
it for
<br>> std::string? What about all the other standard library types? &nbs=
p;>:)
<br>>
<br>> For example?
<br>> We used to do this with a strinstream and all the formatting
<br>> manipulators complexity.
<br>> String-to-string conversion is trivial.
<br>> What other types would you convert and with which criteria?
<br>>
<br>
<br>YOU are changing the criteria. I just try to play the devil's advocate.
<br>
<br>So, if to_string is not just for built-in numeric types, what about=20
<br>std::complex? std::bitset has a to_string member function, why not add =
a=20
<br>free function for the symmetry? The same for upcoming string_view and=
=20
<br>filesystem::path?
<br>
<br>A proposal might include some reasoning about why or why not adding mor=
e=20
<br>functions.<br></blockquote><div><br>So the question you seem to be aski=
ng is, "do we want a generalized convert-any-type-to-string" mechanism?<br>=
<br>Last time I checked <i>we have that</i>. It's called `operator<<(=
ostream &, T);`<br><br>Now, I can't say that I much care for that parti=
cular mechanism. But that's mainly because I dispose iostream's seeming nee=
d to make string formatting as slow and painful as possible.<br><br>`to_str=
ing` was never intended to be a replacement for operator<< so much as=
simply a convenience function for a few simple, common string conversion o=
perations. I don't think it's appropriate to co-opt that into a generalized=
mechanism.<br><br>At least, not without some serious thought about it.<br>=
<br>Personally, I'd much rather see iostream get supplanted, and then build=
the string conversion based on that. That way, you can deal with things li=
ke optimizing buffer allocation based on knowing how big the converted stri=
ng will be, string_view interop, etc.<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" 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_1692_353024228.1433003708969--
------=_Part_1691_14714919.1433003708969--
.