220 19728 article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Move destructor draft Date: Fri, 7 Aug 2015 14:54:27 -0700 (PDT) Lines: 381 Approved: news@gmane.org Message-ID: References: <0A99E209-333B-4140-8F65-2F022E681AC1@gmail.com> <55C0DDD4.8090100@halpernwightsoftware.com> <411A67D7-B062-4D22-983A-095737483208@gmail.com> <55C299B0.1060300@gmail.com> <55C2ABA3.8060605@halpernwightsoftware.com> <55C2ECDB.1060307@gmail.com> <5de71605-7320-4130-938b-813304c51069@isocpp.org> < mq2f45$k25$1@ger.gmane.org> <94331665-f7f3-444b-a1dc-333a52be7873@isocpp.org> <798f7179-c397-4bad-abeb-1bb7493c9860@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2548_1499900910.1438984467831" X-Trace: ger.gmane.org 1438984473 4283 80.91.229.3 (7 Aug 2015 21:54:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 21:54:33 +0000 (UTC) Cc: mwoehlke.floss@gmail.com, isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBFGSSSXAKGQEZIPO3GI@isocpp.org Fri Aug 07 23:54:32 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZNpaw-00048L-LX for gclcip-std-proposals@m.gmane.org; Fri, 07 Aug 2015 23:54:31 +0200 Original-Received: by pdbpo3 with SMTP id po3sf217638748pdb.1 for ; Fri, 07 Aug 2015 14:54:29 -0700 (PDT) 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:content-type: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=UT5JijfU34/D/oLhkbbksIC6nWEwhmfT0zxvyOi8+Ns=; b=bten7DTtMU32p9L6Ffunzhj/n7JILaEAmxhsehVvTg5CIrQUHmYYl9RYbJhIblBs4A kg2GFRFAZgZuAC9NSC82kb91e7bJ/A8ScKJGFoQ5REVoqOmhDQMdNLOiedkR4uUddF9W dR02XT7GMHxmHUBuICsZqTN4O7/yt7XHQtpRr8AICOqdgC5f5VavjCTw09R1iC2VLCop Vkr88z16x627IXaZHI2qu+9kZPiRdi/8oA6jmHOFMtzaV0VLkoi/p6WSRPl2IRxXRm5c nsmVVHt8DTf5WJs/qlIZiaRJ8QXOGJawUGgbYGG0ZJxgD2EB9UiWWuXydWlXVPOHe4LB rA0w== X-Gm-Message-State: ALoCoQkwDUlM6PpnAuo7KasJIi5HZnNVU+AymsgOMXIALj+ynPNUqW9pEOWA/F/Voj/YhAycTMGb X-Received: by 10.66.119.201 with SMTP id kw9mr8293783pab.4.1438984469521; Fri, 07 Aug 2015 14:54:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.32.69 with SMTP id g63ls1903776qgg.73.gmail; Fri, 07 Aug 2015 14:54:28 -0700 (PDT) X-Received: by 10.140.31.70 with SMTP id e64mr47809qge.12.1438984468538; Fri, 07 Aug 2015 14:54:28 -0700 (PDT) In-Reply-To: <798f7179-c397-4bad-abeb-1bb7493c9860@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:19728 Archived-At: ------=_Part_2548_1499900910.1438984467831 Content-Type: multipart/alternative; boundary="----=_Part_2549_921098360.1438984467832" ------=_Part_2549_921098360.1438984467832 Content-Type: text/plain; charset=UTF-8 > - naturally interacts with copy/move constructors - > easy to slip up and forget std::xref, resulting in a deep copy And there we go, I did exactly that in the example: A(A~& x) : B(x), c(std::xref(x.c)), i(x.i) {} Should be: A(A~& x) : B(std::xref(x)), c(std::xref(x.c)), i(x.i) {} Arguably, we have the same problem with move constructors... And arguably - it might be better if we didn't... :) On Friday, August 7, 2015 at 3:51:41 PM UTC-6, isocp...@denisbider.com wrote: > Great responses! Thank you! > > I urgently have to sleep, but I've had the following idea: > > Do you think we should approach this from the opposite direction - a > destructing constructor? > > I went with constructing destructor because it's easy to extend syntax for > it in an unambiguous way. However, > > If we're willing to introduce an explicit reference type for xvalues, we > could have this, which could arguably be *more* general: > > struct A : B { > A(A~& x) : B(x), c(std::xref(x.c)), i(x.i) {} > C c; > int i;}; > > > Pros: > > - everything is like move constructor - except this takes xvalue reference > instead of rvalue reference, and relies on std::xref instead of std::move > > - fully recognizes xvalues, gives them a reference type (~&) > > - naturally interacts with copy/move constructors > > - allows for xvalue assignment operator - maybe useful for returns from > functions when assigned to pre-existing object? > > Cons: > > - fully recognizes xvalues - yet another reference type... > > - naturally interacts with copy/move constructors - easy to slip up and > forget std::xref, resulting in a deep copy > > - allows for xvalue assignment operator - yet another special member... > > Thoughts? > > > On Friday, August 7, 2015 at 3:32:51 PM UTC-6, Matthew Woehlke wrote: > >> On 2015-08-07 16:47, isocp...@denisbider.com wrote: >> > I believe the destructive move Jesus is upon us! >> > >> > I have uploaded the following draft: >> > >> > http://www.denisbider.com/MoveDestructor.pdf >> >> Editorial comments: >> >> - Might want to explain "destructive move" in the opening paragraph. >> >> - Might want to mention std::unique_ptr? This is a really simple example >> of a class that is trivially relocatable but has an "interesting" move >> constructor and "interesting" destructor. >> >> >> Nits: >> >> - In the defaulted example, s.b. ~int(int&). That is, define the default >> behavior as cting-dtor for ALL members, and explain elsewhere when a >> cting-dtor is trivial (i.e. for POD types; the "consists of trivially >> relocatable members" case seems sufficiently covered) and that trivial >> means to just copy the bits. (Also, it's expected that the compiler will >> combine trivial cting-dtors of adjacent members into a single memcpy.) >> At least, I'd do that... seems cleaner. (Shouldn't actually change >> anything.) >> >> >> Not-so-nits: >> >> - The multiple object helper should work on overlapping memory. I >> imagine you intended this, but I don't see any wording to that effect; >> it seems to me that such wording may be important. >> >> - Should(n't) the cting-dtor be implicit-default if the class has a) a >> *default* move ctor *or copy ctor*, *and* b) a default dtor, whether or >> not such are declared? >> >> - I feel fairly strongly that there should be a cutoff point for which >> we can use the same syntax to relocate objects that can't be simply >> relocated. I proposed that there is *always* a cting-dtor (except for >> objects that explicitly delete it, or can't be copied/moved and/or >> destroyed at all, i.e. the fallback implementation would be ill-formed), >> but at any rate, I think the helpers should work regardless. >> >> - I'm not entirely confident that the composition case is solved. As >> worded, the class members are relocated after the base class has been >> destroyed (moveover, the derived class itself is technically "destroyed" >> after the base class has been destroyed), which seems like it could >> present problems... :-( Unfortunately I don't have any suggestions here. >> I do hope that this won't kill the proposal though. >> >> >> Comments: >> >> - It took me a minute or two to understand the invocation helpers, but >> now that I do, I like! IIUC what these mean is that instead of libraries >> having to check a type trait and write a memmove themselves, the >> compiler will do so. Cool! >> >> >> Bikesheds (JFTR): >> >> - ~A(A&) vs. ~A(A*) vs. ~A(void*). >> >> - "cting-dtor" vs. "move-dtor" ;-). >> >> - Type trait names. >> >> >> Thanks for sticking with this! >> >> -- >> Matthew >> >> -- --- 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/. ------=_Part_2549_921098360.1438984467832 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> - naturally interacts with copy/move constructor= s -
> easy to slip up and forget std::xref, resulting in a dee= p copy

