220 11580 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Teachability problems with std::move Date: Fri, 27 Jun 2014 09:17:27 +0800 Lines: 140 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A4CC440-FD0D-4886-ADF7-23F0E6DA759D" X-Trace: ger.gmane.org 1403831855 22736 80.91.229.3 (27 Jun 2014 01:17:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 01:17:35 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBJMMWOOQKGQEEAMUXLA@isocpp.org Fri Jun 27 03:17:28 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f197.google.com ([209.85.128.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0Kn9-0004zE-34 for gclcip-std-proposals@m.gmane.org; Fri, 27 Jun 2014 03:17:27 +0200 Original-Received: by mail-ve0-f197.google.com with SMTP id jz11sf8699521veb.8 for ; Thu, 26 Jun 2014 18:17:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-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=dhoWj5BmjW2qTPNFkmfFxsMoKcM9pMX3yxAudXdvbkk=; b=L6/T2SnuUREsVyVaQolcbL/qbbap/G29i64F5vnFlM/gAlBAyQGmwYAOf4VBv8gOkm +VsIfdweBmWm+vo3DpVnARAqRCcjYp6ewBulzxyHuZuDX3xlwZK8/JsuOeFqmeZUmiWF Q1pZWufFtGt058WAy7Q9xIOdIKMB2n8Zp1hBPGBHBvfZZVcI9k2rrA5Hs11zS5bS494g 4T1LWfWnUfvSRmwXuOqi4YzzbFUu0QmFkoCzeQbNVLygjPFzpVfR0ef60LwYZiHWs9nh fXTmu/pyU9UIy4DEH42okXzeA7fB0rWU4AWZ8frzPrNK0E+BSyH9R5dvplakQirDEDRh KDqw== X-Gm-Message-State: ALoCoQnnT29hGmiiWdZX2CBlvBEYhb/Zjq6d+JPB8G8CC7bLpOPFffrh/sooIcmY/BtisM9jsXfU X-Received: by 10.58.151.238 with SMTP id ut14mr9872210veb.11.1403831846153; Thu, 26 Jun 2014 18:17:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.40.37 with SMTP id u5ls68647igk.22.gmail; Thu, 26 Jun 2014 18:17:25 -0700 (PDT) X-Received: by 10.42.210.74 with SMTP id gj10mr17730232icb.46.1403831845011; Thu, 26 Jun 2014 18:17:25 -0700 (PDT) Original-Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [2607:f8b0:4001:c03::22c]) by mx.google.com with ESMTPS id um8si13904657icb.69.2014.06.26.18.17.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 18:17:25 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::22c as permitted sender) client-ip=2607:f8b0:4001:c03::22c; Original-Received: by mail-ie0-f172.google.com with SMTP id lx4so3829744iec.3 for ; Thu, 26 Jun 2014 18:17:24 -0700 (PDT) X-Received: by 10.50.12.38 with SMTP id v6mr8431389igb.29.1403831844695; Thu, 26 Jun 2014 18:17:24 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.156]) by mx.google.com with ESMTPSA id v9sm9035526igd.14.2014.06.26.18.17.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 18:17:24 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::22c as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.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: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11580 Archived-At: --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 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 MakeHugeArray() { > std::array 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
On 2013&= ndash;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::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.

That doesn’t sound like s= omething that should be taught. Students shouldn’t have the impressio= n that they should avoid move, or omit it just because they can.

<= blockquote type=3D"cite">
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:

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

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.

I'm pretty sure there&rsq= uo;s a DR for this. First-draft code doesn’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.

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.

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

=
It may be doable for inline functions. Perhaps some future langu= age iteration will see through the thicket.

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?

Say move() 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.

--

---
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>.
--Apple-Mail=_5A4CC440-FD0D-4886-ADF7-23F0E6DA759D-- .