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

It's surprisingly hard to come up with a good, teachable set of rules for
when to use std::move. For example, it would be nice to be able to say "you
can leave out std::move when returning a named local variable", but this is
not always the case. Consider:

std::unique_ptr<const Foo> FooFactory() {
  std::unique_ptr<Foo> result(new Foo);
  // ...
  return std::move(result);
}

The "std::move" is mandatory here, because an lvalue can only be implicitly
treated as an rvalue during copy operations, and in "return result;",
'result' is not copied, but used as the input for an implicit conversion.
It seems like this should be fixable, perhaps by expanding the
implicit-rvalue rules, but I'm not sure what all the consequences would be
(at a minimum, this could change the behavior of existing code that has
separate rvalue and lvalue overloads for an implicit conversion operation).

Conversely, it would be nice to be able to say "When in doubt, just use
std::move if you want move semantics, because it never hurts", but
std::move can in fact be a pessimization:

std::array<Foo, 10000> MakeHugeArray() {
  std::array<Foo, 10000> result;
  // ...
  return std::move(result);
}

As written, the return statement incurs 10,000 invocations of Foo's move
constructor (or, worse, its copy constructor), but if std::move is
eliminated, the return statement becomes effectively free, because it's an
elidable copy/move. In this case it's not at all clear to me how to fix the
problem; it seems like a fix would either require special-casing std::move
(which seems like a hack, and breaks the convention that the core-language
standard tries not to refer to the library standard), or require the
implementation to 'see into' the implementation of a function called in a
return statement (which seems impractical).

I think it's worth trying to fix these issues, despite the difficulties,
because being able to provide reliable "rules of thumb" would substantially
improve the learning curve for std::move. Can anyone suggest how these
issues could be fixed?

--

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



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

<div dir=3D"ltr">It&#39;s surprisingly hard to come up with a good, teachab=
le set of rules for when to use std::move. For example, it would be nice to=
 be able to say &quot;you can leave out std::move when returning a named lo=
cal variable&quot;, but this is not always the case. Consider:<div>
<br></div><div>std::unique_ptr&lt;const Foo&gt; FooFactory() {</div><div>=
=A0 std::unique_ptr&lt;Foo&gt; result(new Foo);</div><div>=A0 // ...</div><=
div>=A0 return std::move(result);</div><div>}</div><div><br></div><div>The =
&quot;std::move&quot; is mandatory here, because an lvalue can only be impl=
icitly treated as an rvalue during copy operations, and in &quot;return res=
ult;&quot;, &#39;result&#39; is not copied, but used as the input for an im=
plicit conversion. It seems like this should be fixable, perhaps by expandi=
ng the implicit-rvalue rules, but I&#39;m not sure what all the consequence=
s would be (at a minimum, this could change the behavior of existing code t=
hat has separate rvalue and lvalue overloads for an implicit conversion ope=
ration).</div>
<div><br></div><div>Conversely, it would be nice to be able to say &quot;Wh=
en in doubt, just use std::move if you want move semantics, because it neve=
r hurts&quot;, but std::move can in fact be a pessimization:</div><div>
<br></div><div>std::array&lt;Foo, 10000&gt; MakeHugeArray() {</div><div>=A0=
 std::array&lt;Foo, 10000&gt; result;</div><div>=A0 // ...</div><div>=A0 re=
turn std::move(result);</div><div>}</div><div><br></div><div>As written, th=
e return statement incurs 10,000 invocations of Foo&#39;s move constructor =
(or, worse, its copy constructor), but if std::move is eliminated, the retu=
rn statement becomes effectively free, because it&#39;s an elidable copy/mo=
ve. In this case it&#39;s not at all clear to me how to fix the problem; it=
 seems like a fix would either require special-casing std::move (which seem=
s like a hack, and breaks the convention that the core-language standard tr=
ies not to refer to the library standard), or require the implementation to=
 &#39;see into&#39; the implementation of a function called in a return sta=
tement (which seems impractical).=A0</div>
<div><br></div><div>I think it&#39;s worth trying to fix these issues, desp=
ite the difficulties, because being able to provide reliable &quot;rules of=
 thumb&quot; would substantially improve the learning curve for std::move. =
Can anyone suggest how these issues could be fixed?<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b15b117dc041c04dfeac4c2--

.

On Mon, Jun 24, 2013 at 11:42 AM, Geoffrey Romer <gromer@google.com> wrote:
> It's surprisingly hard to come up with a good, teachable set of rules for
> when to use std::move. For example, it would be nice to be able to say "you
> can leave out std::move when returning a named local variable", but this is
> not always the case. Consider:
>
> std::unique_ptr<const Foo> FooFactory() {
>   std::unique_ptr<Foo> result(new Foo);
>   // ...
>   return std::move(result);
> }
>
> The "std::move" is mandatory here, because an lvalue can only be implicitly
> treated as an rvalue during copy operations, and in "return result;",
> 'result' is not copied, but used as the input for an implicit conversion. It
> seems like this should be fixable, perhaps by expanding the implicit-rvalue
> rules, but I'm not sure what all the consequences would be (at a minimum,
> this could change the behavior of existing code that has separate rvalue and
> lvalue overloads for an implicit conversion operation).

Yes, for NRVO, I think the "same cv-unqualified type as the function
return type" restriction only needs to apply to copy-elision and not
to implicit move. That is, I think we should treat 'result' as an
xvalue here:

T f() {
  U result;
  return result;
}

.... independent of the types of T and U, but we should only be
permitted to perform copy-elision of they're the same cv-unqualified
type. Most generalizations of the implicit-rvalue rules are fraught
with peril, but this one seems relatively safe.

> Conversely, it would be nice to be able to say "When in doubt, just use
> std::move if you want move semantics, because it never hurts", but std::move
> can in fact be a pessimization:
>
> std::array<Foo, 10000> MakeHugeArray() {
>   std::array<Foo, 10000> result;
>   // ...
>   return std::move(result);
> }

I suggest you talk to your compiler vendor (Hi!) and ask for a warning
for this case.

> As written, the return statement incurs 10,000 invocations of Foo's move
> constructor (or, worse, its copy constructor), but if std::move is
> eliminated, the return statement becomes effectively free, because it's an
> elidable copy/move. In this case it's not at all clear to me how to fix the
> problem; it seems like a fix would either require special-casing std::move
> (which seems like a hack, and breaks the convention that the core-language
> standard tries not to refer to the library standard), or require the
> implementation to 'see into' the implementation of a function called in a
> return statement (which seems impractical).
>
> I think it's worth trying to fix these issues, despite the difficulties,
> because being able to provide reliable "rules of thumb" would substantially
> improve the learning curve for std::move. Can anyone suggest how these
> issues could be fixed?

Per the above, I think we can make "you can leave out std::move when
returning a named local variable" be the right advice, with the added
bonus of a compiler warning if you put in a pessimizing std::move.

--

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



.

------=_Part_296_23524625.1372104509838
Content-Type: text/plain; charset=ISO-8859-1

I remember sending you and Mike a reminder about that some months ago, and
was wondering, did you actually talk about this at the Bristol meeting?

On Monday, June 24, 2013 9:14:17 PM UTC+2, Richard Smith wrote:
>
> On Mon, Jun 24, 2013 at 11:42 AM, Geoffrey Romer <gro...@google.com<javascript:>>
> wrote:
> > It's surprisingly hard to come up with a good, teachable set of rules
> for
> > when to use std::move. For example, it would be nice to be able to say
> "you
> > can leave out std::move when returning a named local variable", but this
> is
> > not always the case. Consider:
> >
> > std::unique_ptr<const Foo> FooFactory() {
> >   std::unique_ptr<Foo> result(new Foo);
> >   // ...
> >   return std::move(result);
> > }
> >
> > The "std::move" is mandatory here, because an lvalue can only be
> implicitly
> > treated as an rvalue during copy operations, and in "return result;",
> > 'result' is not copied, but used as the input for an implicit
> conversion. It
> > seems like this should be fixable, perhaps by expanding the
> implicit-rvalue
> > rules, but I'm not sure what all the consequences would be (at a
> minimum,
> > this could change the behavior of existing code that has separate rvalue
> and
> > lvalue overloads for an implicit conversion operation).
>
> Yes, for NRVO, I think the "same cv-unqualified type as the function
> return type" restriction only needs to apply to copy-elision and not
> to implicit move. That is, I think we should treat 'result' as an
> xvalue here:
>
> T f() {
>   U result;
>   return result;
> }
>
> ... independent of the types of T and U, but we should only be
> permitted to perform copy-elision of they're the same cv-unqualified
> type. Most generalizations of the implicit-rvalue rules are fraught
> with peril, but this one seems relatively safe.
>
> > Conversely, it would be nice to be able to say "When in doubt, just use
> > std::move if you want move semantics, because it never hurts", but
> std::move
> > can in fact be a pessimization:
> >
> > std::array<Foo, 10000> MakeHugeArray() {
> >   std::array<Foo, 10000> result;
> >   // ...
> >   return std::move(result);
> > }
>
> I suggest you talk to your compiler vendor (Hi!) and ask for a warning
> for this case.
>
> > As written, the return statement incurs 10,000 invocations of Foo's move
> > constructor (or, worse, its copy constructor), but if std::move is
> > eliminated, the return statement becomes effectively free, because it's
> an
> > elidable copy/move. In this case it's not at all clear to me how to fix
> the
> > problem; it seems like a fix would either require special-casing
> std::move
> > (which seems like a hack, and breaks the convention that the
> core-language
> > standard tries not to refer to the library standard), or require the
> > implementation to 'see into' the implementation of a function called in
> a
> > return statement (which seems impractical).
> >
> > I think it's worth trying to fix these issues, despite the difficulties,
> > because being able to provide reliable "rules of thumb" would
> substantially
> > improve the learning curve for std::move. Can anyone suggest how these
> > issues could be fixed?
>
> Per the above, I think we can make "you can leave out std::move when
> returning a named local variable" be the right advice, with the added
> bonus of a compiler warning if you put in a pessimizing std::move.
>