And there we go, I did exactly that in the = example:


  A~& x) : B(x), c(std::xr=
ef(x.c)), i(<=
/span>x.i) =
{}

Should be:


A(A~& = x) : B(std::xref(x)), c(std::xref(x.c)= ), i(x.i) {}


Arguably, we have the same problem with move co= nstructors...

And arguably - it might be better if= we didn't... :)


On Friday, August 7, 2015 at 3:51:41= PM UTC-6, isocp...@denisbider.com wrote:
Great responses! Thank you!

I urgently have to sleep, but I've had the following idea:
<= br>
Do you think we should approach this from the opposite direct= ion - a destructing constructor?

I went with const= ructing destructor because it's easy to extend syntax for it in an unam= biguous way. However,

If we're willing to intr= oduce an explicit reference type for xvalues, we could have this, which cou= ld arguably be more general:

struct A : B {
  A(A~&=
; x) : B(x), c(std::xref(x.c)), i=
(x.i) {}
  C c;
  int i;
};


Pros:

- everything is like m= ove constructor=C2=A0-=C2=A0except this takes xvalue reference instead of r= value reference, and relies on std::xref instead of std::move
- fully recognizes xvalues, gives them a reference type (~&)

- naturally interacts wit= h copy/move constructors

- allows for xvalue assig= nment operator - maybe useful for returns from functions when assigned to p= re-existing object?

