------=_Part_903_23875862.1368202472483
Content-Type: text/plain; charset=ISO-8859-1

On the old comp.std.c++ Usenet list, I made a suggestion about adding the
ability to move `basic_string`s into and out-of `basic_stringstream`s<https://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ>.
I'm considering making this an actual C++ proposal, so I wanted to gauge
the interest in doing this.

The general idea would be fairly simple, though it would have effects on
the implementation of the stringstreams. In effect, they would *have* to be
written to either internally use `basic_string` for their array of
characters, or their implementations would have to be synchronized with
`basic_string`, so that memory allocated between them could be transferred
appropriately.

The syntactic implication is quite simple. `basic_ostringstream` and
`basic_stringstream` would have a constructor that takes a `basic_string`
of the same character type. This constructor would adopt the
`basic_string`'s memory, as though it had moved the `basic_string` into an
internal `basic_string` instance.

There would also be a `move_str` member function which returns a
`basic_string` by value (it can't be returned by `&&`), but it leaves the
`basic_stringstream` or `basic_istringstream` in the infamous "valid but
undefined" state.

This would be part of a larger package of general changes with respect to
iostreams, such as better integration (by which I mean *some* integration)
with `string_view` or whatever we're calling it, improved allocator support
for the `stringstreams` (they don't even take allocator objects. People
seemed to have completely forgotten about `stringstream`s completely when
they added stateful allocators), and a couple of other things.

So is there any interest in this?

--

---
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/?hl=en.



------=_Part_903_23875862.1368202472483
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On the old comp.std.c++ Usenet list, I made a suggestion about <a href=3D"h=
ttps://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ"=
>adding the ability to move `basic_string`s into and out-of `basic_stringst=
ream`s</a>. I'm considering making this an actual C++ proposal, so I wanted=
 to gauge the interest in doing this.<br><br>The general idea would be fair=
ly simple, though it would have effects on the implementation of the string=
streams. In effect, they would <i>have</i> to be written to either internal=
ly use `basic_string` for their array of characters, or their implementatio=
ns would have to be synchronized with `basic_string`, so that memory alloca=
ted between them could be transferred appropriately.<br><br>The syntactic i=
mplication is quite simple. `basic_ostringstream` and `basic_stringstream` =
would have a constructor that takes a `basic_string` of the same character =
type. This constructor would adopt the `basic_string`'s memory, as though i=
t had moved the `basic_string` into an internal `basic_string` instance.<br=
><br>There would also be a `move_str` member function which returns a `basi=
c_string` by value (it can't be returned by `&amp;&amp;`), but it leaves th=
e `basic_stringstream` or `basic_istringstream` in the infamous "valid but =
undefined" state.<br><br>This would be part of a larger package of general =
changes with respect to iostreams, such as better integration (by which I m=
ean <i>some</i> integration) with `string_view` or whatever we're calling i=
t, improved allocator support for the `stringstreams` (they don't even take=
 allocator objects. People seemed to have completely forgotten about `strin=
gstream`s completely when they added stateful allocators), and a couple of =
other things.<br><br>So is there any interest in this?<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_903_23875862.1368202472483--

.

--001a11c2f5c43ebb9004dc5f8fb5
Content-Type: text/plain; charset=ISO-8859-1

On 10 May 2013 19:14, Nicol Bolas <jmckesson@gmail.com> wrote:

> On the old comp.std.c++ Usenet list, I made a suggestion about adding the
> ability to move `basic_string`s into and out-of `basic_stringstream`s<https://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ>.
> I'm considering making this an actual C++ proposal, so I wanted to gauge
> the interest in doing this.
>

Absolutely. It would decrease the need to use strstreams, too.

--

---
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/?hl=en.



--001a11c2f5c43ebb9004dc5f8fb5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 May 2013 19:14, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On the old comp.std.c++ Usenet list, I made =
a suggestion about <a href=3D"https://groups.google.com/forum/#!msg/comp.st=
d.c++/g79xQ6MX6rU/LRyBeqsIybEJ" target=3D"_blank">adding the ability to mov=
e `basic_string`s into and out-of `basic_stringstream`s</a>. I&#39;m consid=
ering making this an actual C++ proposal, so I wanted to gauge the interest=
 in doing this.<br>
</blockquote><div><br></div><div>Absolutely. It would decrease the need to =
use strstreams, too.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2f5c43ebb9004dc5f8fb5--

.

--90e6ba30931a8ea16204dc5fb015
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 10, 2013 at 6:14 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> So is there any interest in this?
>
> Totally! I have pined for this feature a few times before, and have at one
time considered writing my own stringbuf with similar functionality, but
never got to it.

--

---
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/?hl=en.



--90e6ba30931a8ea16204dc5fb015
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, May 10, 2013 at 6:14 PM, Nicol Bolas <span dir="ltr">&lt;<a href="mailto:jmckesson@gmail.com" target="_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So is there any interest in this?<span class="HOEnZb"><font color="#888888"><br>

<p></p>

</font></span></blockquote><div>Totally! I have pined for this feature a few times before, and have at one time considered writing my own stringbuf with similar functionality, but never got to it.<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--90e6ba30931a8ea16204dc5fb015--

.

--001a11c264143ca8e404dc68b065
Content-Type: text/plain; charset=ISO-8859-1

I'm wondering if a `.str() &&` overload is enough for our need.

--
Zhihao Yuan
On May 10, 2013 12:14 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

> On the old comp.std.c++ Usenet list, I made a suggestion about adding the
> ability to move `basic_string`s into and out-of `basic_stringstream`s<https://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ>.
> I'm considering making this an actual C++ proposal, so I wanted to gauge
> the interest in doing this.
>
> The general idea would be fairly simple, though it would have effects on
> the implementation of the stringstreams. In effect, they would *have* to
> be written to either internally use `basic_string` for their array of
> characters, or their implementations would have to be synchronized with
> `basic_string`, so that memory allocated between them could be transferred
> appropriately.
>
> The syntactic implication is quite simple. `basic_ostringstream` and
> `basic_stringstream` would have a constructor that takes a `basic_string`
> of the same character type. This constructor would adopt the
> `basic_string`'s memory, as though it had moved the `basic_string` into an
> internal `basic_string` instance.
>
> There would also be a `move_str` member function which returns a
> `basic_string` by value (it can't be returned by `&&`), but it leaves the
> `basic_stringstream` or `basic_istringstream` in the infamous "valid but
> undefined" state.
>
> This would be part of a larger package of general changes with respect to
> iostreams, such as better integration (by which I mean *some*integration) with `string_view` or whatever we're calling it, improved
> allocator support for the `stringstreams` (they don't even take allocator
> objects. People seemed to have completely forgotten about `stringstream`s
> completely when they added stateful allocators), and a couple of other
> things.
>
> So is there any interest in this?
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--001a11c264143ca8e404dc68b065
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>I&#39;m wondering if a `.str() &amp;&amp;` overload is enough for our ne=
ed.</p>
<p>--<br>
Zhihao Yuan</p>
<div class=3D"gmail_quote">On May 10, 2013 12:14 PM, &quot;Nicol Bolas&quot=
; &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wr=
ote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the old comp.std.c++ Usenet list, I made a suggestion about <a href=3D"h=
ttps://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ"=
 target=3D"_blank">adding the ability to move `basic_string`s into and out-=
of `basic_stringstream`s</a>. I&#39;m considering making this an actual C++=
 proposal, so I wanted to gauge the interest in doing this.<br>
<br>The general idea would be fairly simple, though it would have effects o=
n the implementation of the stringstreams. In effect, they would <i>have</i=
> to be written to either internally use `basic_string` for their array of =
characters, or their implementations would have to be synchronized with `ba=
sic_string`, so that memory allocated between them could be transferred app=
ropriately.<br>
<br>The syntactic implication is quite simple. `basic_ostringstream` and `b=
asic_stringstream` would have a constructor that takes a `basic_string` of =
the same character type. This constructor would adopt the `basic_string`&#3=
9;s memory, as though it had moved the `basic_string` into an internal `bas=
ic_string` instance.<br>
<br>There would also be a `move_str` member function which returns a `basic=
_string` by value (it can&#39;t be returned by `&amp;&amp;`), but it leaves=
 the `basic_stringstream` or `basic_istringstream` in the infamous &quot;va=
lid but undefined&quot; state.<br>
<br>This would be part of a larger package of general changes with respect =
to iostreams, such as better integration (by which I mean <i>some</i> integ=
ration) with `string_view` or whatever we&#39;re calling it, improved alloc=
ator support for the `stringstreams` (they don&#39;t even take allocator ob=
jects. People seemed to have completely forgotten about `stringstream`s com=
pletely when they added stateful allocators), and a couple of other things.=
<br>
<br>So is there any interest in this?<br>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c264143ca8e404dc68b065--

.

------=_Part_1259_9112387.1368243569609
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 10, 2013 8:14:58 PM UTC-7, Zhihao Yuan wrote:
>
> I'm wondering if a `.str() &&` overload is enough for our need.
>
How would you call that, exactly? Given some ostringstream, how do you move
from it? It would be wierd to do this:

ostringstream o;
//Fill o
std::move(o).str();

It just makes more sense to do:

o.move_str();

It's also more compact, and it's clear what's going on.

--

---
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/?hl=en.



------=_Part_1259_9112387.1368243569609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 10, 2013 8:14:58 PM UTC-7, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><p>I'm wondering if a `.str() &amp;&amp;` ove=
rload is enough for our need.</p></blockquote><div>How would you call that,=
 exactly? Given some ostringstream, how do you move from it? It would be wi=
erd to do this:<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">ostringstream o</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//Fill o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">move</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">o</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">).</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">str</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br>It just makes more sense=
 to do:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">move_str</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><br>It's also more compact, and it's clear what's going on.</div><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1259_9112387.1368243569609--

.

--089e013d16fc3e0d0304dc6b9d25
Content-Type: text/plain; charset=ISO-8859-1

Yea, it looks more length, but it's using an existing semantics, so that we
don't need to explain anything about the state of the stream after calling
move_str(); people already know std::move.

--
Zhihao Yuan
On May 10, 2013 11:39 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

> On Friday, May 10, 2013 8:14:58 PM UTC-7, Zhihao Yuan wrote:
>>
>> I'm wondering if a `.str() &&` overload is enough for our need.
>>
> How would you call that, exactly? Given some ostringstream, how do you
> move from it? It would be wierd to do this:
>
> ostringstream o;
> //Fill o
> std::move(o).str();
>
> It just makes more sense to do:
>
> o.move_str();
>
> It's also more compact, and it's clear what's going on.
>
>  --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e013d16fc3e0d0304dc6b9d25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Yea, it looks more length, but it&#39;s using an existing semantics, so =
that we don&#39;t need to explain anything about the state of the stream af=
ter calling move_str(); people already know std::move.</p>
<p>--<br>
Zhihao Yuan</p>
<div class=3D"gmail_quote">On May 10, 2013 11:39 PM, &quot;Nicol Bolas&quot=
; &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wr=
ote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Friday, May 10, 2013 8:14:58 PM UTC-7, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><p>I&#39;m wondering if a `.str() &amp;&amp;` over=
load is enough for our need.</p>
</blockquote><div>How would you call that, exactly? Given some ostringstrea=
m, how do you move from it? It would be wierd to do this:<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word">
<code><div><span style>ostringstream o</span><span style=3D"color:#660">;</=
span><span style><br></span><span style=3D"color:#800">//Fill o</span><span=
 style><br>std</span><span style=3D"color:#660">::</span><span style>move</=
span><span style=3D"color:#660">(</span><span style>o</span><span style=3D"=
color:#660">).</span><span style>str</span><span style=3D"color:#660">();</=
span><span style><br>
</span></div></code></div><br>It just makes more sense to do:<br><br><div s=
tyle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bor=
der-style:solid;border-width:1px;word-wrap:break-word"><code><div><span sty=
le>o</span><span style=3D"color:#660">.</span><span style>move_str</span><s=
pan style=3D"color:#660">();</span><span style><br>
</span></div></code></div><br>It&#39;s also more compact, and it&#39;s clea=
r what&#39;s going on.</div><br>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013d16fc3e0d0304dc6b9d25--

.

------=_Part_1628_3617967.1368293847363
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 10, 2013 11:44:24 PM UTC-7, Zhihao Yuan wrote:
>
> Yea, it looks more length, but it's using an existing semantics, so that
> we don't need to explain anything about the state of the stream after
> calling move_str(); people already know std::move.
>

.... So the sole reason to force people to use this tortured syntax rather
than a clear function call is solely to avoid having to *explain* what it
means in the standards text? It's called `*move*_str`; how hard could it
possibly be to understand?

It's a lot harder to explain to users why using `std::move` on the stream
followed by a call to `str` results in moving the string out of the stream
than it is explaining why `move_str` does that.

Furthermore, the semantics aren't correct and would generally be
surprising. Consider this:

std::string s("Here is a string that contains characters.");

std::string::iterator stuff = std::move(s).begin();

What are the contents of `s` after this code? The standard is very clear
what those contents are: the same contents as before. Nothing has been *
moved* from the string yet.

Whereas `std::move(o).str()` will *always* leave the stream in the
valid-but-unspecified state. That function will behave differently from
virtually any other expression of the form `std::move(x).function_call()`.

Unless you're suggesting that `str() &&` should return a `std::basic_string
&&`. In which case, you're forcing the implementation to implement
`basic_stringbuf` by using an internal `basic_string`. And I don't see any
reason why we need to enforce that.

--

---
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/?hl=en.



------=_Part_1628_3617967.1368293847363
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 10, 2013 11:44:24 PM UTC-7, Zhihao Yuan wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><p>Yea, it looks more length, but it's using=
 an existing semantics, so that we don't need to explain anything about the=
 state of the stream after calling move_str(); people already know std::mov=
e.</p></blockquote><div><br>... So the sole reason to force people to use t=
his tortured syntax rather than a clear function call is solely to avoid ha=
ving to <i>explain</i> what it means in the standards text? It's called `<b=
>move</b>_str`; how hard could it possibly be to understand?</div><br>It's =
a lot harder to explain to users why using `std::move` on the stream follow=
ed by a call to `str` results in moving the string out of the stream than i=
t is explaining why `move_str` does that.<br><br>Furthermore, the semantics=
 aren't correct and would generally be surprising. Consider this:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"Here is a string that contains characters."</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">iterator stuff </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">).</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></div></=
code></div><br>What are the contents of `s` after this code? The standard i=
s very clear what those contents are: the same contents as before. Nothing =
has been <i>moved</i> from the string yet.<br><br>Whereas `std::move(o).str=
()` will <i>always</i> leave the stream in the valid-but-unspecified state.=
 That function will behave differently from virtually any other expression =
of the form `std::move(x).function_call()`.<br><br>Unless you're suggesting=
 that `str() &amp;&amp;` should return a `std::basic_string &amp;&amp;`. In=
 which case, you're forcing the implementation to implement `basic_stringbu=
f` by using an internal `basic_string`. And I don't see any reason why we n=
eed to enforce that.<br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1628_3617967.1368293847363--

.

------=_Part_265_6044914.1368298628860
Content-Type: text/plain; charset=ISO-8859-1

Permitting easy move semantics to and from basic_stream is a good reason to
enforce it.

--

---
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/?hl=en.



------=_Part_265_6044914.1368298628860
Content-Type: text/html; charset=ISO-8859-1

Permitting easy move semantics to and from basic_stream is a good reason to enforce it.

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_265_6044914.1368298628860--

.

------=_Part_451_9246916.1368299251311
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>
> I'm wondering if a `.str() &&` overload is enough for our need.
>

The standard gives implementations quite a bit of freedom. Overloading=20
..str(string&&) is probably legal without changing the standard. Overloading=
=20
..str()&& (and replacing the existing .str() with .str()const&) might be=20
allowed as well.

That doesn't mean a more explicit syntax with stronger guarantees wouldn't=
=20
be welcome, but it is always good to be sure of where we are starting from.

--=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/?hl=3Den.



------=_Part_451_9246916.1368299251311
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit&nbsp;:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><p>I'm wondering if a `.str() &amp;&amp=
;` overload is enough for our need.</p></blockquote><div><br>The standard g=
ives implementations quite a bit of freedom. Overloading .str(string&amp;&a=
mp;) is probably legal without changing the standard. Overloading .str()&am=
p;&amp; (and replacing the existing .str() with .str()const&amp;) might be =
allowed as well.<br><br>That doesn't mean a more explicit syntax with stron=
ger guarantees wouldn't be welcome, but it is always good to be sure of whe=
re we are starting from.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_451_9246916.1368299251311--

.

--001a11c32932a4daa304dc761a6a
Content-Type: text/plain; charset=ISO-8859-1

On 11 May 2013 21:57, DeadMG <wolfeinstein@gmail.com> wrote:

> Permitting easy move semantics to and from basic_stream is a good reason
> to enforce it.
>
>
>
>
move(ss).str() doesn't seem to be on the same planet with "easy move
semantics", especially compared
to ss.move_str().

--

---
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/?hl=en.



--001a11c32932a4daa304dc761a6a
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 May 2013 21:57, DeadMG <span dir="ltr">&lt;<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Permitting easy move semantics to and from basic_stream is a good reason to enforce it.

<div class="HOEnZb"><div class="h5"><p></p>

<br><br></div></div></blockquote><div><br></div><div>move(ss).str() doesn&#39;t seem to be on the same planet with &quot;easy move semantics&quot;, especially compared<br>to ss.move_str(). <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c32932a4daa304dc761a6a--

.

------=_Part_250_30241231.1368299788764
Content-Type: text/plain; charset=ISO-8859-1

You're right, because when I do `f().str()`, then it works and seamlessly
upgrades existing code, and move_str unnecessarily duplicates this
functionality, forcing anyone who wants to use it to change all their code,
for absolutely no benefit whatsoever.

--

---
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/?hl=en.



------=_Part_250_30241231.1368299788764
Content-Type: text/html; charset=ISO-8859-1

You're right, because when I do `f().str()`, then it works and seamlessly upgrades existing code, and move_str unnecessarily duplicates this functionality, forcing anyone who wants to use it to change all their code, for absolutely no benefit whatsoever.

<p></p>

-- <br />
&nbsp;<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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_250_30241231.1368299788764--

.

--001a11c3311266db2104dc765bb9
Content-Type: text/plain; charset=ISO-8859-1

On 11 May 2013 22:16, DeadMG <wolfeinstein@gmail.com> wrote:

> You're right, because when I do `f().str()`, then it works and seamlessly
> upgrades existing code, and move_str unnecessarily duplicates this
> functionality, forcing anyone who wants to use it to change all their code,
> for absolutely no benefit whatsoever.
>
>
>
>
Mmkay. And then when users do x.str(), they will be utterly puzzled that
they actually have to std::move(x).str() to get what
they want. The benefit is readability. The rvalue-ref overload of str()
doesn't have it.

--

---
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/?hl=en.



--001a11c3311266db2104dc765bb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 May 2013 22:16, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">You&#39;re right, because when I do `f().str=
()`, then it works and seamlessly upgrades existing code, and move_str unne=
cessarily duplicates this functionality, forcing anyone who wants to use it=
 to change all their code, for absolutely no benefit whatsoever.

<div class=3D"HOEnZb"><div class=3D"h5"><p></p>

<br><br></div></div></blockquote><div><br></div><div>Mmkay. And then when u=
sers do x.str(), they will be utterly puzzled that they actually have to st=
d::move(x).str() to get what<br>they want. The benefit is readability. The =
rvalue-ref overload of str() doesn&#39;t have it. <br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c3311266db2104dc765bb9--

.

--089e01294802a328cb04dc76b2e2
Content-Type: text/plain; charset=ISO-8859-1

On 11 May 2013 22:33, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
>
>
> On 11 May 2013 22:16, DeadMG <wolfeinstein@gmail.com> wrote:
>
>> You're right, because when I do `f().str()`, then it works and seamlessly
>> upgrades existing code, and move_str unnecessarily duplicates this
>> functionality, forcing anyone who wants to use it to change all their code,
>> for absolutely no benefit whatsoever.
>>
>>
>>
>>
> Mmkay. And then when users do x.str(), they will be utterly puzzled that
> they actually have to std::move(x).str() to get what
> they want. The benefit is readability. The rvalue-ref overload of str()
> doesn't have it.
>
>

Well, to be fair, adding a stringstream(string&&) and
stringstream::str(string&&) would seem to be the first
order of business, those seem uncontroversial. Getting the benefit for
existing rvalues as you point out
would call for having stringstream::str() &&. Whether we additionally add
stringstream::move_str() is
a nice bonus, but not something that we desperately need. I can get over
the ugliness of the rvalue
str().

--

---
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/?hl=en.



--089e01294802a328cb04dc76b2e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 May 2013 22:33, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 11 May 2013 22:=
16, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailto:wolfeinstein@gmail.com" =
target=3D"_blank">wolfeinstein@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">You&#39;re right, because when I do `f().str=
()`, then it works and seamlessly upgrades existing code, and move_str unne=
cessarily duplicates this functionality, forcing anyone who wants to use it=
 to change all their code, for absolutely no benefit whatsoever.

<div><div><p></p>

<br><br></div></div></blockquote><div><br></div></div><div>Mmkay. And then =
when users do x.str(), they will be utterly puzzled that they actually have=
 to std::move(x).str() to get what<br>they want. The benefit is readability=
.. The rvalue-ref overload of str() doesn&#39;t have it. <br>

</div></div><br></div></div>
</blockquote></div><br><br></div><div class=3D"gmail_extra">Well, to be fai=
r, adding a stringstream(string&amp;&amp;) and stringstream::str(string&amp=
;&amp;) would seem to be the first<br></div><div class=3D"gmail_extra">orde=
r of business, those seem uncontroversial. Getting the benefit for existing=
 rvalues as you point out<br>
would call for having stringstream::str() &amp;&amp;. Whether we additional=
ly add stringstream::move_str() is<br></div><div class=3D"gmail_extra">a ni=
ce bonus, but not something that we desperately need. I can get over the ug=
liness of the rvalue<br>
str().<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01294802a328cb04dc76b2e2--

.

------=_Part_2013_9030578.1368329194127
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>
> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>
>> I'm wondering if a `.str() &&` overload is enough for our need.
>>
>
> The standard gives implementations quite a bit of freedom. Overloading=20
> .str(string&&) is probably legal without changing the standard. Overloadi=
ng=20
> .str()&& (and replacing the existing .str() with .str()const&) might be=
=20
> allowed as well.
>

I'm not sure what you mean by "without changing the standard". Could an=20
implementation add those overloads as an extension? Yes. But you can't *rel=
y
* on it "without changing the standard" to *require* that implementations=
=20
provide them.

Also, adding `.str() &&` would change apparent behavior as well, as it=20
would leave the stringstream in the moved-from state.

--=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/?hl=3Den.



------=_Part_2013_9030578.1368329194127
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yu=
an a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p>I'm wondering=
 if a `.str() &amp;&amp;` overload is enough for our need.</p></blockquote>=
<div><br>The standard gives implementations quite a bit of freedom. Overloa=
ding .str(string&amp;&amp;) is probably legal without changing the standard=
.. Overloading .str()&amp;&amp; (and replacing the existing .str() with .str=
()const&amp;) might be allowed as well.<br></div></blockquote><div><br>I'm =
not sure what you mean by "without changing the standard". Could an impleme=
ntation add those overloads as an extension? Yes. But you can't <i>rely</i>=
 on it "without changing the standard" to <i>require</i> that implementatio=
ns provide them.<br><br>Also, adding `.str() &amp;&amp;` would change appar=
ent behavior as well, as it would leave the stringstream in the moved-from =
state.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2013_9030578.1368329194127--

.

------=_Part_124_26565117.1368329775461
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 11, 2013 12:16:28 PM UTC-7, DeadMG wrote:
>
> You're right, because when I do `f().str()`, then it works and seamlessly
> upgrades existing code, and move_str unnecessarily duplicates this
> functionality, forcing anyone who wants to use it to change all their code,
> for absolutely no benefit whatsoever.


Even ignoring the useability issues that Ville and I have pointed out, how
often do you have functions that return `stringstream`s? The most common
use-case for `istringstream`s is something like this:

std::stringstream build;
build << /*stuff*/
std::string data = build.str();

Most of the time when you're working with a stringstream, you're working
with an lvalue, either passed around by non-const reference (in
`operator<<` overloads) or created on the stack as above.

So I would say that there is no "existing code" to "seamlessly update". Or
at least, there's not nearly enough to justify doing it this way. So the
vast majority of users are going to have to "change all their code" to use
it. At least with the given suggestion, what they'll change their code into
will make sense.

--

---
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/?hl=en.



------=_Part_124_26565117.1368329775461
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 11, 2013 12:16:28 PM UTC-7, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">You're right, because when I do `f().str()`, th=
en it works and seamlessly upgrades existing code, and move_str unnecessari=
ly duplicates this functionality, forcing anyone who wants to use it to cha=
nge all their code, for absolutely no benefit whatsoever.</blockquote><div>=
<br>Even ignoring the useability issues that Ville and I have pointed out, =
how often do you have functions that return `stringstream`s? The most commo=
n use-case for `istringstream`s is something like this:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">stringstream build</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>build </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">/*stuff*/</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">string</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> data </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> build</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">str</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><br>Most of the time when you're working with a stringstream, you're wo=
rking with an lvalue, either passed around by non-const reference (in `oper=
ator&lt;&lt;` overloads) or created on the stack as above.<br><br>So I woul=
d say that there is no "existing code" to "seamlessly update". Or at least,=
 there's not nearly enough to justify doing it this way. So the vast majori=
ty of users are going to have to "change all their code" to use it. At leas=
t with the given suggestion, what they'll change their code into will make =
sense.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_124_26565117.1368329775461--

.

------=_Part_60_25931441.1368347129455
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
>
> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>>
>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>>
>>> I'm wondering if a `.str() &&` overload is enough for our need.
>>>
>>
>> The standard gives implementations quite a bit of freedom. Overloading=
=20
>> .str(string&&) is probably legal without changing the standard. Overload=
ing=20
>> .str()&& (and replacing the existing .str() with .str()const&) might be=
=20
>> allowed as well.
>>
>
> I'm not sure what you mean by "without changing the standard". Could an=
=20
> implementation add those overloads as an extension?
>

Not "as an extension", as a valid implementation of the standard.
=20

> Yes. But you can't *rely* on it "without changing the standard" to *
> require* that implementations provide them.
>

QoI issue. If your library doesn't implement it, you can file a bug with=20
your vendor telling them that performance sucks. There are many places=20
where the library is allowed to make needless copies, and you can only rely=
=20
on the lack of copies through QoI.

Also, adding `.str() &&` would change apparent behavior as well, as it=20
> would leave the stringstream in the moved-from state.

=20
Yes, that's why I was asking if the generic text about rvalues and moving=
=20
in the standard library covers this case.

Again, I am not trying to prevent a more explicit syntax, which I think=20
would be welcome, I just think this should be clarified first, and then you=
=20
could in the rationale describe the difference between your new functions=
=20
and those (possibly just a nicer syntax and a stronger signal to=20
implementers, but maybe more differences).

--=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/?hl=3Den.



------=_Part_60_25931441.1368347129455
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit&nbsp;:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Saturday, May 11, 2013 12:07:31 PM=
 UTC-7, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le samedi 11 mai=
 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit&nbsp;:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><p>I'm wondering if a `.str() &amp;&amp;` overload is enough=
 for our need.</p></blockquote><div><br>The standard gives implementations =
quite a bit of freedom. Overloading .str(string&amp;&amp;) is probably lega=
l without changing the standard. Overloading .str()&amp;&amp; (and replacin=
g the existing .str() with .str()const&amp;) might be allowed as well.<br><=
/div></blockquote><div><br>I'm not sure what you mean by "without changing =
the standard". Could an implementation add those overloads as an extension?=
</div></blockquote><div><br>Not "as an extension", as a valid implementatio=
n of the standard.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"><div> Yes. But you can't <i>rely</i> on it "without chan=
ging the standard" to <i>require</i> that implementations provide them.<br>=
</div></blockquote><div><br>QoI issue. If your library doesn't implement it=
, you can file a bug with your vendor telling them that performance sucks. =
There are many places where the library is allowed to make needless copies,=
 and you can only rely on the lack of copies through QoI.<br><br><blockquot=
e style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;" class=3D"gmail_quote">Also, adding `.str() &amp;&=
amp;` would change apparent behavior as well, as it would leave the strings=
tream in the moved-from state.</blockquote><div>&nbsp;<br>Yes, that's why I=
 was asking if the generic text about rvalues and moving in the standard li=
brary covers this case.<br><br>Again, I am not trying to prevent a more exp=
licit syntax, which I think would be welcome, I just think this should be c=
larified first, and then you could in the rationale describe the difference=
 between your new functions and those (possibly just a nicer syntax and a s=
tronger signal to implementers, but maybe more differences).<br></div></div=
>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_60_25931441.1368347129455--

.

------=_Part_2098_15718148.1368351902973
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:
>
> Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
>>
>> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>>>
>>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>>>
>>>> I'm wondering if a `.str() &&` overload is enough for our need.
>>>>
>>>
>>> The standard gives implementations quite a bit of freedom. Overloading=
=20
>>> .str(string&&) is probably legal without changing the standard. Overloa=
ding=20
>>> .str()&& (and replacing the existing .str() with .str()const&) might be=
=20
>>> allowed as well.
>>>
>>
>> I'm not sure what you mean by "without changing the standard". Could an=
=20
>> implementation add those overloads as an extension?
>>
>
> Not "as an extension", as a valid implementation of the standard.
>

No, you can't. `str` is not allowed to affect the state of the stream in=20
any way. There's no viable way to move a string out of `str` that *doesn't*=
affect the stream. At least, not without making the "move" into a "copy",=
=20
which defeats the entire point of the optimization.

Also, adding `.str() &&` would change apparent behavior as well, as it=20
>> would leave the stringstream in the moved-from state.
>
> =20
> Yes, that's why I was asking if the generic text about rvalues and moving=
=20
> in the standard library covers this case.
>

No. And there never will be.

To allow such text would create *chaos*. It would mean that you have no=20
idea what the state of an object is in when you call it on something that=
=20
happens to bind to the `&&` version rather than the `&` version of the=20
function.

Movement is not something that can *ever* be implicit or accidental. It=20
must be explicitly stated by every function that attempts to move.

--=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/?hl=3Den.



------=_Part_2098_15718148.1368351902973
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas =
a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, May 11=
, 2013 12:07:31 PM UTC-7, Marc wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit&nbsp;:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><p>I'm wondering if a `.str() &amp;&amp;` =
overload is enough for our need.</p></blockquote><div><br>The standard give=
s implementations quite a bit of freedom. Overloading .str(string&amp;&amp;=
) is probably legal without changing the standard. Overloading .str()&amp;&=
amp; (and replacing the existing .str() with .str()const&amp;) might be all=
owed as well.<br></div></blockquote><div><br>I'm not sure what you mean by =
"without changing the standard". Could an implementation add those overload=
s as an extension?</div></blockquote><div><br>Not "as an extension", as a v=
alid implementation of the standard.</div></blockquote><div><br>No, you can=
't. `str` is not allowed to affect the state of the stream in any way. Ther=
e's no viable way to move a string out of `str` that <i>doesn't</i> affect =
the stream. At least, not without making the "move" into a "copy", which de=
feats the entire point of the optimization.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div><blockquote style=3D"margin:0pt 0pt 0pt 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail=
_quote">Also, adding `.str() &amp;&amp;` would change apparent behavior as =
well, as it would leave the stringstream in the moved-from state.</blockquo=
te><div>&nbsp;<br>Yes, that's why I was asking if the generic text about rv=
alues and moving in the standard library covers this case.<br></div></div><=
/blockquote><div><br>No. And there never will be.<br><br>To allow such text=
 would create <i>chaos</i>. It would mean that you have no idea what the st=
ate of an object is in when you call it on something that happens to bind t=
o the `&amp;&amp;` version rather than the `&amp;` version of the function.=
<br><br>Movement is not something that can <i>ever</i> be implicit or accid=
ental. It must be explicitly stated by every function that attempts to move=
..<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2098_15718148.1368351902973--

.

------=_Part_23_9645209.1368363524128
Content-Type: text/plain; charset=ISO-8859-1

On Friday, May 10, 2013 6:14:32 PM UTC+2, Nicol Bolas wrote:

> On the old comp.std.c++ Usenet list, I made a suggestion about adding the
> ability to move `basic_string`s into and out-of `basic_stringstream`s<https://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ>.
> I'm considering making this an actual C++ proposal, so I wanted to gauge
> the interest in doing this.
>
>
Interesting!
What about variants that take the buffer by reference and input/output
directly into the buffer, with buffer (views) being generic?

Isn't an implementation allowed to move a string into a stringstream
already?

--

---
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/?hl=en.



------=_Part_23_9645209.1368363524128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Friday, May 10, 2013 6:14:32 PM UTC+2, Nicol Bolas wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On the old comp.std.c++ Usenet list, I ma=
de a suggestion about <a href=3D"https://groups.google.com/forum/#!msg/comp=
..std.c++/g79xQ6MX6rU/LRyBeqsIybEJ" target=3D"_blank">adding the ability to =
move `basic_string`s into and out-of `basic_stringstream`s</a>. I'm conside=
ring making this an actual C++ proposal, so I wanted to gauge the interest =
in doing this.<br><br></blockquote><div><br></div><div>Interesting!</div><d=
iv>What about variants that take the buffer by reference and input/output d=
irectly into the buffer, with buffer (views) being generic?&nbsp;</div><div=
><br></div><div>Isn't an implementation allowed to move a string into a str=
ingstream already?</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_23_9645209.1368363524128--

.

------=_Part_47_28138705.1368364883517
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit :
>
> On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:
>>
>> Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
>>>
>>> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>>>>
>>>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>>>>
>>>>> I'm wondering if a `.str() &&` overload is enough for our need.
>>>>>
>>>>
>>>> The standard gives implementations quite a bit of freedom. Overloading=
=20
>>>> .str(string&&) is probably legal without changing the standard. Overlo=
ading=20
>>>> .str()&& (and replacing the existing .str() with .str()const&) might b=
e=20
>>>> allowed as well.
>>>>
>>>
>>> I'm not sure what you mean by "without changing the standard". Could an=
=20
>>> implementation add those overloads as an extension?
>>>
>>
>> Not "as an extension", as a valid implementation of the standard.
>>
>
> No, you can't. `str` is not allowed to affect the state of the stream in=
=20
> any way. There's no viable way to move a string out of `str` that *doesn'=
t
> * affect the stream. At least, not without making the "move" into a=20
> "copy", which defeats the entire point of the optimization.
>
> Also, adding `.str() &&` would change apparent behavior as well, as it=20
>>> would leave the stringstream in the moved-from state.
>>
>> =20
>> Yes, that's why I was asking if the generic text about rvalues and movin=
g=20
>> in the standard library covers this case.
>>
>
> No. And there never will be.
>
> To allow such text would create *chaos*. It would mean that you have no=
=20
> idea what the state of an object is in when you call it on something that=
=20
> happens to bind to the `&&` version rather than the `&` version of the=20
> function.
>
> Movement is not something that can *ever* be implicit or accidental. It=
=20
> must be explicitly stated by every function that attempts to move.
>
=20
Because movement is explicit (either you passed a temporary, or you passed=
=20
move(obj)), binding to && is not an accident, it is done on purpose, and=20
there is thus no way it creates chaos.

Note for instance 17.6.4.9:
"... If a program casts an lvalue to an
xvalue while passing that lvalue to a library function (e.g. by calling the=
=20
function with the argument
move(x)), the program is effectively asking that function to treat that=20
lvalue as a temporary. The
implementation is free to optimize away aliasing checks which might be=20
needed if the argument was
an lvalue."
which in conjonction with 17.6.5.15 and 17.6.5.5 could be read to imply=20
that we already have permission. Or not, that's not clear. But please stop=
=20
with the chaos nonsense.

--=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/?hl=3Den.



------=_Part_47_28138705.1368364883517
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit&nbsp;:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Sunday, May 12, 2013 1:25:29 AM UT=
C-7, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le dimanche 12 mai =
2013 05:26:34 UTC+2, Nicol Bolas a =E9crit&nbsp;:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Le samedi 11 mai 2013 05:14:58 UTC+2, Zh=
ihao Yuan a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p>I'm wo=
ndering if a `.str() &amp;&amp;` overload is enough for our need.</p></bloc=
kquote><div><br>The standard gives implementations quite a bit of freedom. =
Overloading .str(string&amp;&amp;) is probably legal without changing the s=
tandard. Overloading .str()&amp;&amp; (and replacing the existing .str() wi=
th .str()const&amp;) might be allowed as well.<br></div></blockquote><div><=
br>I'm not sure what you mean by "without changing the standard". Could an =
implementation add those overloads as an extension?</div></blockquote><div>=
<br>Not "as an extension", as a valid implementation of the standard.</div>=
</blockquote><div><br>No, you can't. `str` is not allowed to affect the sta=
te of the stream in any way. There's no viable way to move a string out of =
`str` that <i>doesn't</i> affect the stream. At least, not without making t=
he "move" into a "copy", which defeats the entire point of the optimization=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote sty=
le=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex" class=3D"gmail_quote">Also, adding `.str() &amp;&amp;` would c=
hange apparent behavior as well, as it would leave the stringstream in the =
moved-from state.</blockquote><div>&nbsp;<br>Yes, that's why I was asking i=
f the generic text about rvalues and moving in the standard library covers =
this case.<br></div></div></blockquote><div><br>No. And there never will be=
..<br><br>To allow such text would create <i>chaos</i>. It would mean that y=
ou have no idea what the state of an object is in when you call it on somet=
hing that happens to bind to the `&amp;&amp;` version rather than the `&amp=
;` version of the function.<br><br>Movement is not something that can <i>ev=
er</i> be implicit or accidental. It must be explicitly stated by every fun=
ction that attempts to move.<br></div></blockquote><div>&nbsp;<br>Because m=
ovement is explicit (either you passed a temporary, or you passed move(obj)=
), binding to &amp;&amp; is not an accident, it is done on purpose, and the=
re is thus no way it creates chaos.<br><br>Note for instance 17.6.4.9:<br>"=
.... If a program casts an lvalue to an<br>xvalue while passing that lvalue =
to a library function (e.g. by calling the function with the argument<br>mo=
ve(x)), the program is effectively asking that function to treat that lvalu=
e as a temporary. The<br>implementation is free to optimize away aliasing c=
hecks which might be needed if the argument was<br>an lvalue."<br>which in =
conjonction with 17.6.5.15 and 17.6.5.5 could be read to imply that we alre=
ady have permission. Or not, that's not clear. But please stop with the cha=
os nonsense.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_47_28138705.1368364883517--

.

------=_Part_2318_6129957.1368367225887
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 6:21:23 AM UTC-7, Marc wrote:
>
> Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit :
>>
>> On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:
>>>
>>> Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
>>>>
>>>> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>>>>>
>>>>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>>>>>
>>>>>> I'm wondering if a `.str() &&` overload is enough for our need.
>>>>>>
>>>>>
>>>>> The standard gives implementations quite a bit of freedom. Overloadin=
g=20
>>>>> .str(string&&) is probably legal without changing the standard. Overl=
oading=20
>>>>> .str()&& (and replacing the existing .str() with .str()const&) might =
be=20
>>>>> allowed as well.
>>>>>
>>>>
>>>> I'm not sure what you mean by "without changing the standard". Could a=
n=20
>>>> implementation add those overloads as an extension?
>>>>
>>>
>>> Not "as an extension", as a valid implementation of the standard.
>>>
>>
>> No, you can't. `str` is not allowed to affect the state of the stream in=
=20
>> any way. There's no viable way to move a string out of `str` that *
>> doesn't* affect the stream. At least, not without making the "move" into=
=20
>> a "copy", which defeats the entire point of the optimization.
>>
>> Also, adding `.str() &&` would change apparent behavior as well, as it=
=20
>>>> would leave the stringstream in the moved-from state.
>>>
>>> =20
>>> Yes, that's why I was asking if the generic text about rvalues and=20
>>> moving in the standard library covers this case.
>>>
>>
>> No. And there never will be.
>>
>> To allow such text would create *chaos*. It would mean that you have no=
=20
>> idea what the state of an object is in when you call it on something tha=
t=20
>> happens to bind to the `&&` version rather than the `&` version of the=
=20
>> function.
>>
>> Movement is not something that can *ever* be implicit or accidental. It=
=20
>> must be explicitly stated by every function that attempts to move.
>>
> =20
> Because movement is explicit (either you passed a temporary, or you passe=
d=20
> move(obj)), binding to && is not an accident, it is done on purpose, and=
=20
> there is thus no way it creates chaos.
>

It creates chaos because the standard is supposed to specify the state of=
=20
objects after each function.* Explicitly*. If a function does not say that=
=20
the state of the object is affected by the function, then the function *may=
=20
not* affect the state of that object.

Implementations cannot subvert this willy-nilly.
=20

> Note for instance 17.6.4.9:
> "... If a program casts an lvalue to an
> xvalue while passing that lvalue to a library function (e.g. by calling=
=20
> the function with the argument
> move(x)), the program is effectively asking that function to treat that=
=20
> lvalue as a temporary. The
> implementation is free to optimize away aliasing checks which might be=20
> needed if the argument was
> an lvalue."
>

None of that is the actual, *normative* text. The normative text, the text=
=20
that actually matters, is:

If a function argument binds to an rvalue reference parameter, the=20
> implementation may assume that
> this parameter is a unique reference to this argument.
>

The terms "argument" and "parameter" are very well defined by the standard.=
=20
"Argument" is the expression you use in the function call; it is what you=
=20
pass in. "Parameter" is the field in the function declaration/definition=20
which the argument is bound to.

I honestly do not know if the standard says that `x.func_name` considers=20
`x` to be an "argument" to the member function `func_name`. But let's=20
assume that it does (because if it doesn't, then this section clearly=20
doesn't apply).

`std::basic_stringstream::str` does *not* take `this` as an "rvalue=20
reference parameter". Therefore, any implementation that *did* split the=20
function between `&` and `&&` versions and did indeed move the string out=
=20
of the object would be in *violation* of the standard. The function as=20
defined in the standard does not take its this parameter by rvalue=20
reference, and therefore the function as defined by the standard cannot=20
move from the stream.

The standard is very clear: `std::move(os).str()` shall be equivalent to=20
`os.str()`. The state of `os` in both cases must be preserved.

Oh, and `std::basic_stringstream::str` is *const* (the one that returns a=
=20
value). I probably should have noticed that much earlier.

--=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/?hl=3Den.



------=_Part_2318_6129957.1368367225887
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 6:21:23 AM UTC-7, Marc wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas =
a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Sunday, May 12, =
2013 1:25:29 AM UTC-7, Marc wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit&nbsp;:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">On Saturday, May 11, 2013 12:07:31 PM UTC=
-7, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le samedi 11 mai 201=
3 05:14:58 UTC+2, Zhihao Yuan a =E9crit&nbsp;:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><p>I'm wondering if a `.str() &amp;&amp;` overload is enough for=
 our need.</p></blockquote><div><br>The standard gives implementations quit=
e a bit of freedom. Overloading .str(string&amp;&amp;) is probably legal wi=
thout changing the standard. Overloading .str()&amp;&amp; (and replacing th=
e existing .str() with .str()const&amp;) might be allowed as well.<br></div=
></blockquote><div><br>I'm not sure what you mean by "without changing the =
standard". Could an implementation add those overloads as an extension?</di=
v></blockquote><div><br>Not "as an extension", as a valid implementation of=
 the standard.</div></blockquote><div><br>No, you can't. `str` is not allow=
ed to affect the state of the stream in any way. There's no viable way to m=
ove a string out of `str` that <i>doesn't</i> affect the stream. At least, =
not without making the "move" into a "copy", which defeats the entire point=
 of the optimization.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div><blockquote style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Also, adding `.str(=
) &amp;&amp;` would change apparent behavior as well, as it would leave the=
 stringstream in the moved-from state.</blockquote><div>&nbsp;<br>Yes, that=
's why I was asking if the generic text about rvalues and moving in the sta=
ndard library covers this case.<br></div></div></blockquote><div><br>No. An=
d there never will be.<br><br>To allow such text would create <i>chaos</i>.=
 It would mean that you have no idea what the state of an object is in when=
 you call it on something that happens to bind to the `&amp;&amp;` version =
rather than the `&amp;` version of the function.<br><br>Movement is not som=
ething that can <i>ever</i> be implicit or accidental. It must be explicitl=
y stated by every function that attempts to move.<br></div></blockquote><di=
v>&nbsp;<br>Because movement is explicit (either you passed a temporary, or=
 you passed move(obj)), binding to &amp;&amp; is not an accident, it is don=
e on purpose, and there is thus no way it creates chaos.<br></div></blockqu=
ote><div><br>It creates chaos because the standard is supposed to specify t=
he state of objects after each function.<i> Explicitly</i>. If a function d=
oes not say that the state of the object is affected by the function, then =
the function <i>may not</i> affect the state of that object.<br><br>Impleme=
ntations cannot subvert this willy-nilly.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>Note for instance <a href=3D"http://17.6.4=
..9" target=3D"_blank">17.6.4.9</a>:<br>"... If a program casts an lvalue to=
 an<br>xvalue while passing that lvalue to a library function (e.g. by call=
ing the function with the argument<br>move(x)), the program is effectively =
asking that function to treat that lvalue as a temporary. The<br>implementa=
tion is free to optimize away aliasing checks which might be needed if the =
argument was<br>an lvalue."<br></div></blockquote><div><br>None of that is =
the actual, <i>normative</i> text. The normative text, the text that actual=
ly matters, is:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote">If a function argument binds to an rvalue reference parameter, the im=
plementation may assume that<br>this parameter is a unique reference to thi=
s argument.<br></blockquote><div><br>The terms "argument" and "parameter" a=
re very well defined by the standard. "Argument" is the expression you use =
in the function call; it is what you pass in. "Parameter" is the field in t=
he function declaration/definition which the argument is bound to.<br><br>I=
 honestly do not know if the standard says that `x.func_name` considers `x`=
 to be an "argument" to the member function `func_name`. But let's assume t=
hat it does (because if it doesn't, then this section clearly doesn't apply=
).<br><br>`std::basic_stringstream::str` does <i>not</i> take `this` as an =
"rvalue reference parameter". Therefore, any implementation that <i>did</i>=
 split the function between `&amp;` and `&amp;&amp;` versions and did indee=
d move the string out of the object would be in <i>violation</i> of the sta=
ndard. The function as defined in the standard does not take its this param=
eter by rvalue reference, and therefore the function as defined by the stan=
dard cannot move from the stream.<br><br>The standard is very clear: `std::=
move(os).str()` shall be equivalent to `os.str()`. The state of `os` in bot=
h cases must be preserved.<br><br>Oh, and `std::basic_stringstream::str` is=
 <i><b>const</b></i> (the one that returns a value). I probably should have=
 noticed that much earlier.<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2318_6129957.1368367225887--

.

------=_Part_2124_18704486.1368367345450
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, May 12, 2013 5:58:44 AM UTC-7, Olaf van der Spek wrote:
>
> On Friday, May 10, 2013 6:14:32 PM UTC+2, Nicol Bolas wrote:
>
>> On the old comp.std.c++ Usenet list, I made a suggestion about adding
>> the ability to move `basic_string`s into and out-of `basic_stringstream`s<https://groups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ>.
>> I'm considering making this an actual C++ proposal, so I wanted to gauge
>> the interest in doing this.
>>
>>
> Interesting!
> What about variants that take the buffer by reference and input/output
> directly into the buffer, with buffer (views) being generic?
>

Now you're talking about a whole new kind of `stringstream` class. It would
be much easier to just expand the interface to give you control over the
stream equivalent to a `basic_string` than to create a whole new stream
class.

Isn't an implementation allowed to move a string into a stringstream
> already?
>

Both the constructor and `str` take the `basic_string` by `const&`. So no
moving.

--

---
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/?hl=en.



------=_Part_2124_18704486.1368367345450
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 5:58:44 AM UTC-7, Olaf van der Spek wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">On Friday, May 10, 2013 6:14:32 PM UTC+=
2, Nicol Bolas wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On the old=
 comp.std.c++ Usenet list, I made a suggestion about <a href=3D"https://gro=
ups.google.com/forum/#!msg/comp.std.c++/g79xQ6MX6rU/LRyBeqsIybEJ" target=3D=
"_blank">adding the ability to move `basic_string`s into and out-of `basic_=
stringstream`s</a>. I'm considering making this an actual C++ proposal, so =
I wanted to gauge the interest in doing this.<br><br></blockquote><div><br>=
</div><div>Interesting!</div><div>What about variants that take the buffer =
by reference and input/output directly into the buffer, with buffer (views)=
 being generic?</div></blockquote><div><br>Now you're talking about a whole=
 new kind of `stringstream` class. It would be much easier to just expand t=
he interface to give you control over the stream equivalent to a `basic_str=
ing` than to create a whole new stream class.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div>Isn't an implementation allowed to move a=
 string into a stringstream already?</div></blockquote><div><br>Both the co=
nstructor and `str` take the `basic_string` by `const&amp;`. So no moving. =
<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2124_18704486.1368367345450--

.

--047d7bdc0ababaebfd04dc86966b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On May 12, 2013 6:21 AM, "Marc" <marc.glisse@gmail.com> wrote:
>
> Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit :
>>
>> On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:
>>>
>>> Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
>>>>
>>>> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
>>>>>
>>>>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
>>>>>>
>>>>>> I'm wondering if a `.str() &&` overload is enough for our need.
>>>>>
>>>>>
>>>>> The standard gives implementations quite a bit of freedom.
Overloading .str(string&&) is probably legal without changing the standard.
Overloading .str()&& (and replacing the existing .str() with .str()const&)
might be allowed as well.
>>>>
>>>>
>>>> I'm not sure what you mean by "without changing the standard". Could
an implementation add those overloads as an extension?
>>>
>>>
>>> Not "as an extension", as a valid implementation of the standard.
>>
>>
>> No, you can't. `str` is not allowed to affect the state of the stream in
any way. There's no viable way to move a string out of `str` that doesn't
affect the stream. At least, not without making the "move" into a "copy",
which defeats the entire point of the optimization.
>>
>>>> Also, adding `.str() &&` would change apparent behavior as well, as it
would leave the stringstream in the moved-from state.
>>>
>>>
>>> Yes, that's why I was asking if the generic text about rvalues and
moving in the standard library covers this case.
>>
>>
>> No. And there never will be.
>>
>> To allow such text would create chaos. It would mean that you have no
idea what the state of an object is in when you call it on something that
happens to bind to the `&&` version rather than the `&` version of the
function.
>>
>> Movement is not something that can ever be implicit or accidental. It
must be explicitly stated by every function that attempts to move.
>
>
> Because movement is explicit (either you passed a temporary, or you
passed move(obj)), binding to && is not an accident, it is done on purpose,
and there is thus no way it creates chaos.
>
> Note for instance 17.6.4.9:
> "... If a program casts an lvalue to an
> xvalue while passing that lvalue to a library function (e.g. by calling
the function with the argument
> move(x)), the program is effectively asking that function to treat that
lvalue as a temporary. The
> implementation is free to optimize away aliasing checks which might be
needed if the argument was
> an lvalue."
> which in conjonction with 17.6.5.15 and 17.6.5.5 could be read to imply
that we already have permission. Or not, that's not clear. But please stop
with the chaos nonsense.
>

I, for one, would welcome normative text saying that if you pass an rvalue
reference to any library function, the value upon return from that function
is unspecified. I don't expect to have time to write the paper, but it
would be great to get it for C++17.

Jeffrey

--=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/?hl=3Den.



--047d7bdc0ababaebfd04dc86966b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On May 12, 2013 6:21 AM, &quot;Marc&quot; &lt;<a href=3D"mai=
lto:marc.glisse@gmail.com">marc.glisse@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit=A0:<br>
&gt;&gt;<br>
&gt;&gt; On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit=
=A0:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:<b=
r>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =
=E9crit=A0:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;m wondering if a `.str() &amp;&amp;` overloa=
d is enough for our need.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; The standard gives implementations quite a bit of free=
dom. Overloading .str(string&amp;&amp;) is probably legal without changing =
the standard. Overloading .str()&amp;&amp; (and replacing the existing .str=
() with .str()const&amp;) might be allowed as well.<br>

&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m not sure what you mean by &quot;without changing t=
he standard&quot;. Could an implementation add those overloads as an extens=
ion?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Not &quot;as an extension&quot;, as a valid implementation of =
the standard.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; No, you can&#39;t. `str` is not allowed to affect the state of the=
 stream in any way. There&#39;s no viable way to move a string out of `str`=
 that doesn&#39;t affect the stream. At least, not without making the &quot=
;move&quot; into a &quot;copy&quot;, which defeats the entire point of the =
optimization.<br>

&gt;&gt;<br>
&gt;&gt;&gt;&gt; Also, adding `.str() &amp;&amp;` would change apparent beh=
avior as well, as it would leave the stringstream in the moved-from state.<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0<br>
&gt;&gt;&gt; Yes, that&#39;s why I was asking if the generic text about rva=
lues and moving in the standard library covers this case.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; No. And there never will be.<br>
&gt;&gt;<br>
&gt;&gt; To allow such text would create chaos. It would mean that you have=
 no idea what the state of an object is in when you call it on something th=
at happens to bind to the `&amp;&amp;` version rather than the `&amp;` vers=
ion of the function.<br>

&gt;&gt;<br>
&gt;&gt; Movement is not something that can ever be implicit or accidental.=
 It must be explicitly stated by every function that attempts to move.<br>
&gt;<br>
&gt; =A0<br>
&gt; Because movement is explicit (either you passed a temporary, or you pa=
ssed move(obj)), binding to &amp;&amp; is not an accident, it is done on pu=
rpose, and there is thus no way it creates chaos.<br>
&gt;<br>
&gt; Note for instance <a href=3D"http://17.6.4.9">17.6.4.9</a>:<br>
&gt; &quot;... If a program casts an lvalue to an<br>
&gt; xvalue while passing that lvalue to a library function (e.g. by callin=
g the function with the argument<br>
&gt; move(x)), the program is effectively asking that function to treat tha=
t lvalue as a temporary. The<br>
&gt; implementation is free to optimize away aliasing checks which might be=
 needed if the argument was<br>
&gt; an lvalue.&quot;<br>
&gt; which in conjonction with 17.6.5.15 and 17.6.5.5 could be read to impl=
y that we already have permission. Or not, that&#39;s not clear. But please=
 stop with the chaos nonsense.<br>
&gt;</p>
<p dir=3D"ltr">I, for one, would welcome normative text saying that if you =
pass an rvalue reference to any library function, the value upon return fro=
m that function is unspecified. I don&#39;t expect to have time to write th=
e paper, but it would be great to get it for C++17.</p>

<p dir=3D"ltr">Jeffrey</p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bdc0ababaebfd04dc86966b--

.

On Sun, May 12, 2013 at 10:00 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> `std::basic_stringstream::str` does not take `this` as an "rvalue reference
> parameter".

But it's our job to make it work, right?

Before

  std::string str() const

After

  std::string str() &&
  std::string str() const&

I can't see the problem...

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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/?hl=en.



.

------=_Part_2170_10837141.1368375057162
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, May 12, 2013 8:18:43 AM UTC-7, Zhihao Yuan wrote:
>
> On Sun, May 12, 2013 at 10:00 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > `std::basic_stringstream::str` does not take `this` as an "rvalue
> reference
> > parameter".
>
> But it's our job to make it work, right?
>
> Before
>
>   std::string str() const
>
> After
>
>   std::string str() &&
>   std::string str() const&
>
> I can't see the problem...
>

This part of the discussion was mainly about whether an implementation
could back-door the functionality as an implementation detail. The answer
being, "no it can't."

As for why we shouldn't do it, there are many reasons. It's not backwards
compatible; it potentially breaks any code that was already of the form
`std::move(os).str()`. Admittedly, that's not a huge concern, but it's
still backwards incompatible needlessly. It also breaks the stringstream's
ABI by creating two different functions with two different definitions when
there used to be one.

Then there's the other reasons mentioned above, like not forcing the
tortured `std::move(os).str()` syntax instead of the much more readable
`os.move_str()` syntax?

--

---
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/?hl=en.



------=_Part_2170_10837141.1368375057162
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 8:18:43 AM UTC-7, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On Sun, May 12, 2013 at 10:00 AM, Nicol Bolas=
 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Dbb=
J78QsbOcJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; `std::basic_stringstream::str` does not take `this` as an "rvalue =
reference
<br>&gt; parameter".
<br>
<br>But it's our job to make it work, right?
<br>
<br>Before
<br>
<br>&nbsp; std::string str() const
<br>
<br>After
<br>
<br>&nbsp; std::string str() &amp;&amp;
<br>&nbsp; std::string str() const&amp;
<br>
<br>I can't see the problem...<br></blockquote><div><br>This part of the di=
scussion was mainly about whether an implementation could back-door the fun=
ctionality as an implementation detail. The answer being, "no it can't."<br=
><br>As for why we shouldn't do it, there are many reasons. It's not backwa=
rds compatible; it potentially breaks any code that was already of the form=
 `std::move(os).str()`. Admittedly, that's not a huge concern, but it's sti=
ll backwards incompatible needlessly. It also breaks the stringstream's ABI=
 by creating two different functions with two different definitions when th=
ere used to be one.<br><br>Then there's the other reasons mentioned above, =
like not forcing the tortured `std::move(os).str()` syntax instead of the m=
uch more readable `os.move_str()` syntax?<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2170_10837141.1368375057162--

.

------=_Part_2371_27037917.1368375229824
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 7:55:19 AM UTC-7, Jeffrey Yasskin wrote:
>
> On May 12, 2013 6:21 AM, "Marc" <marc....@gmail.com <javascript:>> wrote:
> >
> > Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit :
> >>
> >> On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:
> >>>
> >>> Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit :
> >>>>
> >>>> On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:
> >>>>>
> >>>>> Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =E9crit :
> >>>>>>
> >>>>>> I'm wondering if a `.str() &&` overload is enough for our need.
> >>>>>
> >>>>>
> >>>>> The standard gives implementations quite a bit of freedom.=20
> Overloading .str(string&&) is probably legal without changing the standar=
d.=20
> Overloading .str()&& (and replacing the existing .str() with .str()const&=
)=20
> might be allowed as well.
> >>>>
> >>>>
> >>>> I'm not sure what you mean by "without changing the standard". Could=
=20
> an implementation add those overloads as an extension?
> >>>
> >>>
> >>> Not "as an extension", as a valid implementation of the standard.
> >>
> >>
> >> No, you can't. `str` is not allowed to affect the state of the stream=
=20
> in any way. There's no viable way to move a string out of `str` that=20
> doesn't affect the stream. At least, not without making the "move" into a=
=20
> "copy", which defeats the entire point of the optimization.
> >>
> >>>> Also, adding `.str() &&` would change apparent behavior as well, as=
=20
> it would leave the stringstream in the moved-from state.
> >>>
> >>> =20
> >>> Yes, that's why I was asking if the generic text about rvalues and=20
> moving in the standard library covers this case.
> >>
> >>
> >> No. And there never will be.
> >>
> >> To allow such text would create chaos. It would mean that you have no=
=20
> idea what the state of an object is in when you call it on something that=
=20
> happens to bind to the `&&` version rather than the `&` version of the=20
> function.
> >>
> >> Movement is not something that can ever be implicit or accidental. It=
=20
> must be explicitly stated by every function that attempts to move.
> >
> > =20
> > Because movement is explicit (either you passed a temporary, or you=20
> passed move(obj)), binding to && is not an accident, it is done on purpos=
e,=20
> and there is thus no way it creates chaos.
> >
> > Note for instance 17.6.4.9:
> > "... If a program casts an lvalue to an
> > xvalue while passing that lvalue to a library function (e.g. by calling=
=20
> the function with the argument
> > move(x)), the program is effectively asking that function to treat that=
=20
> lvalue as a temporary. The
> > implementation is free to optimize away aliasing checks which might be=
=20
> needed if the argument was
> > an lvalue."
> > which in conjonction with 17.6.5.15 and 17.6.5.5 could be read to imply=
=20
> that we already have permission. Or not, that's not clear. But please sto=
p=20
> with the chaos nonsense.
> >
>
> I, for one, would welcome normative text saying that if you pass an rvalu=
e=20
> reference to any library function, the value upon return from that functi=
on=20
> is unspecified. I don't expect to have time to write the paper, but it=20
> would be great to get it for C++17.
>

That's a terrible idea. We want movement to be something that is *specified=
*by the standard, not a random thing that might happen. Not something that=
=20
some implementations could or could not do.

The actual move itself is ultimately implementation-defined. The specific=
=20
details of the move are implementation-defined. But *when* a move is=20
permitted (and therefore when it is not) should *always* be defined by the=
=20
parameters a function is defined with. Not by how the user calls it.

The possibility of movement should be a function of the *API*, not how the=
=20
API is implemented.

--=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/?hl=3Den.



------=_Part_2371_27037917.1368375229824
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, May 12, 2013 7:55:19 AM UTC-7, Jeffrey Yasskin wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">On May 12, 2013 6:21 AM, "=
Marc" &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"wlrTde9cBDcJ">marc....@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Le dimanche 12 mai 2013 11:45:02 UTC+2, Nicol Bolas a =E9crit&nbsp;:<b=
r>
&gt;&gt;<br>
&gt;&gt; On Sunday, May 12, 2013 1:25:29 AM UTC-7, Marc wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Le dimanche 12 mai 2013 05:26:34 UTC+2, Nicol Bolas a =E9crit&=
nbsp;:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Saturday, May 11, 2013 12:07:31 PM UTC-7, Marc wrote:<b=
r>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Le samedi 11 mai 2013 05:14:58 UTC+2, Zhihao Yuan a =
=E9crit&nbsp;:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I'm wondering if a `.str() &amp;&amp;` overload is=
 enough for our need.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; The standard gives implementations quite a bit of free=
dom. Overloading .str(string&amp;&amp;) is probably legal without changing =
the standard. Overloading .str()&amp;&amp; (and replacing the existing .str=
() with .str()const&amp;) might be allowed as well.<br>

&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I'm not sure what you mean by "without changing the standa=
rd". Could an implementation add those overloads as an extension?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Not "as an extension", as a valid implementation of the standa=
rd.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; No, you can't. `str` is not allowed to affect the state of the str=
eam in any way. There's no viable way to move a string out of `str` that do=
esn't affect the stream. At least, not without making the "move" into a "co=
py", which defeats the entire point of the optimization.<br>

&gt;&gt;<br>
&gt;&gt;&gt;&gt; Also, adding `.str() &amp;&amp;` would change apparent beh=
avior as well, as it would leave the stringstream in the moved-from state.<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &nbsp;<br>
&gt;&gt;&gt; Yes, that's why I was asking if the generic text about rvalues=
 and moving in the standard library covers this case.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; No. And there never will be.<br>
&gt;&gt;<br>
&gt;&gt; To allow such text would create chaos. It would mean that you have=
 no idea what the state of an object is in when you call it on something th=
at happens to bind to the `&amp;&amp;` version rather than the `&amp;` vers=
ion of the function.<br>

&gt;&gt;<br>
&gt;&gt; Movement is not something that can ever be implicit or accidental.=
 It must be explicitly stated by every function that attempts to move.<br>
&gt;<br>
&gt; &nbsp;<br>
&gt; Because movement is explicit (either you passed a temporary, or you pa=
ssed move(obj)), binding to &amp;&amp; is not an accident, it is done on pu=
rpose, and there is thus no way it creates chaos.<br>
&gt;<br>
&gt; Note for instance <a href=3D"http://17.6.4.9" target=3D"_blank">17.6.4=
..9</a>:<br>
&gt; "... If a program casts an lvalue to an<br>
&gt; xvalue while passing that lvalue to a library function (e.g. by callin=
g the function with the argument<br>
&gt; move(x)), the program is effectively asking that function to treat tha=
t lvalue as a temporary. The<br>
&gt; implementation is free to optimize away aliasing checks which might be=
 needed if the argument was<br>
&gt; an lvalue."<br>
&gt; which in conjonction with 17.6.5.15 and 17.6.5.5 could be read to impl=
y that we already have permission. Or not, that's not clear. But please sto=
p with the chaos nonsense.<br>
&gt;</p>
<p dir=3D"ltr">I, for one, would welcome normative text saying that if you =
pass an rvalue reference to any library function, the value upon return fro=
m that function is unspecified. I don't expect to have time to write the pa=
per, but it would be great to get it for C++17.</p></blockquote><div><br>Th=
at's a terrible idea. We want movement to be something that is <i>specified=
</i> by the standard, not a random thing that might happen. Not something t=
hat some implementations could or could not do.<br><br>The actual move itse=
lf is ultimately implementation-defined. The specific details of the move a=
re implementation-defined. But <i>when</i> a move is permitted (and therefo=
re when it is not) should <i>always</i> be defined by the parameters a func=
tion is defined with. Not by how the user calls it.<br><br>The possibility =
of movement should be a function of the <i>API</i>, not how the API is impl=
emented.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2371_27037917.1368375229824--

.

--089e0112bfd0b101b504dc87dfce
Content-Type: text/plain; charset=ISO-8859-1

I see.  I had no ABI compatibility concern in mind and this problem only
occurs when an explicit call to std::move was used.  Anyway, you are right.

And the next question is, does it worth to break a (almost) non-existing
practice? Does it worth to add one member function semantically as  same as
std::move to workaround the problem? In what way the APIs in the future can
benefit from the choices people currently make?

--
Zhihao Yuan
On May 12, 2013 10:11 AM, "Nicol Bolas" <jmckesson@gmail.com> wrote:

> On Sunday, May 12, 2013 8:18:43 AM UTC-7, Zhihao Yuan wrote:
>>
>> On Sun, May 12, 2013 at 10:00 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > `std::basic_stringstream::str` does not take `this` as an "rvalue
>> reference
>> > parameter".
>>
>> But it's our job to make it work, right?
>>
>> Before
>>
>>   std::string str() const
>>
>> After
>>
>>   std::string str() &&
>>   std::string str() const&
>>
>> I can't see the problem...
>>
>
> This part of the discussion was mainly about whether an implementation
> could back-door the functionality as an implementation detail. The answer
> being, "no it can't."
>
> As for why we shouldn't do it, there are many reasons. It's not backwards
> compatible; it potentially breaks any code that was already of the form
> `std::move(os).str()`. Admittedly, that's not a huge concern, but it's
> still backwards incompatible needlessly. It also breaks the stringstream's
> ABI by creating two different functions with two different definitions when
> there used to be one.
>
> Then there's the other reasons mentioned above, like not forcing the
> tortured `std::move(os).str()` syntax instead of the much more readable
> `os.move_str()` syntax?
>
> --
>
> ---
> 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/?hl=en.
>
>
>

--

---
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/?hl=en.



--089e0112bfd0b101b504dc87dfce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>I see.=A0 I had no ABI compatibility concern in mind and this problem on=
ly occurs when an explicit call to std::move was used.=A0 Anyway, you are r=
ight.</p>
<p>And the next question is, does it worth to break a (almost) non-existing=
 practice? Does it worth to add one member function semantically as=A0 same=
 as std::move to workaround the problem? In what way the APIs in the future=
 can benefit from the choices people currently make?</p>

<p>--<br>
Zhihao Yuan</p>
<div class=3D"gmail_quote">On May 12, 2013 10:11 AM, &quot;Nicol Bolas&quot=
; &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wr=
ote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sunday, May 12, 2013 8:18:43 AM UTC-7, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">On Sun, May 12, 2013 at 10:00 AM, Nicol Bolas &lt;=
<a>jmck...@gmail.com</a>&gt; wrote:
<br>&gt; `std::basic_stringstream::str` does not take `this` as an &quot;rv=
alue reference
<br>&gt; parameter&quot;.
<br>
<br>But it&#39;s our job to make it work, right?
<br>
<br>Before
<br>
<br>=A0 std::string str() const
<br>
<br>After
<br>
<br>=A0 std::string str() &amp;&amp;
<br>=A0 std::string str() const&amp;
<br>
<br>I can&#39;t see the problem...<br></blockquote><div><br>This part of th=
e discussion was mainly about whether an implementation could back-door the=
 functionality as an implementation detail. The answer being, &quot;no it c=
an&#39;t.&quot;<br>
<br>As for why we shouldn&#39;t do it, there are many reasons. It&#39;s not=
 backwards compatible; it potentially breaks any code that was already of t=
he form `std::move(os).str()`. Admittedly, that&#39;s not a huge concern, b=
ut it&#39;s still backwards incompatible needlessly. It also breaks the str=
ingstream&#39;s ABI by creating two different functions with two different =
definitions when there used to be one.<br>
<br>Then there&#39;s the other reasons mentioned above, like not forcing th=
e tortured `std::move(os).str()` syntax instead of the much more readable `=
os.move_str()` syntax?<br></div>

<p></p>

-- <br>
=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0112bfd0b101b504dc87dfce--

.

--001a11c2ab988116ca04dc882bfc
Content-Type: text/plain; charset=ISO-8859-1

On 12 May 2013 19:27, Zhihao Yuan <lichray@gmail.com> wrote:

> I see.  I had no ABI compatibility concern in mind and this problem only
> occurs when an explicit call to std::move was used.  Anyway, you are right.
>
> And the next question is, does it worth to break a (almost) non-existing
> practice? Does it worth to add one member function semantically as  same as
> std::move to workaround the problem? In what way the APIs in the future can
> benefit from the choices people currently make?
>
>
>
> future::share is an existing example of a member function that's not
strictly necessary to have, since
it would be possible to write its bare-bones counterpart,
shared_future<T>(move(future)).

For the other distractions, I don't think we should rely on QoI of
libraries to add the rvalue reference
overloads.

--

---
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/?hl=en.



--001a11c2ab988116ca04dc882bfc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 May 2013 19:27, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"=
mailto:lichray@gmail.com" target=3D"_blank">lichray@gmail.com</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p>I see.=A0 I had no ABI compatibility conc=
ern in mind and this problem only occurs when an explicit call to std::move=
 was used.=A0 Anyway, you are right.</p>

<p>And the next question is, does it worth to break a (almost) non-existing=
 practice? Does it worth to add one member function semantically as=A0 same=
 as std::move to workaround the problem? In what way the APIs in the future=
 can benefit from the choices people currently make?</p>


<p><br></p><p><br></p></blockquote><div>future::share is an existing exampl=
e of a member function that&#39;s not strictly necessary to have, since<br>=
</div><div>it would be possible to write its bare-bones counterpart, shared=
_future&lt;T&gt;(move(future)).<br>
<br></div><div>For the other distractions, I don&#39;t think we should rely=
 on QoI of libraries to add the rvalue reference<br>overloads.<br></div></d=
iv><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c2ab988116ca04dc882bfc--

.

------=_Part_3209_5754161.1368382929768
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 16:00:25 UTC+2, Nicol Bolas a =E9crit :
>
> On Sunday, May 12, 2013 6:21:23 AM UTC-7, Marc wrote:
>>
>> Because movement is explicit (either you passed a temporary, or you=20
>> passed move(obj)), binding to && is not an accident, it is done on purpo=
se,=20
>> and there is thus no way it creates chaos.
>>
>> It creates chaos because the standard is supposed to specify the state o=
f=20
> objects after each function.* Explicitly*. If a function does not say=20
> that the state of the object is affected by the function, then the functi=
on=20
> *may not* affect the state of that object.
>

It does. You pass a temporary, what's left of it is in an undefined (but=20
valid) state. Which is good since it disappears immediately (or you=20
promised not to use it anymore by using move()). Again, I insist, passing=
=20
rvalues does not happen by accident, it is clear in the caller. Having=20
functions where the standard mandates moving makes sense. But I want the=20
library to be able to move wherever it makes sense without requiring tons=
=20
of spam overloads in the standard document. For instance, in the=20
std::integer proposal, I argued strongly that the move constructor and all=
=20
the operator overloads taking rvalue references should be left out of the=
=20
text, as they are implementation details (as long as we don't add=20
guarantees like noexcept).
=20
You may consider this as a chaotic subversion of the standard. I consider=
=20
that your position subverts the spirit of rvalue references. And taking the=
=20
standard library specification too literally doesn't help either, or we'll=
=20
have to normalize an implementation.

None of that is the actual, *normative* text.
>

It explains what the people writing the normative text had in mind.
=20

> `std::basic_stringstream::str` does *not* take `this` as an "rvalue=20
> reference parameter". Therefore, any implementation that *did* split the=
=20
> function between `&` and `&&` versions and did indeed move the string out=
=20
> of the object would be in *violation* of the standard.
>

That's where we disagree. I think an implementation is already allowed to=
=20
do it. And if it isn't, it should. That would only help.

Again, I am still in favor of a nicer more explicit syntax as well.

--=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/?hl=3Den.



------=_Part_3209_5754161.1368382929768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 16:00:25 UTC+2, Nicol Bolas a =E9crit&nbsp;:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Sunday, May 12, 2013 6:21:23 AM UT=
C-7, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Because moveme=
nt is explicit (either you passed a temporary, or you passed move(obj)), bi=
nding to &amp;&amp; is not an accident, it is done on purpose, and there is=
 thus no way it creates chaos.<br></div><br></blockquote><div>It creates ch=
aos because the standard is supposed to specify the state of objects after =
each function.<i> Explicitly</i>. If a function does not say that the state=
 of the object is affected by the function, then the function <i>may not</i=
> affect the state of that object.<br></div></blockquote><div><br>It does. =
You pass a temporary, what's left of it is in an undefined (but valid) stat=
e. Which is good since it disappears immediately (or you promised not to us=
e it anymore by using move()). Again, I insist, passing rvalues does not ha=
ppen by accident, it is clear in the caller. Having functions where the sta=
ndard mandates moving makes sense. But I want the library to be able to mov=
e wherever it makes sense without requiring tons of spam overloads in the s=
tandard document. For instance, in the std::integer proposal, I argued stro=
ngly that the move constructor and all the operator overloads taking rvalue=
 references should be left out of the text, as they are implementation deta=
ils (as long as we don't add guarantees like noexcept).<br>&nbsp;<br>You ma=
y consider this as a chaotic subversion of the standard. I consider that yo=
ur position subverts the spirit of rvalue references. And taking the standa=
rd library specification too literally doesn't help either, or we'll have t=
o normalize an implementation.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;"><div>None of that is the actual, <i>normative</i=
> text.</div></blockquote><div><br>It explains what the people writing the =
normative text had in mind.<br>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;"><div><div>`std::basic_stringstream::str` does <i>=
not</i> take `this` as an "rvalue reference parameter". Therefore, any impl=
ementation that <i>did</i> split the function between `&amp;` and `&amp;&am=
p;` versions and did indeed move the string out of the object would be in <=
i>violation</i> of the standard.</div></div></blockquote><div><br>That's wh=
ere we disagree. I think an implementation is already allowed to do it. And=
 if it isn't, it should. That would only help.<br><br>Again, I am still in =
favor of a nicer more explicit syntax as well.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3209_5754161.1368382929768--

.

--089e012948024ebeba04dc89b890
Content-Type: text/plain; charset=ISO-8859-1

On 12 May 2013 21:22, Marc <marc.glisse@gmail.com> wrote:

>
>
>
>> `std::basic_stringstream::str` does *not* take `this` as an "rvalue
>> reference parameter". Therefore, any implementation that *did* split the
>> function between `&` and `&&` versions and did indeed move the string out
>> of the object would be in *violation* of the standard.
>>
>
> That's where we disagree. I think an implementation is already allowed to
> do it. And if it isn't, it should. That would only help.
>

17.6.5.5 Member functions [member.functions]/2:
An implementation may declare additional non-virtual member function
signatures within a class:
...
-  by adding a member function signature for a member function name.
3 A call to a member function signature described in the C ++ standard
library behaves as if the implementation
declares no additional member function signatures. Footnote 187
187) A valid C ++ program always calls the expected library member
function, or one with equivalent behavior. An implemen-
tation may also define additional member functions that would otherwise not
be called by a valid C++ program.


In other words, a library implementation is allowed to add the overloads
we're talking about.

Now, let's create a proposal that actually adds those overloads explicitly,
rather than rely on implementations
to do it, 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/?hl=en.



--089e012948024ebeba04dc89b890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 May 2013 21:22, Marc <span dir=3D"ltr">&lt;<a href=3D"mailto:=
marc.glisse@gmail.com" target=3D"_blank">marc.glisse@gmail.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>=A0<div class=3D"im">=
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div>`std::basic_stringstream::str` does <i>not</i> take `this` as an =
&quot;rvalue reference parameter&quot;. Therefore, any implementation that =
<i>did</i> split the function between `&amp;` and `&amp;&amp;` versions and=
 did indeed move the string out of the object would be in <i>violation</i> =
of the standard.</div>
</div></blockquote></div><div><br>That&#39;s where we disagree. I think an =
implementation is already allowed to do it. And if it isn&#39;t, it should.=
 That would only help.<br></div></blockquote><div><br>17.6.5.5 Member funct=
ions [member.functions]/2:<br>
An implementation may declare additional non-virtual member function signat=
ures within a class:<br>..<br>-=A0 by adding a member function signature fo=
r a member function name.<br>3 A call to a member function signature descri=
bed in the C ++ standard library behaves as if the implementation<br>
declares no additional member function signatures. Footnote 187<br>187) A v=
alid C ++ program always calls the expected library member function, or one=
 with equivalent behavior. An implemen-<br>tation may also define additiona=
l member functions that would otherwise not be called by a valid C++ progra=
m.<br>
<br><br></div><div>In other words, a library implementation is allowed to a=
dd the overloads we&#39;re talking about.<br><br></div><div>Now, let&#39;s =
create a proposal that actually adds those overloads explicitly, rather tha=
n rely on implementations<br>
to do it, please.<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e012948024ebeba04dc89b890--

.

--047d7b33d31ce2ddd104dc89d18b
Content-Type: text/plain; charset=ISO-8859-1

On 12 May 2013 21:39, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

>
>
>
> On 12 May 2013 21:22, Marc <marc.glisse@gmail.com> wrote:
>
>>
>>
>>
>>> `std::basic_stringstream::str` does *not* take `this` as an "rvalue
>>> reference parameter". Therefore, any implementation that *did* split
>>> the function between `&` and `&&` versions and did indeed move the string
>>> out of the object would be in *violation* of the standard.
>>>
>>
>> That's where we disagree. I think an implementation is already allowed to
>> do it. And if it isn't, it should. That would only help.
>>
>
> 17.6.5.5 Member functions [member.functions]/2:
> An implementation may declare additional non-virtual member function
> signatures within a class:
> ..
> -  by adding a member function signature for a member function name.
> 3 A call to a member function signature described in the C ++ standard
> library behaves as if the implementation
> declares no additional member function signatures. Footnote 187
> 187) A valid C ++ program always calls the expected library member
> function, or one with equivalent behavior. An implemen-
> tation may also define additional member functions that would otherwise
> not be called by a valid C++ program.
>
>
> In other words, a library implementation is allowed to add the overloads
> we're talking about.
>
> Now, let's create a proposal that actually adds those overloads
> explicitly, rather than rely on implementations
> to do it, please.
>
>
Ah, just one more thing, says Lt. Columbo - if an rvalue reference overload
actually moves, it's not equivalent
in behavior, and the behavior difference is easy to detect. I think we
actually _need_ to add those overloads
to the standard and specify the semantics.

--

---
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/?hl=en.



--047d7b33d31ce2ddd104dc89d18b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 May 2013 21:39, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 12 May 2013 21:=
22, Marc <span dir=3D"ltr">&lt;<a href=3D"mailto:marc.glisse@gmail.com" tar=
get=3D"_blank">marc.glisse@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>=A0<div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">

<div><div>`std::basic_stringstream::str` does <i>not</i> take `this` as an =
&quot;rvalue reference parameter&quot;. Therefore, any implementation that =
<i>did</i> split the function between `&amp;` and `&amp;&amp;` versions and=
 did indeed move the string out of the object would be in <i>violation</i> =
of the standard.</div>

</div></blockquote></div><div><br>That&#39;s where we disagree. I think an =
implementation is already allowed to do it. And if it isn&#39;t, it should.=
 That would only help.<br></div></blockquote></div><div><br>17.6.5.5 Member=
 functions [member.functions]/2:<br>

An implementation may declare additional non-virtual member function signat=
ures within a class:<br>..<br>-=A0 by adding a member function signature fo=
r a member function name.<br>3 A call to a member function signature descri=
bed in the C ++ standard library behaves as if the implementation<br>

declares no additional member function signatures. Footnote 187<br>187) A v=
alid C ++ program always calls the expected library member function, or one=
 with equivalent behavior. An implemen-<br>tation may also define additiona=
l member functions that would otherwise not be called by a valid C++ progra=
m.<br>

<br><br></div><div>In other words, a library implementation is allowed to a=
dd the overloads we&#39;re talking about.<br><br></div><div>Now, let&#39;s =
create a proposal that actually adds those overloads explicitly, rather tha=
n rely on implementations<br>

to do it, please.<br></div></div><br></div></div></blockquote><div><br></di=
v><div>Ah, just one more thing, says Lt. Columbo - if an rvalue reference o=
verload actually moves, it&#39;s not equivalent<br>in behavior, and the beh=
avior difference is easy to detect. I think we actually _need_ to add those=
 overloads<br>
</div><div>to the standard and specify the semantics. <br></div></div><br><=
/div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b33d31ce2ddd104dc89d18b--

.

------=_Part_468_11038689.1368390244878
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 20:46:36 UTC+2, Ville Voutilainen a =E9crit :
>
> On 12 May 2013 21:39, Ville Voutilainen <ville.vo...@gmail.com<javascript=
:>
> > wrote:
>>
>> On 12 May 2013 21:22, Marc <marc....@gmail.com <javascript:>> wrote:
>>
>>> `std::basic_stringstream::str` does *not* take `this` as an "rvalue=20
>>>> reference parameter". Therefore, any implementation that *did* split=
=20
>>>> the function between `&` and `&&` versions and did indeed move the str=
ing=20
>>>> out of the object would be in *violation* of the standard.
>>>>
>>>
>>> That's where we disagree. I think an implementation is already allowed=
=20
>>> to do it. And if it isn't, it should. That would only help.
>>>
>>
>> 17.6.5.5 Member functions [member.functions]/2:
>> An implementation may declare additional non-virtual member function=20
>> signatures within a class:
>> ..
>> -  by adding a member function signature for a member function name.
>> 3 A call to a member function signature described in the C ++ standard=
=20
>> library behaves as if the implementation
>> declares no additional member function signatures. Footnote 187
>> 187) A valid C ++ program always calls the expected library member=20
>> function, or one with equivalent behavior. An implemen-
>> tation may also define additional member functions that would otherwise=
=20
>> not be called by a valid C++ program.
>>
>>
>> In other words, a library implementation is allowed to add the overloads=
=20
>> we're talking about.
>>
>> Now, let's create a proposal that actually adds those overloads=20
>> explicitly, rather than rely on implementations
>> to do it, please.
>>
>
But let's use a better syntax for that, like Nicol's move_str() ;-)
=20

> Ah, just one more thing, says Lt. Columbo - if an rvalue reference=20
> overload actually moves, it's not equivalent
> in behavior, and the behavior difference is easy to detect. I think we=20
> actually _need_ to add those overloads
> to the standard and specify the semantics.=20
>

I think 17.6.4.9 already gives you permission to treat the rvalue reference=
=20
as a temporary and thus of moving instead of copying, and the different=20
behavior is ok. If it doesn't, I really believe it should, and that's an=20
important point for the library.

--=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/?hl=3Den.



------=_Part_468_11038689.1368390244878
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le dimanche 12 mai 2013 20:46:36 UTC+2, Ville Voutilainen a =E9crit&nbsp;:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On 12 May 2013 21:39, Ville Voutilainen <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"zpj=
bD4Kn3T4J">ville.vo...@gmail.com</a>&gt;</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><div class=3D"gmail_quote"><div>On 12 May 2=
013 21:22, Marc <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"zpjbD4Kn3T4J">marc....@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">

<div><div>`std::basic_stringstream::str` does <i>not</i> take `this` as an =
"rvalue reference parameter". Therefore, any implementation that <i>did</i>=
 split the function between `&amp;` and `&amp;&amp;` versions and did indee=
d move the string out of the object would be in <i>violation</i> of the sta=
ndard.</div>

</div></blockquote></div><div><br>That's where we disagree. I think an impl=
ementation is already allowed to do it. And if it isn't, it should. That wo=
uld only help.<br></div></blockquote></div><div><br>17.6.5.5 Member functio=
ns [member.functions]/2:<br>

An implementation may declare additional non-virtual member function signat=
ures within a class:<br>..<br>-&nbsp; by adding a member function signature=
 for a member function name.<br>3 A call to a member function signature des=
cribed in the C ++ standard library behaves as if the implementation<br>

declares no additional member function signatures. Footnote 187<br>187) A v=
alid C ++ program always calls the expected library member function, or one=
 with equivalent behavior. An implemen-<br>tation may also define additiona=
l member functions that would otherwise not be called by a valid C++ progra=
m.<br>

<br><br></div><div>In other words, a library implementation is allowed to a=
dd the overloads we're talking about.<br><br></div><div>Now, let's create a=
 proposal that actually adds those overloads explicitly, rather than rely o=
n implementations<br>

to do it, please.<br></div></div></div></div></blockquote></div></div></div=
></blockquote><div><br>But let's use a better syntax for that, like Nicol's=
 move_str() ;-)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div></div></div></div></div></blockquote><div>Ah, just=
 one more thing, says Lt. Columbo - if an rvalue reference overload actuall=
y moves, it's not equivalent<br>in behavior, and the behavior difference is=
 easy to detect. I think we actually _need_ to add those overloads<br>
</div><div>to the standard and specify the semantics. <br></div></div></div=
></div></blockquote><div><br>I think 17.6.4.9 already gives you permission =
to treat the rvalue reference as a temporary and thus of moving instead of =
copying, and the different behavior is ok. If it doesn't, I really believe =
it should, and that's an important point for the library.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_468_11038689.1368390244878--

.

------=_Part_2398_25217006.1368390418414
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Sunday, May 12, 2013 1:24:04 PM UTC-7, Marc wrote:
>
> Le dimanche 12 mai 2013 20:46:36 UTC+2, Ville Voutilainen a =E9crit :
>>
>> On 12 May 2013 21:39, Ville Voutilainen <ville.vo...@gmail.com> wrote:
>>>
>>> On 12 May 2013 21:22, Marc <marc....@gmail.com> wrote:
>>>
>>>> `std::basic_stringstream::str` does *not* take `this` as an "rvalue=20
>>>>> reference parameter". Therefore, any implementation that *did* split=
=20
>>>>> the function between `&` and `&&` versions and did indeed move the st=
ring=20
>>>>> out of the object would be in *violation* of the standard.
>>>>>
>>>>
>>>> That's where we disagree. I think an implementation is already allowed=
=20
>>>> to do it. And if it isn't, it should. That would only help.
>>>>
>>>
>>> 17.6.5.5 Member functions [member.functions]/2:
>>> An implementation may declare additional non-virtual member function=20
>>> signatures within a class:
>>> ..
>>> -  by adding a member function signature for a member function name.
>>> 3 A call to a member function signature described in the C ++ standard=
=20
>>> library behaves as if the implementation
>>> declares no additional member function signatures. Footnote 187
>>> 187) A valid C ++ program always calls the expected library member=20
>>> function, or one with equivalent behavior. An implemen-
>>> tation may also define additional member functions that would otherwise=
=20
>>> not be called by a valid C++ program.
>>>
>>>
>>> In other words, a library implementation is allowed to add the overload=
s=20
>>> we're talking about.
>>>
>>> Now, let's create a proposal that actually adds those overloads=20
>>> explicitly, rather than rely on implementations
>>> to do it, please.
>>>
>>
> But let's use a better syntax for that, like Nicol's move_str() ;-)
> =20
>
>> Ah, just one more thing, says Lt. Columbo - if an rvalue reference=20
>> overload actually moves, it's not equivalent
>> in behavior, and the behavior difference is easy to detect. I think we=
=20
>> actually _need_ to add those overloads
>> to the standard and specify the semantics.=20
>>
>
> I think 17.6.4.9 already gives you permission to treat the rvalue=20
> reference as a temporary and thus of moving instead of copying, and the=
=20
> different behavior is ok. If it doesn't, I really believe it should, and=
=20
> that's an important point for the library.
>

You can think that, but it doesn't. As previously stated, the definitions=
=20
of "argument" and "parameter" don't allow that. It only works when the=20
function is explicitly stated as taking an rvalue reference.=20

--=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/?hl=3Den.



------=_Part_2398_25217006.1368390418414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, May 12, 2013 1:24:04 PM UTC-7, Marc wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Le dimanche 12 mai 2013 20:46:36 UTC+2, Vill=
e Voutilainen a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote">On 12 May 2013 21:39, Ville Vou=
tilainen <span dir=3D"ltr">&lt;<a>ville.vo...@gmail.com</a>&gt;</span> wrot=
e:<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><div class=3D"gmail_=
quote"><div>On 12 May 2013 21:22, Marc <span dir=3D"ltr">&lt;<a>marc....@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><div>`std::basic_stringstream::str` does <i>not</i> take `this` as an =
"rvalue reference parameter". Therefore, any implementation that <i>did</i>=
 split the function between `&amp;` and `&amp;&amp;` versions and did indee=
d move the string out of the object would be in <i>violation</i> of the sta=
ndard.</div>

</div></blockquote></div><div><br>That's where we disagree. I think an impl=
ementation is already allowed to do it. And if it isn't, it should. That wo=
uld only help.<br></div></blockquote></div><div><br>17.6.5.5 Member functio=
ns [member.functions]/2:<br>

An implementation may declare additional non-virtual member function signat=
ures within a class:<br>..<br>-&nbsp; by adding a member function signature=
 for a member function name.<br>3 A call to a member function signature des=
cribed in the C ++ standard library behaves as if the implementation<br>

declares no additional member function signatures. Footnote 187<br>187) A v=
alid C ++ program always calls the expected library member function, or one=
 with equivalent behavior. An implemen-<br>tation may also define additiona=
l member functions that would otherwise not be called by a valid C++ progra=
m.<br>

<br><br></div><div>In other words, a library implementation is allowed to a=
dd the overloads we're talking about.<br><br></div><div>Now, let's create a=
 proposal that actually adds those overloads explicitly, rather than rely o=
n implementations<br>

to do it, please.<br></div></div></div></div></blockquote></div></div></div=
></blockquote><div><br>But let's use a better syntax for that, like Nicol's=
 move_str() ;-)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te"><div></div></div></div></div></blockquote><div>Ah, just one more thing,=
 says Lt. Columbo - if an rvalue reference overload actually moves, it's no=
t equivalent<br>in behavior, and the behavior difference is easy to detect.=
 I think we actually _need_ to add those overloads<br>
</div><div>to the standard and specify the semantics. <br></div></div></div=
></div></blockquote><div><br>I think 17.6.4.9 already gives you permission =
to treat the rvalue reference as a temporary and thus of moving instead of =
copying, and the different behavior is ok. If it doesn't, I really believe =
it should, and that's an important point for the library.<br></div></blockq=
uote><div><br>You can think that, but it doesn't. As previously stated, the=
 definitions of "argument" and "parameter" don't allow that. It only works =
when the function is explicitly stated as taking an rvalue reference. <br><=
/div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2398_25217006.1368390418414--

.