--

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



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

I remember sending you and Mike a reminder about that some months ago, and =
was wondering, did you actually talk about this at the Bristol meeting?<br>=
<br>On Monday, June 24, 2013 9:14:17 PM UTC+2, Richard Smith wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Mon, Jun 24, 2013 at 11:42 AM, Geof=
frey Romer &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"aTEsPprxzZgJ">gro...@google.com</a>&gt; wrote:
<br>&gt; It's surprisingly hard to come up with a good, teachable set of ru=
les for
<br>&gt; when to use std::move. For example, it would be nice to be able to=
 say "you
<br>&gt; can leave out std::move when returning a named local variable", bu=
t this is
<br>&gt; not always the case. Consider:
<br>&gt;
<br>&gt; std::unique_ptr&lt;const Foo&gt; FooFactory() {
<br>&gt; &nbsp; std::unique_ptr&lt;Foo&gt; result(new Foo);
<br>&gt; &nbsp; // ...
<br>&gt; &nbsp; return std::move(result);
<br>&gt; }
<br>&gt;
<br>&gt; The "std::move" is mandatory here, because an lvalue can only be i=
mplicitly
<br>&gt; treated as an rvalue during copy operations, and in "return result=
;",
<br>&gt; 'result' is not copied, but used as the input for an implicit conv=
ersion. It
<br>&gt; seems like this should be fixable, perhaps by expanding the implic=
it-rvalue
<br>&gt; rules, but I'm not sure what all the consequences would be (at a m=
inimum,
<br>&gt; this could change the behavior of existing code that has separate =
rvalue and
<br>&gt; lvalue overloads for an implicit conversion operation).
<br>
<br>Yes, for NRVO, I think the "same cv-unqualified type as the function
<br>return type" restriction only needs to apply to copy-elision and not
<br>to implicit move. That is, I think we should treat 'result' as an
<br>xvalue here:
<br>
<br>T f() {
<br>&nbsp; U result;
<br>&nbsp; return result;
<br>}
<br>
<br>... independent of the types of T and U, but we should only be
<br>permitted to perform copy-elision of they're the same cv-unqualified
<br>type. Most generalizations of the implicit-rvalue rules are fraught
<br>with peril, but this one seems relatively safe.
<br>
<br>&gt; Conversely, it would be nice to be able to say "When in doubt, jus=
t use
<br>&gt; std::move if you want move semantics, because it never hurts", but=
 std::move
<br>&gt; can in fact be a pessimization:
<br>&gt;
<br>&gt; std::array&lt;Foo, 10000&gt; MakeHugeArray() {
<br>&gt; &nbsp; std::array&lt;Foo, 10000&gt; result;
<br>&gt; &nbsp; // ...
<br>&gt; &nbsp; return std::move(result);
<br>&gt; }
<br>
<br>I suggest you talk to your compiler vendor (Hi!) and ask for a warning
<br>for this case.
<br>
<br>&gt; As written, the return statement incurs 10,000 invocations of Foo'=
s move
<br>&gt; constructor (or, worse, its copy constructor), but if std::move is
<br>&gt; eliminated, the return statement becomes effectively free, because=
 it's an
<br>&gt; elidable copy/move. In this case it's not at all clear to me how t=
o fix the
<br>&gt; problem; it seems like a fix would either require special-casing s=
td::move
<br>&gt; (which seems like a hack, and breaks the convention that the core-=
language
<br>&gt; standard tries not to refer to the library standard), or require t=
he
<br>&gt; implementation to 'see into' the implementation of a function call=
ed in a
<br>&gt; return statement (which seems impractical).
<br>&gt;
<br>&gt; I think it's worth trying to fix these issues, despite the difficu=
lties,
<br>&gt; because being able to provide reliable "rules of thumb" would subs=
tantially
<br>&gt; improve the learning curve for std::move. Can anyone suggest how t=
hese
<br>&gt; issues could be fixed?
<br>
<br>Per the above, I think we can make "you can leave out std::move when
<br>returning a named local variable" be the right advice, with the added
<br>bonus of a compiler warning if you put in a pessimizing std::move.
<br></blockquote>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_296_23524625.1372104509838--

.

On Mon, Jun 24, 2013 at 1:08 PM, Xeo <hivemaster@hotmail.de> wrote:
> I remember sending you and Mike a reminder about that some months ago, and
> was wondering, did you actually talk about this at the Bristol meeting?

No. For CWG, the Bristol meeting was almost entirely occupied by
reviewing C++14 feature wording. I don't recall seeing this on the
issues list, either, but perhaps I just missed it.

> On Monday, June 24, 2013 9:14:17 PM UTC+2, Richard Smith wrote:
>>
>> On Mon, Jun 24, 2013 at 11:42 AM, Geoffrey Romer <gro...@google.com>
>> wrote:
>> > It's surprisingly hard to come up with a good, teachable set of rules
>> > for
>> > when to use std::move. For example, it would be nice to be able to say
>> > "you
>> > can leave out std::move when returning a named local variable", but this
>> > is
>> > not always the case. Consider:
>> >
>> > std::unique_ptr<const Foo> FooFactory() {
>> >   std::unique_ptr<Foo> result(new Foo);
>> >   // ...
>> >   return std::move(result);
>> > }
>> >
>> > The "std::move" is mandatory here, because an lvalue can only be
>> > implicitly
>> > treated as an rvalue during copy operations, and in "return result;",
>> > 'result' is not copied, but used as the input for an implicit
>> > conversion. It
>> > seems like this should be fixable, perhaps by expanding the
>> > implicit-rvalue
>> > rules, but I'm not sure what all the consequences would be (at a
>> > minimum,
>> > this could change the behavior of existing code that has separate rvalue
>> > and
>> > lvalue overloads for an implicit conversion operation).
>>
>> Yes, for NRVO, I think the "same cv-unqualified type as the function
>> return type" restriction only needs to apply to copy-elision and not
>> to implicit move. That is, I think we should treat 'result' as an
>> xvalue here:
>>
>> T f() {
>>   U result;
>>   return result;
>> }
>>
>> ... independent of the types of T and U, but we should only be
>> permitted to perform copy-elision of they're the same cv-unqualified
>> type. Most generalizations of the implicit-rvalue rules are fraught
>> with peril, but this one seems relatively safe.
>>
>> > Conversely, it would be nice to be able to say "When in doubt, just use
>> > std::move if you want move semantics, because it never hurts", but
>> > std::move
>> > can in fact be a pessimization:
>> >
>> > std::array<Foo, 10000> MakeHugeArray() {
>> >   std::array<Foo, 10000> result;
>> >   // ...
>> >   return std::move(result);
>> > }
>>
>> I suggest you talk to your compiler vendor (Hi!) and ask for a warning
>> for this case.
>>
>> > As written, the return statement incurs 10,000 invocations of Foo's move
>> > constructor (or, worse, its copy constructor), but if std::move is
>> > eliminated, the return statement becomes effectively free, because it's
>> > an
>> > elidable copy/move. In this case it's not at all clear to me how to fix
>> > the
>> > problem; it seems like a fix would either require special-casing
>> > std::move
>> > (which seems like a hack, and breaks the convention that the
>> > core-language
>> > standard tries not to refer to the library standard), or require the
>> > implementation to 'see into' the implementation of a function called in
>> > a
>> > return statement (which seems impractical).
>> >
>> > I think it's worth trying to fix these issues, despite the difficulties,
>> > because being able to provide reliable "rules of thumb" would
>> > substantially
>> > improve the learning curve for std::move. Can anyone suggest how these
>> > issues could be fixed?
>>
>> Per the above, I think we can make "you can leave out std::move when
>> returning a named local variable" be the right advice, with the added
>> bonus of a compiler warning if you put in a pessimizing std::move.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>

--

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



.

------=_Part_517_30114209.1372182947769
Content-Type: text/plain; charset=ISO-8859-1

I would suggest writing something like that:

*std::unique_ptr<const Foo> FooFactory() {*
*  std::unique_ptr<const Foo> result(static_cast<const Foo*>(new Foo));*
*  // ...*
*  return result;*
*}*

Then you don't need to deal with implicit conversions and writing *return
std::move(result);*.

On the other hand, if you need to change the newly created Foo value: just
deal with it first and then create the unique_ptr and return 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/.



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

<div>I would suggest writing something like that:</div><div><div>&nbsp;</di=
v><div><strong>std::unique_ptr&lt;const Foo&gt; FooFactory() {</strong></di=
v><div><strong>&nbsp; std::unique_ptr&lt;const Foo&gt; result(static_cast&l=
t;const Foo*&gt;(new Foo));</strong></div><div><strong>&nbsp; // ...</stron=
g></div><div><strong>&nbsp; return result;</strong></div><div><strong>}</st=
rong></div></div><div>&nbsp;</div><div>Then you don't need to deal with imp=
licit conversions and writing <strong>return std::move(result);</strong>.</=
div><div>&nbsp;</div><div>On the other hand, if you need to change the newl=
y created Foo value: just deal with it first and then create the unique_ptr=
 and return it.</div><div><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_517_30114209.1372182947769--

.

------=_Part_698_11141268.1372183288823
Content-Type: text/plain; charset=ISO-8859-1

You don't actually need the static_cast here. The following will do:

