220 25487 <96061c41-6f44-468b-b5ec-fb1fd6fad4b7@isocpp.org> article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Fri, 8 Apr 2016 14:44:23 -0700 (PDT) Lines: 377 Approved: news@gmane.org Message-ID: <96061c41-6f44-468b-b5ec-fb1fd6fad4b7@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> <30181f63-7189-494d-9294-3f8b8759308f@isocpp.org> <456f6164-031c-4ccc-ba25-39fcb5714b98@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_949_1744695238.1460151863659" X-Trace: ger.gmane.org 1460151869 1586 80.91.229.3 (8 Apr 2016 21:44:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 21:44:29 +0000 (UTC) Cc: isocppgroup@denisbider.com, barry.revzin@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBOGMUC4AKGQE4WN5BQA@isocpp.org Fri Apr 08 23:44:29 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoeCZ-0006Gz-3K for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 23:44:27 +0200 Original-Received: by mail-vk0-f70.google.com with SMTP id k1sf195834279vkb.3 for ; Fri, 08 Apr 2016 14:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Ck3+FGkNAzt7J1KKTvzc8PNEpFoqK3IbdK7/c9vXAXs=; b=Zovy5tBFt6qOmyBdCDSayzxO/EMLFFdQAHvPgp+3xYOpUtNk7Raxb/TUxWUKfiobC3 7d1H/hEaj1/Htmg6uBHhdGfYe7oCojInqVGqKdt7J+W7/IxVjPT/mMYH84dhBNH/YBtd /OoDNhTCmzE54vw2a59D+9LMaTrjZ4UZRT2Mhk9K2FDvfdsDWQ5peTamqSf6sxgEGZe+ x1gmrDD9e6DcwhTJAexNO5DcRctiBhkqWPPg1MDGOsxMgYu+p3z/oXGi791DHCQr0YI7 iVrAWOoDLjWAZTR4ggrRolhkAPcA7+qLjseKqznMngZE6durMWlQH5ZB7KSSkKyTU96R VKbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=Ck3+FGkNAzt7J1KKTvzc8PNEpFoqK3IbdK7/c9vXAXs=; b=SQTUcQTfcyTYA42Dup0dDr+dGm4zSdZXKySAYZuzbUE1gbdeGw1SIB7WZPB0ipcQT3 xl2IaHrdkSsNvBBFg0UrcoBL5/K7Rre1nGCdkw55HZXJo3TKXYcuJgluOfCBKBt/n/rb 8NlYuW5gr0kSAxmsi2GLVZjhDFghkk7FyKFC0TeM6OSZaz6e5fFiKeLwhIYtPk7eEirj mul5GxU4gceHcoK4lM99EDo6p/5z8UT3H5rqXpaD/XDadJvgqiV6Sz+ngE9PbgMQOMRZ knxq35VdXo/j9qlpemldRa/kqhK1UIBdPlJkgBsBKSlP3QYWH0pjeIO8wwtlRCPa28pp 7reA== X-Gm-Message-State: AD7BkJI+SdchnjXkmNAnJz2SHerKbfz3kbRXo2z/QZydP9tLbRXASEVg+WJpWf1LB7YPsA== X-Received: by 10.129.48.5 with SMTP id w5mr7044876yww.12.1460151866113; Fri, 08 Apr 2016 14:44:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.137.96 with SMTP id l93ls1314232iod.1.gmail; Fri, 08 Apr 2016 14:44:24 -0700 (PDT) X-Received: by 10.50.36.68 with SMTP id o4mr147445igj.1.1460151864702; Fri, 08 Apr 2016 14:44:24 -0700 (PDT) In-Reply-To: <456f6164-031c-4ccc-ba25-39fcb5714b98@isocpp.org> X-Original-Sender: isocppgroup@denisbider.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25487 Archived-At: ------=_Part_949_1744695238.1460151863659 Content-Type: multipart/alternative; boundary="----=_Part_950_1736003873.1460151863659" ------=_Part_950_1736003873.1460151863659 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You are quite correct. This aspect is being implied, rather than being=20 addressed. =20 I am toying with the following text - currently rather informal: "Move optimization=20 When a type is relocatable; then in situations where an implementation=20 would otherwise move an object value to an object of same type by invoking= =20 a move constructor, followed by destruction of the moved-from object; and= =20 where no use of the moved-from object occurs between move and destruction;= =20 the implementation may instead invoke the type=E2=80=99s relocator, eliding= the=20 move constructor and destructor. This move optimization *must* occur when move construction followed by=20 destruction would otherwise be used when returning a relocatable type by=20 value from a function, into a new object of same type." =20 This would require relocation for return by value, if relocation is=20 available and copy elision isn't. This would be similar to how move vs.=20 copy construction is already chosen right now.=20 =20 It would also open the door for a compiler to detect when an object is=20 being moved to a new location, followed by destruction in the previous=20 location. In this case, the compiler *could* use relocation (move=20 destruction), but is not forced to. =20 An open concern here is whether this would be, in practice, too subtle. For= =20 example, a developer might want to ensure that relocation is used, instead= =20 of move construction + destruction: =20 std::unique_ptr MakeThing() { std::list lst =3D ...; InitializeList(lst); return std::make_unique(std::move(lst)); // Is this copy construction, move construction, or relocation?} =20 On the one hand, currently, we do not have syntax that the developer could= =20 use to ensure move construction is used, rather than copy construction. The= =20 developer just has to use syntax that allows for move construction, and=20 then count on that a move constructor is available. =20 Suppose that we have relocation, and the compiler has determined to use=20 relocation in the above example. =20 Then, someone modifies the above function as follows: =20 std::unique_ptr MakeThing() { std::list lst =3D ...; InitializeList(lst); auto thing =3D std::make_unique(std::move(lst)); ReuseListForOtherPurpose(lst); return thing;} =20 Now, this definitely no longer uses relocation, because *lst* is being used= =20 again. Is this a concern? How do we prevent this? To avoid introducing a keyword, one way could be to add a blessed standard= =20 library function, say *std::final_reference*:=20 std::unique_ptr MakeThing() { std::list lst =3D ...; InitializeList(lst); auto thing =3D std::make_unique(std::final_reference(lst)); ReuseListForOtherPurpose(lst); // Error: use of "lst" after final_refere= nce return thing;} This would require a compiler to detect the reuse of "lst" after it's used= =20 in *std::final_reference*, and flag an error when "lst" is reused. An alternative to a blessed function would be a new keyword, e.g.=20 "final_reference". Thoughts? Ideas? =20 On Friday, April 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote: > > If your relocation support can't even perform relocation in this most= =20 >> simple of cases: >> =20 >> =20 >> How does it *not* handle that case? If std::list has a relocator, the=20 >> compiler can just call the relocator in this case: >> =20 >> >> std::list SomeFunc() { >> std::list lt =3D ... >> ... >> return lt; // no special syntax needed; compiler calls relocator >>l= ist >> } >> >> =20 >> What prevents the compiler from doing this? >> > =20 > As far as I can tell, your proposal doesn't say anything about this case,= =20 > or about automatic objects at all. Your invocation section only addresses= =20 > the use-case of "relocating" one pointer to another.=20 > =20 > You should take advantage of the feedback opportunity to improve your=20 > proposal. There's no need to be so defensive.=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/96061c41-6f44-468b-b5ec-fb1fd6fad4b7%40isocpp.or= g. ------=_Part_950_1736003873.1460151863659 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are quite correct.=C2=A0This aspect is being impl= ied, rather than being addressed.
=C2=A0
I a= m toying with the following text - currently rather informal:

"Move optimization

When a type is relocatable; then in situations where an implementation would otherwise move an object value = to an object of same type by invoking a move constructor, followed by destruct= ion of the moved-from object; and where no use of the moved-from object occurs = between move and destruction; the implementation may instead invoke the type=E2=80= =99s relocator, eliding the move constructor and destructor.

This move optimization must occur when move construction followed by= destruction would otherwise be used when returning a relocatable type by value from a function, into a = new object of same type."
=C2=A0
This wo= uld require relocation for return by value, if relocation is available and = copy elision isn't. This would be similar to how move vs. copy construc= tion is already chosen right now.
=C2=A0
It= would also open the door for a compiler to detect when an object is being = moved to a new location, followed by destruction in the previous location.= =C2=A0In this case, the compiler could=C2=A0use relocation (move d= estruction), but is not forced to.
=C2=A0
An= open concern here is whether this would be, in practice, too subtle. For e= xample, a developer might want to ensure that relocation is used, instead o= f move construction + destruction:
=C2=A0
std::unique_ptr=
<Thing> MakeTh=
ing() {
  std::list<int> lst =
=3D ...;
  InitializeList(lst);
  return =
std::make_unique<Thing>(std::move(lst)=
);
    // Is this copy construction, =
move construction, or relocation?
}
=C2=A0
On the one hand, = currently, we do not have syntax that the developer could use to ensure mov= e construction is used,=C2=A0rather than=C2=A0copy construction. The develo= per just has to use syntax that allows for move construction, and then coun= t on that a move constructor is available.
=C2=A0
Suppose that we have relocation, and the compiler has determined to u= se relocation in the above example.
=C2=A0
T= hen, someone modifies=C2=A0the above=C2=A0function as follows:
=C2=A0
std::unique_ptr<Thing> MakeThing() {
  std::list<int> lst =
=3D ...;
  InitializeList(lst);
  auto th=
ing =3D std:=
:make_unique<Thin=
g>(std::move(lst));<=
/span>
  ReuseListForOtherPurpose(lst);
  return =
thing;
}
=C2=A0
Now, this definitely no l= onger uses relocation,=C2=A0because lst is being=C2=A0used again.<= /div>

