220 11590 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 16:22:16 -0700 Lines: 295 Approved: news@gmane.org Message-ID: References: <29988A30-548A-47F3-A275-9B6099329877@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134eda87d948604fcd994cb X-Trace: ger.gmane.org 1403911347 31191 80.91.229.3 (27 Jun 2014 23:22:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 23:22:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD74DCN5SYHBBKHZW6OQKGQEBEK5NFQ@isocpp.org Sat Jun 28 01:22:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0fTG-0001J0-Ix for gclcip-std-proposals@m.gmane.org; Sat, 28 Jun 2014 01:22:18 +0200 Original-Received: by mail-pd0-f199.google.com with SMTP id r10sf20798866pdi.6 for ; Fri, 27 Jun 2014 16:22:17 -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=uLyKjmF28QtGsYj0xz8iDtGnc4aX3GtEaF/Sn52eNfc=; b=ZK+BsVVvAQ8aBwl49+RnV6kXjCyUJ6pwVTG8HOTpfpH1WJG0ws9QeYOThZEyG6zLnN xH2+chnfhXg8sWEZZNzbGA02R0n7bAoJpYXCkJ3lbgZ3w28C7k1L5N15ay6W2OJc6X35 v9tdLNNs3kJqyLnjirpG8YQ7+j3Ad6yGgy1dxqq7lf3yuvzjemCCS2KHLkm3IhO2RG+Y gd0gA3KLDGsTZLsXNscyfWMvO5B83bZQsqyZGHVgtI4VWz17VVE92ABYPd5NuzomjD8c hUZJI7GnBaJuT7J56DhMf1FbecSUKZjPy/kK6amQbRbDqYD8cPs8qvMExc8ehCbwIXzc 6zXQ== X-Gm-Message-State: ALoCoQkYEQGsmmuETEiadHu78uM207Vjn0jfYgHG9Nojjc2u2rH2OgHsawdkfTL6kXJG4RK6tr89 X-Received: by 10.69.31.75 with SMTP id kk11mr11890689pbd.8.1403911337293; Fri, 27 Jun 2014 16:22:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.48.145 with SMTP id o17ls802090qga.37.gmail; Fri, 27 Jun 2014 16:22:16 -0700 (PDT) X-Received: by 10.140.34.55 with SMTP id k52mr35012104qgk.13.1403911336387; Fri, 27 Jun 2014 16:22:16 -0700 (PDT) Original-Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [2607:f8b0:400d:c04::229]) by mx.google.com with ESMTPS id p96si15877355qgp.2.2014.06.27.16.22.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 16:22:16 -0700 (PDT) Received-SPF: pass (google.com: domain of gromer@google.com designates 2607:f8b0:400d:c04::229 as permitted sender) client-ip=2607:f8b0:400d:c04::229; Original-Received: by mail-qg0-f41.google.com with SMTP id i50so103139qgf.14 for ; Fri, 27 Jun 2014 16:22:16 -0700 (PDT) X-Received: by 10.140.103.74 with SMTP id x68mr35348905qge.34.1403911336191; Fri, 27 Jun 2014 16:22:16 -0700 (PDT) Original-Received: by 10.96.223.131 with HTTP; Fri, 27 Jun 2014 16:22:16 -0700 (PDT) In-Reply-To: <29988A30-548A-47F3-A275-9B6099329877@gmail.com> 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::229 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:11590 Archived-At: --001a1134eda87d948604fcd994cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 27, 2014 at 3:30 PM, David Krauss wrote: > > On 2014=E2=80=9306=E2=80=9328, at 3:43 AM, 'Geoffrey Romer' via ISO C++ S= tandard - Future > Proposals wrote: > > > On Thu, Jun 26, 2014 at 6:17 PM, David Krauss 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


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, 'Geoff= rey Romer' via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org&= gt; wrote:


O= n Thu, Jun 26, 2014 at 6:17 PM, David Krauss=C2=A0<potswa@gmai= l.com>=C2=A0wrote:

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.

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

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

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.

I'm curious; if you don= 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?

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's local to the scope you&#= 39;re returning from.
=C2=A0

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.

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

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

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

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


Say=C2=A0move()=C2=A0= 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

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&= #39;t apply to many situations where move() is appropriate, or even necessa= ry. It's possible to generalize the notion of ownership so that it appl= ies to those situations too, but at that point "ownership transfer&quo= t; becomes basically synonymous with move, and your advice again becomes ci= rcular.

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

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

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

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