*std::unique_ptr<const Foo> FooFactory() {*

> *  std::unique_ptr<const Foo> result(new Foo);*
> *  // ...*
> *  return result;*
> *}*
>
>
>

--

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



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

<div>You don't actually need the static_cast here. The following will do:</=
div><div><br><strong>std::unique_ptr&lt;const Foo&gt; FooFactory() {</stron=
g></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div><div><strong>&nbsp; std::unique_p=
tr&lt;const Foo&gt; result(new Foo);</strong></div><div><strong>&nbsp; // .=
...</strong></div><div><strong>&nbsp; return result;</strong></div><div><str=
ong>}</strong></div></div><div>&nbsp;</div><div><br>
</div>
</blockquote>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_698_11141268.1372183288823--

.

--20cf306844d580a1e604dffe807d
Content-Type: text/plain; charset=ISO-8859-1

On 25 June 2013 21:01, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> You don't actually need the static_cast here. The following will do:
>
> *std::unique_ptr<const Foo> FooFactory() {*
>
>> *  std::unique_ptr<const Foo> result(new Foo);*
>> *  // ...*
>> *  return result;*
>> *}*
>>
>>
>>
>>
Except that it won't for cases where the factory wants to modify the Foo
stored inside the unique_ptr
before ultimately returning it as a unique_ptr to const Foo.

--

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



--20cf306844d580a1e604dffe807d
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 25 June 2013 21:01, Mikhail Semenov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1=
957@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>You don&#39;t actually need the static_=
cast here. The following will do:</div><div class=3D"im"><div><br><b>std::u=
nique_ptr&lt;const Foo&gt; FooFactory() {</b></div>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid"><div><div><b>=A0 std::unique_ptr&lt;const Foo&gt; re=
sult(new Foo);</b></div>
<div><b>=A0 // ...</b></div><div><b>=A0 return result;</b></div><div><b>}</=
b></div></div><div>=A0</div><div><br><br></div></blockquote></blockquote><d=
iv><br></div><div>Except that it won&#39;t for cases where the factory want=
s to modify the Foo stored inside the unique_ptr<br>
</div><div>before ultimately returning it as a unique_ptr to const Foo. <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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf306844d580a1e604dffe807d--

.

------=_Part_754_602566.1372185985239
Content-Type: text/plain; charset=ISO-8859-1

If you really need to convert, I suggest make it explicit:

*std::unique_ptr<const Foo> FooFactory() {*
*  std::unique_ptr<Foo> result(new Foo);*
*  // ...*
*  return std::unique_ptr<const Foo>(std::move(result));*
*}*
**
It would be clear what you are doing.

By the way, where I work we always write explicit casts.



--

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



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

<div><div>If you really need to convert, I suggest make it explicit:</div><=
div>&nbsp;</div><div><strong>std::unique_ptr&lt;const Foo&gt; FooFactory() =
{</strong></div><div><strong>&nbsp; std::unique_ptr&lt;Foo&gt; result(new F=
oo);</strong></div><div><strong>&nbsp; // ...</strong></div><div><strong>&n=
bsp; return std::unique_ptr&lt;const Foo&gt;(std::move(result));</strong></=
div><div><strong>}</strong></div></div><div><strong></strong>&nbsp;</div><d=
iv>It would be clear what you are doing.</div><div>&nbsp;</div><div>By the =
way, where I work we always write explicit casts.</div><div><br>&nbsp;</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_754_602566.1372185985239--

.

------=_Part_307_31275737.1372238304414
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, June 25, 2013 7:46:25 PM UTC+1, Mikhail Semenov wrote:
>
> If you really need to convert, I suggest make it explicit:
>
> *std::unique_ptr<const Foo> FooFactory() {*
> *  std::unique_ptr<Foo> result(new Foo);*
>

*ahem* std::make_unique   ;-)

*  // ...*
> *  return std::unique_ptr<const Foo>(std::move(result));*
> *}*
> **
> It would be clear what you are doing.
>

It would be clear anyway with Geoffrey's suggestion, returning a unique_ptr
of one type and having it convert to the return type.

If I didn't want the return type to differ from the declared type I'd have
used return type deduction anyway, right?


> By the way, where I work we always write explicit casts.
>

That's your prerogative, but doesn't mean it is the only way or that
everyone else should have to do it that way.

Coming back to the original topic, are you really suggesting the code above
is the ideal form for teaching when to use std::move and when not to?  I
think "return result;" is much simpler.

--

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



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

<br><br>On Tuesday, June 25, 2013 7:46:25 PM UTC+1, Mikhail Semenov wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div><div>If you really need to=
 convert, I suggest make it explicit:</div><div>&nbsp;</div><div><b>std::un=
ique_ptr&lt;const Foo&gt; FooFactory() {</b></div><div><b>&nbsp; std::uniqu=
e_ptr&lt;Foo&gt; result(new Foo);</b></div></div></blockquote><div><br>*ahe=
m* std::make_unique&nbsp;&nbsp; ;-)<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div><div><b>&nbsp; // ...</b></div><div><b>&nbsp; retur=
n std::unique_ptr&lt;const Foo&gt;(std::move(result));</b></div><div><b>}</=
b></div></div><div><b></b>&nbsp;</div><div>It would be clear what you are d=
oing.</div></blockquote><div><br>It would be clear anyway with Geoffrey's s=
uggestion, returning a unique_ptr of one type and having it convert to the =
return type.<br><br>If I didn't want the return type to differ from the dec=
lared type I'd have used return type deduction anyway, right?<br>&nbsp;<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>By the way, where I=
 work we always write explicit casts.</div></blockquote><div><br>That's you=
r prerogative, but doesn't mean it is the only way or that everyone else sh=
ould have to do it that way.<br><br>Coming back to the original topic, are =
you really suggesting the code above is the ideal form for teaching when to=
 use std::move and when not to?&nbsp; I think "return result;" is much simp=
ler.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_307_31275737.1372238304414--

.

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

> Coming back to the original topic, are you really suggesting the code
above is the ideal form for teaching when to use std::move and when > not
to?  I think "return result;" is much simpler.

If you have to convert from std::unique_ptr<Foo> to std::unique_ptr<const
Foo>
the following code *WON'T COMPILE*;
*return result;*

*Try it in your compiler!*

My point is that if you have to convert  (from std::unique_ptr<Foo> to
std::unique_ptr<const Foo>) write it explicitly:

 *return std::unique_ptr<const Foo>(std::move(result));*

If you don't have to convert (you use the same unque_ptr types) than yes write
as you said:
**
*return result*.

--

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



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

<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff">&gt; Coming=
 back to the original topic, are you really suggesting the code above is th=
e ideal form for teaching when to use std::move and when &gt; not to?=A0 I =
think &quot;return result;&quot; is much simpler.<br>
</font></div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font></font>=A0</div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000">If you have to convert from std::unique_ptr&lt;Foo&gt; to std:=
:unique_ptr&lt;const Foo&gt;</font></font></div>
<div>the following code <font color=3D"#ff0000"><strong>WON&#39;T COMPILE</=
strong></font>;</div>
<div><strong>return result;</strong></div>
<div>=A0</div>
<div><font color=3D"#ff6666"><strong>Try it in your compiler!</strong></fon=
t></div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font></font>=A0</div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000">My point is that if you have to convert=A0 (from std::unique_p=
tr&lt;Foo&gt; to std::unique_ptr&lt;const Foo&gt;) write it explicitly:</fo=
nt></font></div>

<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font>=A0</font></div>
<div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"><strong>return std::unique_ptr&lt;const Foo&gt;(std::move(resu=
lt));</strong></font></font></div></div>
<div>=A0</div>
<div><font color=3D"#000000">If you don&#39;t have to convert (you use the =
same unque_ptr types) than yes </font><font color=3D"#000000">write as you =
said:</font></div>
<div><font color=3D"#000000"><strong></strong></font>=A0</div>
<div><font color=3D"#000000"><strong>return result</strong>.</font></div>
<div><font color=3D"#000000"></font><br>=A0</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0149c80041a66304e00cb370--

.

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

On 26 June 2013 14:10, Mikhail Semenov <mikhailsemenov1957@gmail.com> wrote:

> > Coming back to the original topic, are you really suggesting the code
> above is the ideal form for teaching when to use std::move and when > not
> to?  I think "return result;" is much simpler.
>
> If you have to convert from std::unique_ptr<Foo> to std::unique_ptr<const
> Foo>
> the following code *WON'T COMPILE*;
> *return result;*
>
> *Try it in your compiler!*
>

We know. There's no need to shout. The whole question is whether it should
be valid, aka compile.
The conversion in this case is perfectly safe, so perhaps we should
consider relaxing the rules.

--

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



--001a1132eceec2610e04e00ce00a
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 26 June 2013 14:10, Mikhail Semenov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov1=
957@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 class=3D"im"><div><font style color=3D"=
#3333ff">&gt; Coming back to the original topic, are you really suggesting =
the code above is the ideal form for teaching when to use std::move and whe=
n &gt; not to?=A0 I think &quot;return result;&quot; is much simpler.<br>

</font></div>
<div><font style color=3D"#3333ff"><font color=3D"#000000"></font></font>=
=A0</div>
</div><div><font style color=3D"#3333ff"><font color=3D"#000000">If you hav=
e to convert from std::unique_ptr&lt;Foo&gt; to std::unique_ptr&lt;const Fo=
o&gt;</font></font></div>
<div>the following code <font color=3D"#ff0000"><b>WON&#39;T COMPILE</b></f=
ont>;</div>
<div><b>return result;</b></div>
<div>=A0</div>
<div><font color=3D"#ff6666"><b>Try it in your compiler!</b></font></div></=
blockquote><div><br></div><div>We know. There&#39;s no need to shout. The w=
hole question is whether it should be valid, aka compile.<br></div><div>
The conversion in this case is perfectly safe, so perhaps we should conside=
r relaxing the rules.<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 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a1132eceec2610e04e00ce00a--

