220 5196 article Path: news.gmane.org!not-for-mail From: Geoffrey Romer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Teachability problems with std::move Date: Mon, 24 Jun 2013 11:42:04 -0700 Lines: 115 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b15b117dc041c04dfeac4c2 X-Trace: ger.gmane.org 1372099327 21434 80.91.229.3 (24 Jun 2013 18:42:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Jun 2013 18:42:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD74DCN5SYHBB7NFUKHAKGQES4QI2MI@isocpp.org Mon Jun 24 20:42:08 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UrBiJ-0006IL-3O for gclcip-std-proposals@m.gmane.org; Mon, 24 Jun 2013 20:42:07 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id xk17sf47491887obc.6 for ; Mon, 24 Jun 2013 11:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:mime-version:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:list-subscribe:list-unsubscribe:content-type; bh=/AchMupw0BnNIj6Dzi7DkPwtHo1uiFB67XCqqE1uuoQ=; b=WzJwvDd+e3ZsGWueRyyVBMya3WmUxAjU8wu/N190rOH1w810uNOnQbxUKf/0ZrMXAy xa2KzH+yAZJwiOy12yQrEA5P4wvVJ7wpUuVmgsliUr+QnSPZcWK3sm9vE4YsbQvx/jV1 33/Ksg/PhBmPkin2VEua73gdrBK1FexWZW/MtZDJIlnkmxBpbxJX+HT+flJHh4NBUbio 2Ywo3QuGEn2MdrcrtN8MbE87n5z+3cfn+ljIYRB/X0wBsyzXoHKJiIgbKQvwkBVfw5Ac zCA6dv34BWbi1zhD1tACVhw0WhPpAWY5Z0kEQXoxElv0kDFgFqQrGC2Gt67fjD45SQLT hxZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:mime-version:date:message-id:subject:from:to :x-gm-message-state:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=/AchMupw0BnNIj6Dzi7DkPwtHo1uiFB67XCqqE1uuoQ=; b=EHfh5vgFnk1LhqOQkWOkIQBl5jRxFEUoeoXx3iTNBoUMY1f2DjYFSZiBMTmiNltz6k O6EpIIJgVzwS4Ldjmhrdv7T10cqZ1vjWyK+grJx+H7R+SD220uDFJmoJNlP1HEAvUBwF WpJTIhVdstL38K/dyFil2kDeaCLSP/uM9BPtbzee6M1Vw1Uh68pYX1s6GdeNaiQLlb/q MyXJccWs+78agQpvnmDKBOORtj+Pkwwi+9fpX+Iljl7PiaJjbADZM1gQ2YxC9zO+Z2xX Dw7gK407Cz/pHqbZmg+n5x2DwEZDX3vXHzogD0d9mZq0W9YnUfRrjhChMBgRdglW1mMT XEUg== X-Received: by 10.182.226.170 with SMTP id rt10mr4409460obc.13.1372099326030; Mon, 24 Jun 2013 11:42:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.142.39 with SMTP id rt7ls312831obb.73.gmail; Mon, 24 Jun 2013 11:42:05 -0700 (PDT) X-Received: by 10.182.125.1 with SMTP id mm1mr8731845obb.47.1372099325294; Mon, 24 Jun 2013 11:42:05 -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 ur7si7174991obc.108.2013.06.24.11.42.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 11:42:05 -0700 (PDT) Received-SPF: pass (google.com: domain of gromer@google.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 16so26105380iea.3 for ; Mon, 24 Jun 2013 11:42:05 -0700 (PDT) X-Received: by 10.50.60.2 with SMTP id d2mr4902856igr.52.1372099324905; Mon, 24 Jun 2013 11:42:04 -0700 (PDT) Original-Received: by 10.231.133.10 with HTTP; Mon, 24 Jun 2013 11:42:04 -0700 (PDT) X-Gm-Message-State: ALoCoQmcmoN8jY4JzW0ZTlqG7ptZ3nX45m1H5V7+qcjL81knR4+Ibhcpla0CuOovhWhwTpH1+aAzO588myyOljWdsBy6cAC6R87y2vgGa5kzTH+yr8nGI+BfoT8SRz0MlVgCPMqdoTulcfyepX/3ILVMASbAiNA9sl0P/eNtatrJCev7pd5zZydVf8gmozBpSIjkRe2r0rlXz9Yxia/LWvzGdCEhPkQF9w== 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:4001:c03::22c as permitted sender) smtp.mail=gromer@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) d=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: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5196 Archived-At: --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 FooFactory() { std::unique_ptr 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 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 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
It'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 "you can leave out std::move when returning a named lo= cal variable", but this is not always the case. Consider:

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

The = "std::move" is mandatory here, because an lvalue can only be impl= icitly treated as an rvalue during copy operations, and in "return res= ult;", 'result' 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'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).

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

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

As written, th= e return statement incurs 10,000 invocations of Foo's move constructor = (or, worse, its copy constructor), but if std::move is eliminated, the retu= rn statement becomes effectively free, because it's an elidable copy/mo= ve. 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 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= 'see into' the implementation of a function called in a return sta= tement (which seems impractical).=A0

I think it's worth trying to fix these issues, desp= ite 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 &= 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/group/std-proposals/<= /a>.
 
 
--047d7b15b117dc041c04dfeac4c2-- .