220 11588 article Path: news.gmane.org!not-for-mail From: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Teachability problems with std::move Date: Fri, 27 Jun 2014 12:43:32 -0700 Lines: 257 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c295723d2ba204fcd686ae X-Trace: ger.gmane.org 1403898223 15909 80.91.229.3 (27 Jun 2014 19:43:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 19:43:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD74DCN5SYHBBZESW6OQKGQEGIUBZQQ@isocpp.org Fri Jun 27 21:43:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0c3a-0005mQ-2G for gclcip-std-proposals@m.gmane.org; Fri, 27 Jun 2014 21:43:34 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id rd18sf31723220iec.2 for ; Fri, 27 Jun 2014 12:43:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=nkW9nMpXlRu1Yx5w89p0exr2mMtINmGsnCuyIPWiOsc=; b=EQ2T6tSZXxiaMEwP6zk+Un5z22+9a00bflCd7aq1Ryfx3HhUx3Tzl+qh+blGQOyCN0 uA+gZmmp59LQsVHFhnJHNts5yH/zJhZbDPyaGYAMh3TMORWWXiufxbpoCmyYf9liTtJ/ PzsdWr+A2WrMynonNP696bXqTNM+5SuVEVkcybAsTvSIGRZAm/C+R20Iiuo59zFIKY7G PRGGwwdFzeD+7oyKD3JRCDzOziNKU0mjAowGuRu/K0XAutEFPufUDJEQW79JCKu6myk7 p5oxy5uTxlZ3RAVfIFUK9E8Y14nE6m0W1PfAuaoVSe+jeEOuSSUT+TJBpnOGyHkh5ulO zQSA== X-Gm-Message-State: ALoCoQkff5rYw36UZqTTjWKMlMoqj9/SX41JPHkAWs5VWqFiorphmKDX8HxB/sth/2bl/dLUZlde X-Received: by 10.182.148.1 with SMTP id to1mr12441477obb.50.1403898213181; Fri, 27 Jun 2014 12:43:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.84.72 with SMTP id k66ls769009qgd.96.gmail; Fri, 27 Jun 2014 12:43:32 -0700 (PDT) X-Received: by 10.140.22.134 with SMTP id 6mr34066710qgn.4.1403898212437; Fri, 27 Jun 2014 12:43:32 -0700 (PDT) Original-Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [2607:f8b0:400d:c04::22e]) by mx.google.com with ESMTPS id k6si15112152qct.2.2014.06.27.12.43.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 12:43:32 -0700 (PDT) Received-SPF: pass (google.com: domain of gromer@google.com designates 2607:f8b0:400d:c04::22e as permitted sender) client-ip=2607:f8b0:400d:c04::22e; Original-Received: by mail-qg0-f46.google.com with SMTP id q107so4702057qgd.5 for ; Fri, 27 Jun 2014 12:43:32 -0700 (PDT) X-Received: by 10.224.131.74 with SMTP id w10mr37296831qas.100.1403898212176; Fri, 27 Jun 2014 12:43:32 -0700 (PDT) Original-Received: by 10.96.223.131 with HTTP; Fri, 27 Jun 2014 12:43:32 -0700 (PDT) In-Reply-To: X-Original-Sender: gromer@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gromer@google.com designates 2607:f8b0:400d:c04::22e as permitted sender) smtp.mail=gromer@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , X-Original-From: Geoffrey Romer Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11588 Archived-At: --001a11c295723d2ba204fcd686ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 26, 2014 at 6:17 PM, David Krauss wrote: > > On 2013=E2=80=9306=E2=80=9325, at 2:42 AM, Geoffrey Romer 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 MakeHugeArray() { > std::array 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

= 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 R= omer <gromer@goog= le.com> wrote:

It'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 "you can leave out std::= move when returning a named local variable", but this is not always th= e case.

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

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

Sink(std::move(Sour= ce()));


Conversely, it would be nice to be able t= o say "When in doubt, just use std::move if you want move semantics, b= ecause it never hurts", but std::move can in fact be a pessimization:<= /div>

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

As wr= itten, the return statement incurs 10,000 invocations of Foo's move con= structor (or, worse, its copy constructor), but if std::move is eliminated,= the return statement becomes effectively free, because it's an elidabl= e 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 sp= eed anyway. Students should learn general techniques for finding bottleneck= s, not every performance quirk and pitfall.

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.
=C2=A0
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.

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.

Can you give an example of when a pr= ogrammer would not want a copy elision?
=C2=A0

In this case it'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 'see into' the implementation of a f= unction called in a return statement (which seems impractical).=C2=A0

It may be doable for inline fu= nctions. Perhaps some future language iteration will see through the thicke= t.

I think it's worth trying to fix these issues, despite the difficu= lties, because being able to provide reliable "rules of thumb" wo= uld substantially improve the learning curve for std::move. Can anyone sugg= est how these issues could be fixed?

Say move() when you want a move.

Th= at's just begging the question; I'm trying to teach people how to k= now when they should want a move
=C2=A0
Debug the rest, and be aware that moves still carry a cost wh= ich may be as much as a copy.=C2=A0

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

--

---
You received this message because you are subscribed to the Google Groups &= quot;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/gro= up/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
--001a11c295723d2ba204fcd686ae-- .