.

------=_Part_451_27735288.1372248521655
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 26, 2013 12:10:58 PM UTC+1, Mikhail Semenov wrote:
>
> > Coming back to the original topic, are you really suggesting the code
> above is the ideal form for teaching when to use std::move and when > not
> to?  I think "return result;" is much simpler.
>
> If you have to convert from std::unique_ptr<Foo> to std::unique_ptr<const
> Foo>
> the following code *WON'T COMPILE*;
> *return result;*
>
> *Try it in your compiler!*
>
> My point is that if you have to convert  (from std::unique_ptr<Foo> to
> std::unique_ptr<const Foo>) write it explicitly:
>
>  *return std::unique_ptr<const Foo>(std::move(result));*
>
> If you don't have to convert (you use the same unque_ptr types) than yes write
> as you said:
> **
> *return result*.
>
>
Yep, I know, I was referring to Geoffrey's suggestion to change that rule
in the first post in this thread: "It would be clear anyway with Geoffrey's
suggestion".   Apologies for trying to discuss the thread topic ;)


--

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



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

<br><br>On Wednesday, June 26, 2013 12:10:58 PM UTC+1, Mikhail Semenov wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div><font style=3D"BACKGROU=
ND-COLOR:#ffffff" color=3D"#3333ff">&gt; Coming back to the original topic,=
 are you really suggesting the code above is the ideal form for teaching wh=
en to use std::move and when &gt; not to?&nbsp; I think "return result;" is=
 much simpler.<br>
</font></div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font></font>&nbsp;</div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000">If you have to convert from std::unique_ptr&lt;Foo&gt; to std:=
:unique_ptr&lt;const Foo&gt;</font></font></div>
<div>the following code <font color=3D"#ff0000"><b>WON'T COMPILE</b></font>=
;</div>
<div><b>return result;</b></div>
<div>&nbsp;</div>
<div><font color=3D"#ff6666"><b>Try it in your compiler!</b></font></div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font></font>&nbsp;</div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000">My point is that if you have to convert&nbsp; (from std::uniqu=
e_ptr&lt;Foo&gt; to std::unique_ptr&lt;const Foo&gt;) write it explicitly:<=
/font></font></div>

<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"></font>&nbsp;</font></div>
<div>
<div><font style=3D"BACKGROUND-COLOR:#ffffff" color=3D"#3333ff"><font color=
=3D"#000000"><b>return std::unique_ptr&lt;const Foo&gt;(std::move(result));=
</b></font></font></div></div>
<div>&nbsp;</div>
<div><font color=3D"#000000">If you don't have to convert (you use the same=
 unque_ptr types) than yes </font><font color=3D"#000000">write as you said=
:</font></div>
<div><font color=3D"#000000"><b></b></font>&nbsp;</div>
<div><font color=3D"#000000"><b>return result</b>.</font></div>
<div><font color=3D"#000000"></font><br></div></blockquote><div><br>Yep, I =
know, I was referring to Geoffrey's suggestion to change that rule in the f=
irst post in this thread: "It would be clear anyway with Geoffrey's suggest=
ion".&nbsp;&nbsp; Apologies for trying to discuss the thread topic ;)<br><b=
r><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_451_27735288.1372248521655--

.

------=_Part_136_23637001.1403776474877
Content-Type: text/plain; charset=UTF-8



On Monday, 24 June 2013 22:30:48 UTC+1, Richard Smith wrote:
>
> On Mon, Jun 24, 2013 at 1:08 PM, Xeo <hivem...@hotmail.de <javascript:>>
> wrote:
> > I remember sending you and Mike a reminder about that some months ago,
> and
> > was wondering, did you actually talk about this at the Bristol meeting?
>
> No. For CWG, the Bristol meeting was almost entirely occupied by
> reviewing C++14 feature wording. I don't recall seeing this on the
> issues list, either, but perhaps I just missed it.
>


For the record, this is
http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579 which was
moved to DR in February at the Issaquah meeting.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, 24 June 2013 22:30:48 UTC+1, Richard Sm=
ith  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jun 24, 201=
3 at 1:08 PM, Xeo &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"FidKPZVnGtMJ" onmousedown=3D"this.href=3D'javascript:';return=
 true;" onclick=3D"this.href=3D'javascript:';return true;">hivem...@hotmail=
..de</a>&gt; wrote:
<br>&gt; I remember sending you and Mike a reminder about that some months =
ago, and
<br>&gt; was wondering, did you actually talk about this at the Bristol mee=
ting?
<br>
<br>No. For CWG, the Bristol meeting was almost entirely occupied by
<br>reviewing C++14 feature wording. I don't recall seeing this on the
<br>issues list, either, but perhaps I just missed it.
<br></blockquote><div><br></div><div><br></div><div>For the record, this is=
 http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579 which was mo=
ved to DR in February at the Issaquah meeting.<br></div></div>

<p></p>

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

------=_Part_136_23637001.1403776474877--

.

--Apple-Mail=_5A4CC440-FD0D-4886-ADF7-23F0E6DA759D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2013-06-25, at 2:42 AM, Geoffrey Romer <gromer@google.com> wrote:

> It's surprisingly hard to come up with a good, teachable set of rules for=
 when to use std::move. For example, it would be nice to be able to say "yo=
u can leave out std::move when returning a named local variable", but this =
is not always the case.

That doesn't sound like something that should be taught. Students shouldn't=
 have the impression that they should avoid move, or omit it just because t=
hey can.

> Conversely, it would be nice to be able to say "When in doubt, just use s=
td::move if you want move semantics, because it never hurts", but std::move=
 can in fact be a pessimization:
>=20
> std::array<Foo, 10000> MakeHugeArray() {
>   std::array<Foo, 10000> result;
>   // ...
>   return std::move(result);
> }
>=20
> As written, the return statement incurs 10,000 invocations of Foo's move =
constructor (or, worse, its copy constructor), but if std::move is eliminat=
ed, the return statement becomes effectively free, because it's an elidable=
 copy/move.

I'm pretty sure there's a DR for this. First-draft code doesn't need to run=
 full speed anyway. Students should learn general techniques for finding bo=
ttlenecks, not every performance quirk and pitfall. When fixing this code, =
it would be a good idea to add a comment that the result is expected to be =
constructed in-place, hence neither moved nor copied.

By the way, this code is still giving you exactly what you asked for. Askin=
g for a move when you actually want copy elision is, though reasonable, a c=
onfusion of two completely different things.

> In this case it's not at all clear to me how to fix the problem; it seems=
 like a fix would either require special-casing std::move (which seems like=
 a hack, and breaks the convention that the core-language standard tries no=
t to refer to the library standard), or require the implementation to 'see =
into' the implementation of a function called in a return statement (which =
seems impractical).=20

It may be doable for inline functions. Perhaps some future language iterati=
on will see through the thicket.

> I think it's worth trying to fix these issues, despite the difficulties, =
because being able to provide reliable "rules of thumb" would substantially=
 improve the learning curve for std::move. Can anyone suggest how these iss=
ues could be fixed?

Say move() when you want a move. Debug the rest, and be aware that moves st=
ill carry a cost which may be as much as a copy.

--=20

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

--Apple-Mail=_5A4CC440-FD0D-4886-ADF7-23F0E6DA759D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2013&=
ndash;06&ndash;25, at 2:42 AM, Geoffrey Romer &lt;<a href=3D"mailto:gromer@=
google.com">gromer@google.com</a>&gt; wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">It's surprisingly=
 hard to come up with a good, teachable set of rules for when to use std::m=
ove. For example, it would be nice to be able to say "you can leave out std=
::move when returning a named local variable", but this is not always the c=
ase. </div></blockquote><div><br></div><div>That doesn&rsquo;t sound like s=
omething that should be taught. Students shouldn&rsquo;t have the impressio=
n that they should avoid move, or omit it just because they can.</div><br><=
blockquote type=3D"cite"><div dir=3D"ltr"><div>Conversely, it would be nice=
 to be able to say "When in doubt, just use std::move if you want move sema=
ntics, because it never hurts", but std::move can in fact be a pessimizatio=
n:</div><div>
<br></div><div>std::array&lt;Foo, 10000&gt; MakeHugeArray() {</div><div>&nb=
sp; std::array&lt;Foo, 10000&gt; result;</div><div>&nbsp; // ...</div><div>=
&nbsp; return std::move(result);</div><div>}</div><div><br></div><div>As wr=
itten, the return statement incurs 10,000 invocations of Foo's move constru=
ctor (or, worse, its copy constructor), but if std::move is eliminated, the=
 return statement becomes effectively free, because it's an elidable copy/m=
ove. </div></div></blockquote><div><br></div><div>I'm pretty sure there&rsq=
uo;s a DR for this. First-draft code doesn&rsquo;t need to run full speed a=
nyway. Students should learn general techniques for finding bottlenecks, no=
t every performance quirk and pitfall. When fixing this code, it would be a=
 good idea to add a comment that the result is expected to be constructed i=
n-place, hence neither moved nor copied.</div><div><br></div><div>By the wa=
y, this code is still giving you exactly what you asked for. Asking for a m=
ove when you actually want copy elision is, though reasonable, a confusion =
of two completely different things.</div><br><blockquote type=3D"cite"><div=
 dir=3D"ltr"><div>In this case it's not at all clear to me how to fix the p=
