220 25488 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 15:30:51 -0700 (PDT) Lines: 468 Approved: news@gmane.org Message-ID: 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_1119_1497625205.1460154651741" X-Trace: ger.gmane.org 1460154657 12257 80.91.229.3 (8 Apr 2016 22:30:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 22:30:57 +0000 (UTC) Cc: isocppgroup@denisbider.com, barry.revzin@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBHPCUC4AKGQE4N5OSWQ@isocpp.org Sat Apr 09 00:30:56 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoevW-0006If-Vu for gclcip-std-proposals@m.gmane.org; Sat, 09 Apr 2016 00:30:55 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id o131sf212141758ywc.2 for ; Fri, 08 Apr 2016 15:30:54 -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=Gz9BsjHM0GglfmkPu2R0g8qszF7p+kP3BIuKJXFJT2A=; b=L7SOLAwjHds/v5+Li4krwXKxChco0uEzRqJLmVmZBn5CZARvFml7O4RGjS2V4CMJ4I JA2d1AGmpMYoplcpk6aa6peb0hgVN3jZl0D23FY4XD8zOXBB5G8r9T1froHB9fgPyQgg HtmXXYLh+pr0bfA3r+29hNJ/D2rMiV3pM9dtwOThky/fSZqcxDzVmgpikT7Z5RjXfLm/ j4RVyDDvSAmpAeGx9kuTag5FeMUb33JtYrlAUVO7OzqCpGzkHcvLWWddrWHEJE5JaqIb Q10d3gjFS7tHQJwm/Vqc+Le15vsqjDbQMj8by4ay/u08mQ6jMBHZPtWpFF3KXBqMOSo1 Oi+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=Gz9BsjHM0GglfmkPu2R0g8qszF7p+kP3BIuKJXFJT2A=; b=RKaOtL+AC8F/K8sbEgSy4RFWx8RkhkDdgcoVFmMqIXPiTvPzV4e1bFr5IcxBxzpDoR RyqBEPTd02cfd2IKxW1+UuGe1i2SLqCu0dHy7thXF7/uLEHzinkzQUV2kMqM3rhsGnw6 AVMNotGCw+OPyP21S2pPze47n4wxOPwCZBVzrE7GyQxXIf77x2hQ/50R7bzY7ytz9Qpr BkWoVZYY22nZb6uKsG2dUmgOR4CmGQZtQk+sd8MQNCFltmgakcvy0t8jpKDsLoPKGRIa BVzJPeGI+EVb8Hq0ZjwuEB1NikYU19gt7nQbrd1kXTlxdc5ZbOZxB9d/4XLECGKDPXOc 5LqA== X-Gm-Message-State: AD7BkJIFYnX2jcD0SYqv7i0MrMJGECL3aiUQ328zndGUbG8xa42fuXqHmtTVkHwx6Ie0eA== X-Received: by 10.31.6.210 with SMTP id 201mr7184025vkg.3.1460154653997; Fri, 08 Apr 2016 15:30:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.39.48 with SMTP id m16ls333730igk.8.canary; Fri, 08 Apr 2016 15:30:52 -0700 (PDT) X-Received: by 10.50.155.72 with SMTP id vu8mr150748igb.5.1460154652902; Fri, 08 Apr 2016 15:30:52 -0700 (PDT) In-Reply-To: <96061c41-6f44-468b-b5ec-fb1fd6fad4b7@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:25488 Archived-At: ------=_Part_1119_1497625205.1460154651741 Content-Type: multipart/alternative; boundary="----=_Part_1120_17427712.1460154651742" ------=_Part_1120_17427712.1460154651742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Or, since we have this problem already when distinguishing between move and= =20 copy construction: how about a family of special blessed functions, like=20 this? template T const& require_copy (T const&);template T&& require_move (T&);template T& require= _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 end= =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 copy= =20 construction, by accident. On Friday, April 8, 2016 at 3:44:24 PM UTC-6, isocp...@denisbider.com 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 invokin= g=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, elidi= ng 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 coul= d=20 > use to ensure move construction is used, rather than copy construction. T= he=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=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 standar= d=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_refe= rence > return thing;} > > > This would require a compiler to detect the reuse of "lst" after it's use= d=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 >>= list >>> } >>> >>> =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 addresse= s=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/f92d4647-9aca-4471-bdc2-c7caba2e2128%40isocpp.or= g. ------=_Part_1120_17427712.1460154651742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or, since we have this problem already when distingui= shing between move and copy construction: how=C2=A0about=C2=A0a family of= =C2=A0special blessed functions, like this?

template <typename T> T const& re=
quire_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, iso= cp...@denisbider.com wrote:
You are quite correct.=C2=A0This aspect is being implied, rather t= han being addressed.
=C2=A0
I am 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));
  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/f92d4647-9aca-4471-bdc2-c7caba2e2128= %40isocpp.org.
------=_Part_1120_17427712.1460154651742-- ------=_Part_1119_1497625205.1460154651741-- .