Is this a concern? How do we prevent this?

To avoid introducing a keyword, one way could be to add a= blessed standard library function, say std::final_reference: 

std::unique_ptr<=
Thing> MakeThing() {
  std::list<int> lst =
=3D ...;
  InitializeList(lst);
  auto th=
ing =3D std:=
:make_unique<Thin=
g>(std::final_reference(lst));
  ReuseListForOtherPurpose(lst);  // E=
rror: use of "lst" after final_reference
  return =
thing;
}

This would require a compiler to= detect the reuse of "lst" after it's used in=C2=A0std::f= inal_reference, and flag an error when "lst" is reused.

An alternative to a blessed function would be a new ke= yword, e.g. "final_reference".

Thoughts?= Ideas?

=C2=A0
On Friday, Apr= il 8, 2016 at 2:46:35 PM UTC-6, barry....@gmail.com wrote:
= > If your relocation support can't even perform relocation in this m= ost simple of cases:
=C2=A0
=C2=A0
How does it not handle that case? If std::list has a relocator, t= he compiler can just call the relocator in this case:
=C2=A0
<= div>
  std=
::list<T> SomeFunc() {
    std::list<T> lt =3D ...
    ...
    return lt; // no special syntax needed; compiler calls relocator &=
gt;>list<T>
  }
=C2=A0
What prevents the compi= ler from doing this?
=C2=A0
As far as I can tell, your proposal doesn't say anything about this = case, or about automatic objects at all. Your invocation section only addre= sses the use-case of "relocating" one pointer to another.=C2=A0
=C2=A0
You should take advantage of the feedb= ack opportunity to improve your proposal. There's no need to be so defe= nsive.=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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/96061c41-6f44-468b-b5ec-fb1fd6fad4b7= %40isocpp.org.
------=_Part_950_1736003873.1460151863659-- ------=_Part_949_1744695238.1460151863659-- .