roblem; it seems like a fix would either require special-casing std::move (=
which seems like a hack, and breaks the convention that the core-language s=
tandard tries not to refer to the library standard), or require the impleme=
ntation to 'see into' the implementation of a function called in a return s=
tatement (which seems impractical).&nbsp;</div></div></blockquote><div><br>=
</div><div>It may be doable for inline functions. Perhaps some future langu=
age iteration will see through the thicket.</div><br><blockquote type=3D"ci=
te"><div dir=3D"ltr">
<div>I think it's worth trying to fix these issues, despite the difficultie=
s, because being able to provide reliable "rules of thumb" would substantia=
lly improve the learning curve for std::move. Can anyone suggest how these =
issues could be fixed?</div></div></blockquote><br></div><div>Say <font fac=
e=3D"Courier">move()</font> when you want a move. Debug the rest, and be aw=
are that moves still carry a cost which may be as much as a copy.</div><div=
><br></div></body></html>

<p></p>

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

--Apple-Mail=_5A4CC440-FD0D-4886-ADF7-23F0E6DA759D--

.

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


I learnt that you should apply std::move only to the types that hold=20
resources (like heap memory) behind the scenes. That means you shouldn't=20
apply std::move to fundamental types and types that are bitwise copyable=20
(with shallow copy operation like aggregates). In fact, this applies to=20
std::array as well, but is limited to the implementation of type stored in=
=20
such array. Typical implementation of std::array might be:


template<class T, size_t n>
array { T storage[n]; /* some non-virual member function here... */  }

What if T is not bitwise copyable or it is, for instance std::vector<U> of=
=20
thousands of U? Should I apply move operation to every element of such=20
std::array<std::vector<U>, n>?  It depends mainly on N/RVO optimisations.=
=20
To be strict, moving blindly may not be a good idea.

Issuing a compiler warning on possible pessimization when applying=20
std::move is reasonable. Implicit conversion are evil in my opinion and=20
such conversion that changes properties of a type (like CV-qualifiers)=20
should result in warning. Compiler warnings are to help developers.


K


W dniu poniedzia=C5=82ek, 24 czerwca 2013 20:42:04 UTC+2 u=C5=BCytkownik Ge=
offrey=20
Romer napisa=C5=82:
>
> It's surprisingly hard to come up with a good, teachable set of rules for=
=20
> when to use std::move. For example, it would be nice to be able to say "y=
ou=20
> can leave out std::move when returning a named local variable", but this =
is=20
> not always the case. Consider:
>
> std::unique_ptr<const Foo> FooFactory() {
>   std::unique_ptr<Foo> result(new Foo);
>   // ...
>   return std::move(result);
> }
>
> The "std::move" is mandatory here, because an lvalue can only be=20
> implicitly treated as an rvalue during copy operations, and in "return=20
> result;", 'result' is not copied, but used as the input for an implicit=
=20
> conversion. It seems like this should be fixable, perhaps by expanding th=
e=20
> implicit-rvalue rules, but I'm not sure what all the consequences would b=
e=20
> (at a minimum, this could change the behavior of existing code that has=
=20
> separate rvalue and lvalue overloads for an implicit conversion operation=
).
>
> Conversely, it would be nice to be able to say "When in doubt, just use=
=20
> std::move if you want move semantics, because it never hurts", but=20
> std::move can in fact be a pessimization:
>
> std::array<Foo, 10000> MakeHugeArray() {
>   std::array<Foo, 10000> result;
>   // ...
>   return std::move(result);
> }
>
> As written, the return statement incurs 10,000 invocations of Foo's move=
=20
> constructor (or, worse, its copy constructor), but if std::move is=20
> eliminated, the return statement becomes effectively free, because it's a=
n=20
> elidable copy/move. In this case it's not at all clear to me how to fix t=
he=20
> problem; it seems like a fix would either require special-casing std::mov=
e=20
> (which seems like a hack, and breaks the convention that the core-languag=
e=20
> standard tries not to refer to the library standard), or require the=20
> implementation to 'see into' the implementation of a function called in a=
=20
> return statement (which seems impractical).=20
>
> I think it's worth trying to fix these issues, despite the difficulties,=
=20
> because being able to provide reliable "rules of thumb" would substantial=
ly=20
> improve the learning curve for std::move. Can anyone suggest how these=20
> issues could be fixed?
> =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/.

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

<div dir=3D"ltr"><br>I learnt that you should apply std::move only to the t=
ypes that hold resources (like heap memory) behind the scenes. That means y=
ou shouldn't apply std::move to fundamental types and types that are bitwis=
e copyable (with shallow copy operation like aggregates). In fact, this app=
lies to std::array as well, but is limited to the implementation of type st=
ored in such array. Typical implementation of std::array might be:<br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">template</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> size_t n</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>array </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> T storage</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">];</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">/* some non-virual member=
 function here... */</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> &nbsp;</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>What if T is not bitwise copyable or it is,=
 for instance std::vector&lt;U&gt; of thousands of U? Should I apply move o=
peration to every element of such std::array&lt;std::vector&lt;U&gt;, n&gt;=
?&nbsp; It depends mainly on N/RVO optimisations. To be strict, moving blin=
dly may not be a good idea.<br><br>Issuing a compiler warning on possible p=
essimization when applying std::move is reasonable. Implicit conversion are=
 evil in my opinion and such conversion that changes properties of a type (=
like CV-qualifiers) should result in warning. Compiler warnings are to help=
 developers.<br><br><br>K<br><br><br>W dniu poniedzia=C5=82ek, 24 czerwca 2=
013 20:42:04 UTC+2 u=C5=BCytkownik Geoffrey Romer napisa=C5=82:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It's surprisingly hard to=
 come up with a good, teachable set of rules for when to use std::move. For=
 example, it would be nice to be able to say "you can leave out std::move w=
hen returning a named local variable", but this is not always the case. Con=
sider:<div>
<br></div><div>std::unique_ptr&lt;const Foo&gt; FooFactory() {</div><div>&n=
bsp; std::unique_ptr&lt;Foo&gt; result(new Foo);</div><div>&nbsp; // ...</d=
iv><div>&nbsp; return std::move(result);</div><div>}</div><div><br></div><d=
iv>The "std::move" is mandatory here, because an lvalue can only be implici=
tly treated as an rvalue during copy operations, and in "return result;", '=
result' is not copied, but used as the input for an implicit conversion. It=
 seems like this should be fixable, perhaps by expanding the implicit-rvalu=
e rules, but I'm not sure what all the consequences would be (at a minimum,=
 this could change the behavior of existing code that has separate rvalue a=
nd lvalue overloads for an implicit conversion operation).</div>
<div><br></div><div>Conversely, it would be nice to be able to say "When in=
 doubt, just use std::move if you want move semantics, because it never hur=
ts", but std::move can in fact be a pessimization:</div><div>
<br></div><div>std::array&lt;Foo, 10000&gt; MakeHugeArray() {</div><div>&nb=
sp; std::array&lt;Foo, 10000&gt; result;</div><div>&nbsp; // ...</div><div>=
&nbsp; return std::move(result);</div><div>}</div><div><br></div><div>As wr=
itten, the return statement incurs 10,000 invocations of Foo's move constru=
ctor (or, worse, its copy constructor), but if std::move is eliminated, the=
 return statement becomes effectively free, because it's an elidable copy/m=
ove. In this case it's not at all clear to me how to fix the problem; it se=
ems like a fix would either require special-casing std::move (which seems l=
ike a hack, and breaks the convention that the core-language standard tries=
 not to refer to the library standard), or require the implementation to 's=
ee into' the implementation of a function called in a return statement (whi=
ch seems impractical).&nbsp;</div>
<div><br></div><div>I think it's worth trying to fix these issues, despite =
the difficulties, because being able to provide reliable "rules of thumb" w=
ould substantially improve the learning curve for std::move. Can anyone sug=
gest how these issues could be fixed?<br>
</div></div>
</blockquote></div>

<p></p>

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

------=_Part_819_28922083.1403893330951--

.

--001a11c295723d2ba204fcd686ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 26, 2014 at 6:17 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2013=E2=80=9306=E2=80=9325, at 2:42 AM, Geoffrey Romer <gromer@google.=
com> wrote:
>
> It's surprisingly hard to come up with a good, teachable set of rules for
> when to use std::move. For example, it would be nice to be able to say "y=
ou
> can leave out std::move when returning a named local variable", but this =
is
> not always the case.
>
>
> That doesn=E2=80=99t sound like something that should be taught. Students
> shouldn=E2=80=99t have the impression that they should avoid move, or omi=
t it just
> because they can.
>

Really? You wouldn't even teach students to omit move in an expression like
this?

Sink(std::move(Source()));


> Conversely, it would be nice to be able to say "When in doubt, just use
> std::move if you want move semantics, because it never hurts", but
> std::move can in fact be a pessimization:
>
> std::array<Foo, 10000> MakeHugeArray() {
>   std::array<Foo, 10000> result;
>   // ...
>   return std::move(result);
> }
>
> As written, the return statement incurs 10,000 invocations of Foo's move
> constructor (or, worse, its copy constructor), but if std::move is
> eliminated, the return statement becomes effectively free, because it's a=
n
> elidable copy/move.
>
>
> I'm pretty sure there=E2=80=99s a DR for this. First-draft code doesn=E2=
=80=99t need to
> run full speed anyway. Students should learn general techniques for findi=
ng
> bottlenecks, not every performance quirk and pitfall.
>

The best way to avoid teaching performance quirks and pitfalls is to
eliminate them from the language. Failing that, students will have to learn
them eventually, although you can haggle over when.


