220 11596 <689CF02F-8111-477F-BAC1-56CAB334823B@gmail.com> 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: Sun, 29 Jun 2014 00:10:42 +0800 Lines: 224 Approved: news@gmane.org Message-ID: <689CF02F-8111-477F-BAC1-56CAB334823B@gmail.com> References: <29988A30-548A-47F3-A275-9B6099329877@gmail.com> 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=_FC5310D2-CF16-4562-A6FF-6D18F8D69234" X-Trace: ger.gmane.org 1403971856 18105 80.91.229.3 (28 Jun 2014 16:10:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Jun 2014 16:10:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBBWSXOOQKGQEIPTM2MI@isocpp.org Sat Jun 28 18:10:48 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f70.google.com ([209.85.192.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0vDE-0001H9-0n for gclcip-std-proposals@m.gmane.org; Sat, 28 Jun 2014 18:10:48 +0200 Original-Received: by mail-qg0-f70.google.com with SMTP id z60sf1467193qgd.5 for ; Sat, 28 Jun 2014 09:10:47 -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=sjWPSnFl/jV/g9JoxWI1fdgx7ACPz7M3v03taU1gteE=; b=AbTFjGH9lHEe/Nu5xX2rU7vr4deHMiTjrYS5snC4oktac3vLQAZ1Ml5E6zGDyOrSPb H1sk5cl2NWHNy7Argg4hyvVPUvO1sxdmQZIMXrRBct9MYlF+OpNMjQJcyBkG/u72pMDe JmaFnFdKy69PApvVwQko11HamcRbtNcrIPshgw80KQmYjtKMXZu6PC4J6F49olH4wzrU 3gSpHUflgE/WgrIgkBMA3Y77J3rP821iycnxAaNiT7PjpKpexc8ouJxfUeWOst+8LKUo iev0XkEW4zE1kSqXlSpvmjnWtZWiGhMcuiXmrxbYguzDZZzuIxHNoR5dIXxT4oYrUIIa zFFQ== X-Gm-Message-State: ALoCoQkz8lnjIaD/MJ3UpzVgluGA/xAs46/JJMJwzJbQ1hNPdZZmNKqqDngrCpXl//ptCIChAaJU X-Received: by 10.58.164.226 with SMTP id yt2mr16155728veb.7.1403971847143; Sat, 28 Jun 2014 09:10:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.36.72 with SMTP id o8ls928897igj.36.canary; Sat, 28 Jun 2014 09:10:46 -0700 (PDT) X-Received: by 10.50.25.71 with SMTP id a7mr20162311igg.17.1403971846508; Sat, 28 Jun 2014 09:10:46 -0700 (PDT) Original-Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [2607:f8b0:4001:c03::229]) by mx.google.com with ESMTPS id mb17si21520940icb.52.2014.06.28.09.10.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 09:10:46 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::229 as permitted sender) client-ip=2607:f8b0:4001:c03::229; Original-Received: by mail-ie0-f169.google.com with SMTP id at1so5508281iec.14 for ; Sat, 28 Jun 2014 09:10:46 -0700 (PDT) X-Received: by 10.50.134.135 with SMTP id pk7mr20593947igb.31.1403971846376; Sat, 28 Jun 2014 09:10:46 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.50]) by mx.google.com with ESMTPSA id hv1sm3145941igb.0.2014.06.28.09.10.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 09:10:45 -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::229 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:11596 Archived-At: --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 wrote: > On Fri, Jun 27, 2014 at 3:30 PM, David Krauss 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
On 2014&= ndash;06–28, at 7:22 AM, 'Geoffrey Romer' via ISO C++ Standard - Futu= re Proposals <std-proposals@= isocpp.org> wrote:

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

That’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’= s not avoiding it, or opportunistic omission, it follows from the underlyin= g theory.

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?

[class.co= py]/32 specifies that copy elision “failure” shall decay to a m= ove. That’s a way of obtaining a lesser opportunistic optimization, a= s gradual degradation.

I didn’t say students= shouldn’t be taught about anything. I merely recommend an order of c= urriculum:

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 programm= ing paradigms.
2. move() is used to constrain an object to tempor= arily behave more like a pure value.
— Perhaps some time la= ter in the course —
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.
4. The c= ompiler is allowed to use move semantics as an inferior substitute for copy= elision. (In fact, it must use this fallback.)

St= udents 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 explicit way to express copy elision. If there’s a problem with th= e language, it’s the lack of an explicit requi= re_copy_elide operator. (I don’t take that seriously.)
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.

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.

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

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.

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.

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’s no need to explain wh= en or why.

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

Per= haps my meaning hasn’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’re comfortable = explaining 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 c= alled.

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.

That’s a= dangerous path. Performance bugs aren’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’s interaction with the mach= ine architecture. They should *not* be encouraged to get hung up on = language quirks.

The physical machine is what goes f= ast, not the C++ virtual machine!

--

---
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=_FC5310D2-CF16-4562-A6FF-6D18F8D69234-- .