220 25489 <82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0@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 21:05:30 -0700 (PDT) Lines: 852 Approved: news@gmane.org Message-ID: <82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0@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> <96061c41-6f44-468b-b5ec-fb1fd6fad4b7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1139_1556648077.1460174730295" X-Trace: ger.gmane.org 1460174736 28884 80.91.229.3 (9 Apr 2016 04:05:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Apr 2016 04:05:36 +0000 (UTC) Cc: isocppgroup@denisbider.com, barry.revzin@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBDH7UG4AKGQEAZAWV6Q@isocpp.org Sat Apr 09 06:05:35 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aok9O-0003cr-IA for gclcip-std-proposals@m.gmane.org; Sat, 09 Apr 2016 06:05:35 +0200 Original-Received: by mail-pa0-f72.google.com with SMTP id zy2sf136037227pac.1 for ; Fri, 08 Apr 2016 21:05:34 -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=Ry2wMT1jyVMkz9WI4zjV77Nt1U6epW3Hd+X+6plLLvE=; b=K0qJ3NIAFNs/NlTMh+S2Yh4GZE9YfkVqt4gZA/1U7RHSZOz4KwHxJ32VZpckQGbvFj OGMy2sxQvolAx7BjAHt2OsMXptHPnllN4GVo4mYDPzRMqX+26C5Ux/H98+EQhpiQA5Oj 79mTRKGzzNegO37cdGk4Yywtrz/2agS4UpulhrO9DSuGthB3DNTJSSmHVGecpDCj13VZ 7NPRVxKZ55sXokRGvFlzJ05VgVRGLsx5c/5KOlGSYSJDBbekXhgimVvPSp8eonLor21j uJpQbGwTP++MAcbTtayRO1MzWVMtbt3V7UBA+CiFRXxwgdJzC/jSxHn/UIzvqpdOQIvX Fm+w== 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=Ry2wMT1jyVMkz9WI4zjV77Nt1U6epW3Hd+X+6plLLvE=; b=F5eXGt3zQRk8Trdq1Lwgw48fk4BqCgWjPJ5MD+w/zM5PI0KBFoD1mJ4xEkCLoPGJT3 /d29L1E/DDpGhybBNR3OqMzwl/1owz6hXn+tNAA1rzdYpJrALPnlN78u1TGdgo8JJNaE RK77ySkXmHoYg60MCz9yk94rSA3633vQWwVu0vjKDxjasxpzESI7AibOIFTeQBVOj+8J ea4WZYflm6hatpI+s3IQxlaBmKRBgGhnNuqZa6QxUXgcE4Hv0Ovxmx7Um3R0RqQ7MwEU miMm+y7OON9AIVIsRDFIyihAlWlj3I+YHN5Hu4HThgVKyV7tEfh/99ybp9C6s9d5/nVV 1gdg== X-Gm-Message-State: AD7BkJJxJNLTEl4SRsSoJ3uqUS9By+6bVp0SEtKNMrbvvxiANvOttD87nCMM23facTbnYQ== X-Received: by 10.98.33.76 with SMTP id h73mr7853170pfh.0.1460174733346; Fri, 08 Apr 2016 21:05:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.169.39 with SMTP id s39ls1354102ioe.46.gmail; Fri, 08 Apr 2016 21:05:31 -0700 (PDT) X-Received: by 10.50.43.234 with SMTP id z10mr166136igl.4.1460174731722; Fri, 08 Apr 2016 21:05:31 -0700 (PDT) In-Reply-To: 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:25489 Archived-At: ------=_Part_1139_1556648077.1460174730295 Content-Type: multipart/alternative; boundary="----=_Part_1140_479930691.1460174730296" ------=_Part_1140_479930691.1460174730296 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have uploaded a new version of the proposal: http://denisbider.com/Relocator.pdf Main changes: - Indirect use of relocation via copy/move optimization is now explicitly= =20 defined. - There is a new annex, proposing a syntax by which a language user can=20 ensure that copy/move optimizations are done as intended. The proposed new syntax helps not only with relocation, but also in=20 existing situations where a developer wants to ensure that deep copy is not= =20 being accidentally used. The proposed syntax simplifies the variant example as follows: =20 X temp { std::move(a.x) }; b.y.~Y(); *new* (&b.x) X(std::must_relocate(temp)); =20 It also allows for this: =20 BigPart MakeBigPart() { BigPart part; ... *return* std::must_move(part); // may elide, relocate, or move -=20 but not copy } =20 std::unique_ptr MakeBigThing() { *auto* part =3D MakeBigPart(); *auto* thng =3D std::make_unique(std::must_move(part)); //= =20 relocate/move *return* thng; // do not care if copied } =20 Comments welcome. On Friday, April 8, 2016 at 4:30:52 PM UTC-6, isocp...@denisbider.com wrote= : > Or, since we have this problem already when distinguishing between move= =20 > and copy construction: how about a family of special blessed functions,= =20 > like this? > > template T const& require_copy (T const&);template T&& require_move (T&);template T& requi= re_relocate (T&); > > > Each of these would require the compiler to flag the returned reference,= =20 > and perform a compile-time verification that the reference does in fact e= nd=20 > up being passed to a copy constructor; move constructor; or relocator,=20 > respectively. > > This would be useful even without relocate. It would allow code like this= : > > BigObj MakeBigObj() { > BigObj x; > x.This(); > x.That(); > return std::require_move(x);} > > > ... to verify that what's happening is indeed move construction - not cop= y=20 > construction, by accident. > > > On Friday, April 8, 2016 at 3:44:24 PM UTC-6, isocp...@denisbider.com=20 > wrote: > >> 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 invoki= ng=20 >> a move constructor, followed by destruction of the moved-from object; an= d=20 >> where no use of the moved-from object occurs between move and destructio= n;=20 >> the implementation may instead invoke the type=E2=80=99s relocator, elid= ing 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.= =20 >> For example, a developer might want to ensure that relocation is used,= =20 >> instead 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=20 >> could use to ensure move construction is used, rather than copy=20 >> construction. The developer just has to use syntax that allows for move= =20 >> construction, and 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=20 >> being used again. >> >> Is this a concern? How do we prevent this? >> >> To avoid introducing a keyword, one way could be to add a blessed=20 >> standard 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_ref= erence >> return thing;} >> >> >> This would require a compiler to detect the reuse of "lst" after it's=20 >> used 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 >= >list >>>> } >>>> >>>> =20 >>>> What prevents the compiler from doing this? >>>> >>> =20 >>> As far as I can tell, your proposal doesn't say anything about this=20 >>> case, or about automatic objects at all. Your invocation section only= =20 >>> addresses 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/82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0%40isocpp.or= g. ------=_Part_1140_479930691.1460174730296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have uploaded a new version of the proposal:
<= div>