> When fixing this code, it would be a good idea to add a comment that the
> result is expected to be constructed in-place, hence neither moved nor
> copied.
>
> By the way, this code is still giving you exactly what you asked for.
> Asking for a move when you actually want copy elision is, though
> reasonable, a confusion of two completely different things.
>

Can you give an example of when a programmer would not want a copy elision?


>
> In this case it's not at all clear to me how to fix the problem; it seems
> like a fix would either require special-casing std::move (which seems lik=
e
> a hack, and breaks the convention that the core-language standard tries n=
ot
> to refer to the library standard), or require the implementation to 'see
> into' the implementation of a function called in a return statement (whic=
h
> seems impractical).
>
>
> It may be doable for inline functions. Perhaps some future language
> iteration will see through the thicket.
>
> I think it's worth trying to fix these issues, despite the difficulties,
> because being able to provide reliable "rules of thumb" would substantial=
ly
> improve the learning curve for std::move. Can anyone suggest how these
> issues could be fixed?
>
>
> Say move() when you want a move.
>

That's just begging the question; I'm trying to teach people how to know
when they should want a move


> Debug the rest, and be aware that moves still carry a cost which may be a=
s
> much as a copy.
>

Would you say, then, that one should never apply std::move to a copyable
type?


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

--=20

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

--001a11c295723d2ba204fcd686ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jun 26, 2014 at 6:17 PM, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2013=E2=80=9306=E2=80=9325, at 2:42 AM, Geoffrey R=
omer &lt;<a href=3D"mailto:gromer@google.com" target=3D"_blank">gromer@goog=
le.com</a>&gt; wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr">It&#39;s surprisingly hard t=
o come up with a good, teachable set of rules for when to use std::move. Fo=
r example, it would be nice to be able to say &quot;you can leave out std::=
move when returning a named local variable&quot;, but this is not always th=
e case. </div>
</blockquote><div><br></div></div><div>That doesn=E2=80=99t sound like some=
thing that should be taught. Students shouldn=E2=80=99t have the impression=
 that they should avoid move, or omit it just because they can.</div></div>=
</div></blockquote>
<div><br></div><div>Really? You wouldn&#39;t even teach students to omit mo=
ve in an expression like this?</div><div><br></div><div>Sink(std::move(Sour=
ce()));</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div class=3D""><br><blockquote ty=
pe=3D"cite"><div dir=3D"ltr"><div>Conversely, it would be nice to be able t=
o say &quot;When in doubt, just use std::move if you want move semantics, b=
ecause it never hurts&quot;, but std::move can in fact be a pessimization:<=
/div>
<div>
<br></div><div>std::array&lt;Foo, 10000&gt; MakeHugeArray() {</div><div>=C2=
=A0 std::array&lt;Foo, 10000&gt; result;</div><div>=C2=A0 // ...</div><div>=
=C2=A0 return std::move(result);</div><div>}</div><div><br></div><div>As wr=
itten, the return statement incurs 10,000 invocations of Foo&#39;s move con=
structor (or, worse, its copy constructor), but if std::move is eliminated,=
 the return statement becomes effectively free, because it&#39;s an elidabl=
e copy/move. </div>
</div></blockquote><div><br></div></div><div>I&#39;m pretty sure there=E2=
=80=99s a DR for this. First-draft code doesn=E2=80=99t need to run full sp=
eed anyway. Students should learn general techniques for finding bottleneck=
s, not every performance quirk and pitfall.</div>
</div></div></blockquote><div><br></div><div>The best way to avoid teaching=
 performance quirks and pitfalls is to eliminate them from the language. Fa=
iling that, students will have to learn them eventually, although you can h=
aggle over when.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div><div> When fixing this code, it would be a good idea to add a=
 comment that the result is expected to be constructed in-place, hence neit=
her moved nor copied.</div>
<div><br></div><div>By the way, this code is still giving you exactly what =
you asked for. Asking for a move when you actually want copy elision is, th=
ough reasonable, a confusion of two completely different things.</div></div=
>
</div></blockquote><div><br></div><div>Can you give an example of when a pr=
ogrammer would not want a copy elision?</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div class=3D""><br><blockquote ty=
pe=3D"cite"><div dir=3D"ltr"><div>In this case it&#39;s not at all clear to=
 me how to fix the problem; it seems like a fix would either require specia=
l-casing std::move (which seems like a hack, and breaks the convention that=
 the core-language standard tries not to refer to the library standard), or=
 require the implementation to &#39;see into&#39; the implementation of a f=
unction called in a return statement (which seems impractical).=C2=A0</div>
</div></blockquote><div><br></div></div><div>It may be doable for inline fu=
nctions. Perhaps some future language iteration will see through the thicke=
t.</div><div class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr">
<div>I think it&#39;s worth trying to fix these issues, despite the difficu=
lties, because being able to provide reliable &quot;rules of thumb&quot; wo=
uld substantially improve the learning curve for std::move. Can anyone sugg=
est how these issues could be fixed?</div>
</div></blockquote><br></div></div><div>Say <font face=3D"Courier">move()</=
font> when you want a move. </div></div></blockquote><div><br></div><div>Th=
at&#39;s just begging the question; I&#39;m trying to teach people how to k=
now when they should want a move</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div>Debug the rest, and be aware that moves still carry a cost wh=
ich may be as much as a copy.=C2=A0</div>
</div></blockquote><div><br></div><div>Would you say, then, that one should=
 never apply std::move to a copyable type?</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><br></div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a11c295723d2ba204fcd686ae--

.

--Apple-Mail=_86B416BA-23C9-4A36-A216-1EA192BC5B5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-28, at 3:43 AM, 'Geoffrey Romer' via ISO C++ Standard - Future P=
roposals <std-proposals@isocpp.org> wrote:

>=20
> On Thu, Jun 26, 2014 at 6:17 PM, David Krauss <potswa@gmail.com> wrote:
>=20
> That doesn't sound like something that should be taught. Students shouldn=
't have the impression that they should avoid move, or omit it just because=
 they can.
>=20
> Really? You wouldn't even teach students to omit move in an expression li=
ke this?
>=20
> Sink(std::move(Source()));

That's going a bit far. Students should know that move casts an object-sema=
ntic lvalue into a value-semantic rvalue, and application to an rvalue is a=
lways redundant. But that's not avoiding it, or opportunistic omission, it =
follows from the underlying theory.

> When fixing this code, it would be a good idea to add a comment that the =
result is expected to be constructed in-place, hence neither moved nor copi=
ed.
>=20
> By the way, this code is still giving you exactly what you asked for. Ask=
ing for a move when you actually want copy elision is, though reasonable, a=
 confusion of two completely different things.
>=20
> Can you give an example of when a programmer would not want a copy elisio=
n?

It's an optimization, not a choice. Teaching its interaction with moving is=
 asks the student to think about two theories at once, which almost by defi=
nition relegates it to a more advanced course.=20

> Say move() when you want a move.
>=20
> That's just begging the question; I'm trying to teach people how to know =
when they should want a move

I mean, say move() when you want an ownership transfer.

> Debug the rest, and be aware that moves still carry a cost which may be a=
s much as a copy.=20
>=20
> Would you say, then, that one should never apply std::move to a copyable =
type?

Absolutely not. For one thing, that often happens in generic programming. I=
 simply mean that while chasing performance bugs, after the fact of writing=
 a first draft, code with move semantics should not be dismissed out of han=
d as "already fast."

--=20

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

--Apple-Mail=_86B416BA-23C9-4A36-A216-1EA192BC5B5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;28, at 3:43 AM, 'Geoffrey Romer' via ISO C++ Standard - Futu=
re Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr" style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><br class=3D"Apple-interchange-newline=
">On Thu, Jun 26, 2014 at 6:17 PM, David Krauss<span class=3D"Apple-convert=
ed-space">&nbsp;</span><span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail=
..com" target=3D"_blank">potswa@gmail.com</a>&gt;</span><span class=3D"Apple=
-converted-space">&nbsp;</span>wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-col=
or: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; positi=
on: static; z-index: auto;"><div style=3D"word-wrap: break-word;"><br><div>=
<div class=3D""><div>That doesn&rsquo;t sound like something that should be=
 taught. Students shouldn&rsquo;t have the impression that they should avoi=
d move, or omit it just because they can.</div></div></div></div></blockquo=
te><div><br></div><div>Really? You wouldn't even teach students to omit mov=
e in an expression like this?</div><div><br></div><div>Sink(std::move(Sourc=
e()));</div></div></div></div></blockquote><div><br></div><div>That&rsquo;s=
 going a bit far. Students should know that move casts an object-semantic l=
value into a value-semantic rvalue, and application to an rvalue is always =
redundant. But that&rsquo;s not avoiding it, or opportunistic omission, it =
follows from the underlying theory.</div><br><blockquote type=3D"cite"><div=
 dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px;"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;"><div style=3D"word-wrap: break-word=
;"><div>When fixing this code, it would be a good idea to add a comment tha=
t the result is expected to be constructed in-place, hence neither moved no=
r copied.</div><div><br></div><div>By the way, this code is still giving yo=
u exactly what you asked for. Asking for a move when you actually want copy=
 elision is, though reasonable, a confusion of two completely different thi=
ngs.</div></div></blockquote><div><br></div><div>Can you give an example of=
 when a programmer would not want a copy elision?</div></div></div></div></=
blockquote><div><br></div><div>It&rsquo;s an optimization, not a choice. Te=
aching its interaction with moving is asks the student to think about two t=
heories at once, which almost by definition relegates it to a more advanced=
 course.&nbsp;</div><div><br></div><blockquote type=3D"cite"><div dir=3D"lt=