Cons:

- fully recognizes xvalues - yet another reference type...

<= /div>
- naturally interacts with copy/move constructors - easy to slip = up and forget std::xref, resulting in a deep copy

= - allows for xvalue assignment operator - yet another special member...
=

Thoughts?


On Friday,= August 7, 2015 at 3:32:51 PM UTC-6, Matthew Woehlke wrote:
On 2015-08-07 16:47, isocp...@denisb= ider.com wrote:
> I believe the destructive move Jesus is upon us!
>=20
> =C2=A0I have uploaded the following draft:
>=20
> http://www.denisbider.com/M= oveDestructor.pdf

Editorial comments:

- Might want to explain "destructive move" in the opening par= agraph.

- Might want to mention std::unique_ptr? This is a really simple exampl= e
of a class that is trivially relocatable but has an "interesting&q= uot; move
constructor and "interesting" destructor.


Nits:

- In the defaulted example, s.b. ~int(int&). That is, define the de= fault
behavior as cting-dtor for ALL members, and explain elsewhere when a
cting-dtor is trivial (i.e. for POD types; the "consists of trivia= lly
relocatable members" case seems sufficiently covered) and that tri= vial
means to just copy the bits. (Also, it's expected that the compiler= will
combine trivial cting-dtors of adjacent members into a single memcpy.)
At least, I'd do that... seems cleaner. (Shouldn't actually cha= nge
anything.)


Not-so-nits:

- The multiple object helper should work on overlapping memory. I
imagine you intended this, but I don't see any wording to that effe= ct;
it seems to me that such wording may be important.

- Should(n't) the cting-dtor be implicit-default if the class has a= ) a
*default* move ctor *or copy ctor*, *and* b) a default dtor, whether or
not such are declared?

- I feel fairly strongly that there should be a cutoff point for which
we can use the same syntax to relocate objects that can't be simply
relocated. I proposed that there is *always* a cting-dtor (except for
objects that explicitly delete it, or can't be copied/moved and/or
destroyed at all, i.e. the fallback implementation would be ill-formed)= ,
but at any rate, I think the helpers should work regardless.

- I'm not entirely confident that the composition case is solved. A= s
worded, the class members are relocated after the base class has been
destroyed (moveover, the derived class itself is technically "dest= royed"
after the base class has been destroyed), which seems like it could
present problems... :-( Unfortunately I don't have any suggestions = here.
I do hope that this won't kill the proposal though.


Comments:

- It took me a minute or two to understand the invocation helpers, but
now that I do, I like! IIUC what these mean is that instead of librarie= s
having to check a type trait and write a memmove themselves, the
compiler will do so. Cool!


Bikesheds (JFTR):

- ~A(A&) vs. ~A(A*) vs. ~A(void*).

- "cting-dtor" vs. "move-dtor" ;-).

- Type trait names.


Thanks for sticking with this!

--=20
Matthew

--

---
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>.
------=_Part_2549_921098360.1438984467832-- ------=_Part_2548_1499900910.1438984467831-- .