Main changes:

- Indirect use of relocation via copy/move optimizatio= n is now explicitly defined.

-=C2=A0There is a new= =C2=A0annex, proposing=C2=A0a syntax by which a language user can ensure th= at copy/move optimizations are done as intended.

T= he proposed new syntax helps not only with relocation, but also in existing= situations where a developer wants to ensure that deep copy is not being a= ccidentally used.

The proposed syntax simplifies t= he variant example as follows:

=C2=
=A0
=
=C2=A0 X temp { std::move(a.x) };
 =C2=A0b.y.~Y();
=C2=A0 new (&b.x) X(std::must_relocate());
=
=C2=A0

It also allows for t= his:

=C2=A0

=C2=A0 BigPart MakeBigPart() {

=C2=A0=C2= =A0 =C2=A0BigPart part;

=

=C2=A0 = =C2=A0=C2=A0...

=C2=A0 = =C2=A0=C2=A0return std= ::must_mov= e(part);= =C2=A0 =C2=A0=C2=A0=C2=A0<= /span>// may el= ide, relocate, or move - but not copy

=C2=A0 }

=C2=A0

=C2=A0 std::unique_ptr<BigThing> MakeBigThing() {

=C2=A0 = =C2=A0=C2=A0auto part =3D MakeBigPart()= ;

=C2=A0 = =C2=A0=C2=A0auto thng =3D std::make_unique<= span style=3D"color: rgb(64, 96, 128); font-family: Consolas; font-size: 10= pt; mso-fareast-font-family: "Times New Roman";"><BigThing>(std::must_move(part));=C2=A0 // relocate/move

=C2=A0 = =C2=A0=C2=A0return thng;=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= span style=3D"color: rgb(89, 89, 121); font-family: Consolas; font-size: 10= pt; mso-fareast-font-family: "Times New Roman";">// do not care i= f copied

=C2=A0 }

=C2=A0


Comments welcome.


On Friday, April 8, 2016 at 4:30:52 PM UTC-6, isocp...@deni= sbider.com wrote:
O= r, since we have this problem already when distinguishing between move and = copy construction: how=C2=A0about=C2=A0a family of=C2=A0special blessed fun= ctions, like this?

template <t=
ypename T> T const& require_copy     (T const&);
template =
<typename T> T&=
amp;&      requ=
ire_move     (T&);
template =
<typename T> T&=
amp;       require_relocate &);

Each of these would require the compiler to= flag the returned reference, and perform a compile-time verification that = the reference does in fact end up being passed to a copy constructor; move = constructor; or relocator, respectively.

This woul= d be useful even without relocate. It would allow code like this:

BigObj MakeBigObj() {
  BigObj x;
  x.This()=
;
  x.That()=
;
  return =
std::require_move(x);
}

... to verify that what's happening is = indeed move construction -=C2=A0not copy construction, by accident.


On Friday, April 8, 2016 at 3:44:24 PM UTC-6, = isocp...@denisbider.com wrote:
You are quite correct.=C2=A0This aspect is being implied, r= ather than being addressed.
=C2=A0
I am toyi= ng 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));
  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<=
span style=3D"color: rgb(48, 128, 128);">(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 most simple of cases:
=C2=A0
=C2=A0
How does it not handle that case? If std::list has a reloc= ator, the compiler can just call the relocator in this case:
=C2=A0
= 
  std=
::list&l=
t;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/82db5d5a-bad9-42ce-b1ad-66bcc0dd20b0= %40isocpp.org.
------=_Part_1140_479930691.1460174730296-- ------=_Part_1139_1556648077.1460174730295-- .