r" style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex; position: static; z-index: auto;"><div style=
=3D"word-wrap: break-word;"><div>Say<span class=3D"Apple-converted-space">&=
nbsp;</span><font face=3D"Courier">move()</font><span class=3D"Apple-conver=
ted-space">&nbsp;</span>when you want a move.</div></div></blockquote><div>=
<br></div><div>That's just begging the question; I'm trying to teach people=
 how to know when they should want a move</div></div></div></div></blockquo=
te><div><br></div><div>I mean, say move() when you want an ownership transf=
er.</div><br><blockquote type=3D"cite"><div dir=3D"ltr" style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bo=
rder-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left=
: 1ex;"><div style=3D"word-wrap: break-word;">Debug the rest, and be aware =
that moves still carry a cost which may be as much as a copy.&nbsp;</div></=
blockquote><div><br></div><div>Would you say, then, that one should never a=
pply std::move to a copyable type?</div></div></div></div></blockquote><br>=
</div><div>Absolutely not. For one thing, that often happens in generic pro=
gramming. I simply mean that while chasing performance bugs, after the fact=
 of writing a first draft, code with move semantics should not be dismissed=
 out of hand as &ldquo;already fast.&rdquo;</div><div><br></div></body></ht=
ml>

<p></p>

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

--Apple-Mail=_86B416BA-23C9-4A36-A216-1EA192BC5B5E--

.

--001a1134eda87d948604fcd994cb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 27, 2014 at 3:30 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9306=E2=80=9328, at 3:43 AM, 'Geoffrey Romer' via ISO C++ S=
tandard - Future
> Proposals <std-proposals@isocpp.org> wrote:
>
>
> On Thu, Jun 26, 2014 at 6:17 PM, David Krauss <potswa@gmail.com> wrote:
>
>>
>> That doesn=E2=80=99t sound like something that should be taught. Student=
s
>> shouldn=E2=80=99t have the impression that they should avoid move, or om=
it it just
>> because they can.
>>
>
> Really? You wouldn't even teach students to omit move in an expression
> like this?
>
> Sink(std::move(Source()));
>
>
> That=E2=80=99s going a bit far. Students should know that move casts an
> object-semantic lvalue into a value-semantic rvalue, and application to a=
n
> rvalue is always redundant. But that=E2=80=99s not avoiding it, or opport=
unistic
> omission, it follows from the underlying theory.
>

I'm curious; if you don't think students should be taught about this
option, do you think it was a mistake for the language to go so far out of
its way (q.v. [class.copy]/p32) to enable it?

In any event, this is a moot point. C++14 resolves the defect I was
referring to here, so we _can_ now teach that you can always omit std::move
when returning a variable that's local to the scope you're returning from.


>
> When fixing this code, it would be a good idea to add a comment that the
>> result is expected to be constructed in-place, hence neither moved nor
>> copied.
>>
>> By the way, this code is still giving you exactly what you asked for.
>> Asking for a move when you actually want copy elision is, though
>> reasonable, a confusion of two completely different things.
>>
>
> Can you give an example of when a programmer would not want a copy elisio=
n?
>
>
> It=E2=80=99s an optimization, not a choice. Teaching its interaction with=
 moving
> is asks the student to think about two theories at once, which almost by
> definition relegates it to a more advanced course.
>

Yes, which is exactly I don't want it to have _any_ interaction with
moving, so that I don't have to teach about that interaction.


> Say move() when you want a move.
>>
>
> That's just begging the question; I'm trying to teach people how to know
> when they should want a move
>
>
> I mean, say move() when you want an ownership transfer.
>

"Ownership" normally refers to the responsibility to explicitly invoke a
cleanup operation (cf. [unique.ptr]/p1), and so doesn't apply to many
situations where move() is appropriate, or even necessary. It's possible to
generalize the notion of ownership so that it applies to those situations
too, but at that point "ownership transfer" becomes basically synonymous
with move, and your advice again becomes circular.

This rule also doesn't account for the Sink(Source()) example above.


>
> Debug the rest, and be aware that moves still carry a cost which may be a=
s
>> much as a copy.
>>
>
> Would you say, then, that one should never apply std::move to a copyable
> type?
>
>
> Absolutely not. For one thing, that often happens in generic programming.
> I simply mean that while chasing performance bugs, after the fact of
> writing a first draft, code with move semantics should not be dismissed o=
ut
> of hand as =E2=80=9Calready fast.=E2=80=9D
>

Oh, I certainly agree with that; my goal is to reduce the number of
performance bugs that people write (or fear they will write) in the first
place.


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

--=20

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

--001a1134eda87d948604fcd994cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Fri, Jun 27, 2014 at 3:30 PM, David Krauss <span dir=3D"ltr">&lt;<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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 style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9306=E2=80=9328, at 3:43 AM, &#39;Geoff=
rey Romer&#39; via ISO C++ Standard - Future Proposals &lt;<a href=3D"mailt=
o:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&=
gt; wrote:</div>
<br></div><blockquote type=3D"cite"><div dir=3D"ltr" style=3D"font-family:H=
elvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:n=
ormal;letter-spacing:normal;line-height:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br>O=
n Thu, Jun 26, 2014 at 6:17 PM, David Krauss<span>=C2=A0</span><span dir=3D=
"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmai=
l.com</a>&gt;</span><span>=C2=A0</span>wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div class=
=3D"">
<div><div><div>That doesn=E2=80=99t sound like something that should be tau=
ght. Students shouldn=E2=80=99t have the impression that they should avoid =
move, or omit it just because they can.</div></div></div></div></div></bloc=
kquote><div class=3D"">
<div><br></div><div>Really? You wouldn&#39;t even teach students to omit mo=
ve in an expression like this?</div><div><br></div><div>Sink(std::move(Sour=
ce()));</div></div></div></div></div></blockquote><div><br></div><div>That=
=E2=80=99s going a bit far. Students should know that move casts an object-=
semantic lvalue into a value-semantic rvalue, and application to an rvalue =
is always redundant. But that=E2=80=99s not avoiding it, or opportunistic o=
mission, it follows from the underlying theory.</div>
</div></div></blockquote><div><br></div><div>I&#39;m curious; if you don&#3=
9;t think students should be taught about this option, do you think it was =
a mistake for the language to go so far out of its way (q.v. [class.copy]/p=
32) to enable it?</div>
<div><br></div><div>In any event, this is a moot point. C++14 resolves the =
defect I was referring to here, so we _can_ now teach that you can always o=
mit std::move when returning a variable that&#39;s local to the scope you&#=
39;re returning from.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div><div class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr=
" style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-vari=
ant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp=
acing:0px">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
 style=3D"word-wrap:break-word">
<div>When fixing this code, it would be a good idea to add a comment that t=
he result is expected to be constructed in-place, hence neither moved nor c=
opied.</div><div><br></div><div>By the way, this code is still giving you e=
xactly what you asked for. Asking for a move when you actually want copy el=
ision is, though reasonable, a confusion of two completely different things=
..</div>
</div></blockquote><div><br></div><div>Can you give an example of when a pr=
ogrammer would not want a copy elision?</div></div></div></div></blockquote=
><div><br></div></div><div>It=E2=80=99s an optimization, not a choice. Teac=
hing its interaction with moving is asks the student to think about two the=
ories at once, which almost by definition relegates it to a more advanced c=
ourse.=C2=A0</div>
</div></div></blockquote><div><br></div><div>Yes, which is exactly I don&#3=
9;t want it to have _any_ interaction with moving, so that I don&#39;t have=
 to teach about that interaction.</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<div style=3D"word-wrap:break-word"><div><div class=3D""><div><br></div><bl=
ockquote type=3D"cite"><div dir=3D"ltr" style=3D"font-family:Helvetica;font=
-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-=
spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
 style=3D"word-wrap:break-word">
<div>Say<span>=C2=A0</span><font face=3D"Courier">move()</font><span>=C2=A0=
</span>when you want a move.</div></div></blockquote><div><br></div><div>Th=
at&#39;s just begging the question; I&#39;m trying to teach people how to k=
now when they should want a move</div>
</div></div></div></blockquote><div><br></div></div><div>I mean, say move()=
 when you want an ownership transfer.</div></div></div></blockquote><div><b=
r></div><div>&quot;Ownership&quot; normally refers to the responsibility to=
 explicitly invoke a cleanup operation (cf. [unique.ptr]/p1), and so doesn&=
#39;t apply to many situations where move() is appropriate, or even necessa=
ry. It&#39;s possible to generalize the notion of ownership so that it appl=
ies to those situations too, but at that point &quot;ownership transfer&quo=
t; becomes basically synonymous with move, and your advice again becomes ci=
rcular.</div>
<div><br></div><div>This rule also doesn&#39;t account for the Sink(Source(=
)) example above.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 style=3D"word-wrap:break-word">
<div><div class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr" style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
 style=3D"word-wrap:break-word">
Debug the rest, and be aware that moves still carry a cost which may be as =
much as a copy.=C2=A0</div></blockquote><div><br></div><div>Would you say, =
then, that one should never apply std::move to a copyable type?</div></div>=
</div>
</div></blockquote><br></div></div><div>Absolutely not. For one thing, that=
 often happens in generic programming. I simply mean that while chasing per=
formance bugs, after the fact of writing a first draft, code with move sema=
ntics should not be dismissed out of hand as =E2=80=9Calready fast.=E2=80=
=9D</div>
</div></blockquote><div><br></div><div>Oh, I certainly agree with that; my =
goal is to reduce the number of performance bugs that people write (or fear=
 they will write) in the first place.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div style=3D"word-wrap:break-word"><div><br></div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a1134eda87d948604fcd994cb--

