to_string(string)

[dgutson .]

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.

Daniel.

--
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?

[Nevin Liber]

On 29 May 2015 at 12:06, dgutson . <daniel...@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:ne...@eviloverlord.com>  (847) 691-1404

[dgutson .]

On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
> On 29 May 2015 at 12:06, dgutson . <daniel...@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.
(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:ne...@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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Nevin Liber]

On 29 May 2015 at 12:23, dgutson . <daniel...@gmail.com> wrote:

On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
> On 29 May 2015 at 12:06, dgutson . <daniel...@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.

[Matt Calabrese]

On Fri, May 29, 2015 at 11:02 AM, Nevin Liber <ne...@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.

[dgutson .]

On Fri, May 29, 2015 at 3:02 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
> On 29 May 2015 at 12:23, dgutson . <daniel...@gmail.com> wrote:
>>
>> On Fri, May 29, 2015 at 2:13 PM, Nevin Liber <ne...@eviloverlord.com>
>> wrote:
>> > On 29 May 2015 at 12:06, dgutson . <daniel...@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

Right, shame on me.

>
> 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.

I do. Thanks anyway.

> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
>

[dgutson .]

Since I won't go to Lenexa, could someone champion this for me please?

[Nevin Liber]

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 :-)).

[dgutson .]

:) 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:ne...@eviloverlord.com> (847) 691-1404
>

[Patrice Roy]

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!

[dgutson .]

On Fri, May 29, 2015 at 4:18 PM, Patrice Roy <patr...@gmail.com> wrote:
> 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!

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.

[Bo Persson]

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-pr...@isocpp.org <mailto:std-pr...@isocpp.org>>

> wrote:
>
> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber
> <ne...@eviloverlord.com <mailto:ne...@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

[dgutson .]

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

[Bo Persson]

On 2015-05-30 15:32, dgutson . wrote:

>
> El 30/5/2015 6:48, "Bo Persson" <b...@gmb.dk <mailto:b...@gmb.dk>> escribió:
> >
> > 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-pr...@isocpp.org

> <mailto:std-pr...@isocpp.org> <mailto:std-pr...@isocpp.org

> <mailto:std-pr...@isocpp.org>>>
> >>
> >> wrote:
> >>
> >> On Fri, May 29, 2015 at 11:02 AM, Nevin Liber
> >> <ne...@eviloverlord.com <mailto:ne...@eviloverlord.com>

> <mailto:ne...@eviloverlord.com <mailto:ne...@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? >:)
>
> 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
std::complex? std::bitset has a to_string member function, why not add a
free function for the symmetry? The same for upcoming string_view and
filesystem::path?

A proposal might include some reasoning about why or why not adding more
functions.


Bo Persson

[Nicol Bolas]

So the question you seem to be asking is, "do we want a generalized 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 mainly because I dispose iostream's seeming need to make string formatting as slow and painful as possible.

`to_string` was never intended to be a replacement for operator<< so much as simply a convenience function for a few simple, common string conversion operations. I don't think it's appropriate to co-opt that into a generalized mechanism.

At least, not without some serious thought about it.

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 like optimizing buffer allocation based on knowing how big the converted string will be, string_view interop, etc.