.

--Apple-Mail=_FC5310D2-CF16-4562-A6FF-6D18F8D69234
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-28, at 7:22 AM, 'Geoffrey Romer' via ISO C++ Standard - Future P=
roposals <std-proposals@isocpp.org> wrote:

> On Fri, Jun 27, 2014 at 3:30 PM, David Krauss <potswa@gmail.com> wrote:
>=20
> That's going a bit far. Students should know that move casts an object-se=
mantic lvalue into a value-semantic rvalue, and application to an rvalue is=
 always redundant. But that's not avoiding it, or opportunistic omission, i=
t follows from the underlying theory.
>=20
> I'm curious; if you don't think students should be taught about this opti=
on, do you think it was a mistake for the language to go so far out of its =
way (q.v. [class.copy]/p32) to enable it?

[class.copy]/32 specifies that copy elision "failure" shall decay to a move=
.. That's a way of obtaining a lesser opportunistic optimization, as gradual=
 degradation.

I didn't say students shouldn't be taught about anything. I merely recommen=
d an order of curriculum:

1. Rvalues and lvalues (why and how you are prevented from assigning 1 =3D =
3). Value semantics vs object semantics: refer to functional and imperative=
 programming paradigms.
2. move() is used to constrain an object to temporarily behave more like a =
pure value.
-- Perhaps some time later in the course --
3. Copy elision: object semantics may be ignored if they get in the way. Th=
e compiler hacks a chain of transitively initialized objects to be identica=
lly the same object.
4. The compiler is allowed to use move semantics as an inferior substitute =
for copy elision. (In fact, it must use this fallback.)

Students should never be taught to use an opportunistic optimization as if =
it were a means of expression. It's slightly unfortunate that there is no e=
xplicit way to express copy elision. If there's a problem with the language=
, it's the lack of an explicit require_copy_elide operator. (I don't take t=
hat seriously.)

> In any event, this is a moot point. C++14 resolves the defect I was refer=
ring to here, so we _can_ now teach that you can always omit std::move when=
 returning a variable that's local to the scope you're returning from.

What you do in your classroom is your business. I would prefer to work with=
 people who don't try to omit anything that they mean. (Of course, meaning =
should be kept to a zen minimum.) Please, encourage students to write comme=
nts.

> It's an optimization, not a choice. Teaching its interaction with moving =
is asks the student to think about two theories at once, which almost by de=
finition relegates it to a more advanced course.=20
>=20
> Yes, which is exactly I don't want it to have _any_ interaction with movi=
ng, so that I don't have to teach about that interaction.

The easiest thing to do is to not teach about optimizations. They are nice,=
 but complicated, things the compiler does for you. Copy elision can be put=
 in the same bucket as loop unrolling, function inlining, loop-invariant co=
de motion.

Copy elision happens not to be covered by the as-if rule, hence its mention=
 in the standard. But unexpected failure of a constructor to run is a quirk=
, not a feature. In that sense, you only need to tell students that copy/mo=
ve constructors should not have side effects because they may be skipped, b=
ut there's no need to explain when or why.

> "Ownership" normally refers to the responsibility to explicitly invoke a =
cleanup operation (cf. [unique.ptr]/p1), and so doesn't apply to many situa=
tions where move() is appropriate, or even necessary. It's possible to gene=
ralize the notion of ownership so that it applies to those situations too, =
but at that point "ownership transfer" becomes basically synonymous with mo=
ve, and your advice again becomes circular.

Perhaps my meaning hasn't come across. You might ask (or find an existing a=
nswer) on StackOverflow. Maybe the object vs value semantic idea is better.=
 The important thing is to settle on something you're comfortable explainin=
g to the class. But, I assure you that there's clear distinction, and it's =
not only a matter of getting the desired constructor to be called.

> Oh, I certainly agree with that; my goal is to reduce the number of perfo=
rmance bugs that people write (or fear they will write) in the first place.

That's a dangerous path. Performance bugs aren't avoided. Knowledge of algo=
rithms and structures is sufficient to produce a program which, once ironed=
 out using a profiler, will be optimal. Students need to know how to operat=
e a profiler and how to interpret a program's interaction with the machine =
architecture. They should *not* be encouraged to get hung up on language qu=
irks.

The physical machine is what goes fast, not the C++ virtual machine!

--=20

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

--Apple-Mail=_FC5310D2-CF16-4562-A6FF-6D18F8D69234
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;28, at 7:22 AM, 'Geoffrey Romer' via ISO C++ Standard - Futu=
re Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, Jun 27, 20=
14 at 3:30 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@=
gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D=
"word-wrap:break-word"><br><div><div>That&rsquo;s going a bit far. Students=
 should know that move casts an object-semantic lvalue into a value-semanti=
c rvalue, and application to an rvalue is always redundant. But that&rsquo;=
s not avoiding it, or opportunistic omission, it follows from the underlyin=
g theory.</div>
</div></div></blockquote><div><br></div><div>I'm curious; if you don't thin=
k students should be taught about this option, do you think it was a mistak=
e for the language to go so far out of its way (q.v. [class.copy]/p32) to e=
nable it?</div></div></div></div></blockquote><div><br></div><div>[class.co=
py]/32 specifies that copy elision &ldquo;failure&rdquo; shall decay to a m=
ove. That&rsquo;s a way of obtaining a lesser opportunistic optimization, a=
s gradual degradation.</div><div><br></div><div>I didn&rsquo;t say students=
 shouldn&rsquo;t be taught about anything. I merely recommend an order of c=
urriculum:</div><div><br></div><div>1. Rvalues and lvalues (why and how you=
 are prevented from assigning <font face=3D"Courier">1 =3D 3</font>). Value=
 semantics vs object semantics: refer to functional and imperative programm=
ing paradigms.</div><div>2. move() is used to constrain an object to tempor=
arily behave more like a pure value.</div><div>&mdash; Perhaps some time la=
ter in the course &mdash;</div><div>3. Copy elision: object semantics may b=
e ignored if they get in the way. The compiler hacks a chain of transitivel=
y initialized objects to be identically the same object.</div><div>4. The c=
ompiler is allowed to use move semantics as an inferior substitute for copy=
 elision. (In fact, it must use this fallback.)</div><div><br></div><div>St=
udents should never be taught to use an opportunistic optimization as if it=
 were a means of expression. It&rsquo;s slightly unfortunate that there is =
no explicit way to express copy elision. If there&rsquo;s a problem with th=
e language, it&rsquo;s the lack of an explicit <font face=3D"Courier">requi=
re_copy_elide</font> operator. (I don&rsquo;t take that seriously.)</div><b=
r><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<div>In any event, this is a moot point. C++14 resolves the defect I was re=
ferring to here, so we _can_ now teach that you can always omit std::move w=
hen returning a variable that's local to the scope you're returning from.</=
div></div></div></div></blockquote><div><br></div><div>What you do in your =
classroom is your business. I would prefer to work with people who don&rsqu=
o;t try to omit anything that they mean. (Of course, meaning should be kept=
 to a zen minimum.) Please, encourage students to write comments.</div><br>=
<blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D=
"word-wrap:break-word"><div>It&rsquo;s an optimization, not a choice. Teach=
ing its interaction with moving is asks the student to think about two theo=
ries at once, which almost by definition relegates it to a more advanced co=
urse.&nbsp;</div>
</div></blockquote><div><br></div><div>Yes, which is exactly I don't want i=
t to have _any_ interaction with moving, so that I don't have to teach abou=
t that interaction.</div></div></div></div></blockquote><div><br></div><div=
>The easiest thing to do is to not teach about optimizations. They are nice=
, but complicated, things the compiler does for you. Copy elision can be pu=
t in the same bucket as loop unrolling, function inlining, loop-invariant c=
ode motion.</div><div><br></div><div>Copy elision happens not to be covered=
 by the as-if rule, hence its mention in the standard. But unexpected failu=
re of a constructor to run is a quirk, not a feature. In that sense, you on=
ly need to tell students that copy/move constructors should not have side e=
ffects because they may be skipped, but there&rsquo;s no need to explain wh=
en or why.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>"Ownership" normally refer=
s to the responsibility to explicitly invoke a cleanup operation (cf. [uniq=
ue.ptr]/p1), and so doesn't apply to many situations where move() is approp=
riate, or even necessary. It's possible to generalize the notion of ownersh=
ip so that it applies to those situations too, but at that point "ownership=
 transfer" becomes basically synonymous with move, and your advice again be=
comes circular.</div></div></div></div></blockquote><div><br></div><div>Per=
haps my meaning hasn&rsquo;t come across. You might ask (or find an existin=
g answer) on StackOverflow. Maybe the object vs value semantic idea is bett=
er. The important thing is to settle on something you&rsquo;re comfortable =
explaining to the class. But, I assure you that there's clear distinction, =
and it&rsquo;s not only a matter of getting the desired constructor to be c=
alled.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote">
<div>Oh, I certainly agree with that; my goal is to reduce the number of pe=
rformance bugs that people write (or fear they will write) in the first pla=
ce.</div></div></div></div></blockquote><div><br></div></div>That&rsquo;s a=
 dangerous path. Performance bugs aren&rsquo;t avoided. Knowledge of algori=
thms and structures is sufficient to produce a program which, once ironed o=
ut using a profiler, will be optimal. Students need to know how to operate =
a profiler and how to interpret a program&rsquo;s interaction with the mach=
ine architecture. They should *<i>not</i>* be encouraged to get hung up on =
language quirks.<br><div><br></div><div>The physical machine is what goes f=
ast, not the C++ virtual machine!</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_FC5310D2-CF16-4562-A6FF-6D18F8D69234--

.