220 19854 <6aa5db15-1c30-4374-85af-afdbce670c7c@isocpp.org> 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: Thu, 13 Aug 2015 19:58:53 -0700 (PDT) Lines: 511 Approved: news@gmane.org Message-ID: <6aa5db15-1c30-4374-85af-afdbce670c7c@isocpp.org> 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-444 b-a1dc-333a52be7873@isocpp.org> <80721d48-888b-4dc8-b938-28f2ca329f04@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_185_1486388530.1439521133556" X-Trace: ger.gmane.org 1439521138 6240 80.91.229.3 (14 Aug 2015 02:58:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2015 02:58:58 +0000 (UTC) Cc: mwoehlke.floss@gmail.com, isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRB3VSWWXAKGQE6JYJFEY@isocpp.org Fri Aug 14 04:58:57 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZQ5Cq-0007gl-BX for gclcip-std-proposals@m.gmane.org; Fri, 14 Aug 2015 04:58:56 +0200 Original-Received: by oio137 with SMTP id 137sf96790658oio.2 for ; Thu, 13 Aug 2015 19:58:55 -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=qEjCKQIFHrlRwzJvKAaWnUQu0iAjwOK+NFt7aj5y1/k=; b=mZm9teoEPvluAED4NgSqgCP+H8HCoEalOrN+AEYrz2ORHPF2oqb/FHdI/f9AZqKaIK 90Q6ETs4pJFWeSdZSmnHTQNFNANlUtlX5J46gBMnbxr9Bhe3qW1lbnMzA4qxZ3fvD0Dn f1ZQ/SSJvhW0i6rKyAVLJRVBMXNo/GSPeZd7iAAzpb0z2IYsiJzBv5lGCO95y8D4ue90 CEtp4uV2q8rmehvDFliXRtwHldn9Tj75n34Qrimnjud33XW2CpZkXzvzVTElPD8w8b/X KXxxy5GYgg30PP06UYKJKykZ4N8PtW0RRhNve96cI0EUqPrTAtjY2czuofP1gZZ/QnJH gOIw== X-Gm-Message-State: ALoCoQm61WX41EKz91qHZJt5Mvbz74+cx0Rz7FUU202YMrrf+StEtrZUriey6AhD57tpx1oJr7iZ X-Received: by 10.107.128.203 with SMTP id k72mr8754636ioi.26.1439521135337; Thu, 13 Aug 2015 19:58:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.93.9 with SMTP id c9ls506299qge.16.gmail; Thu, 13 Aug 2015 19:58:54 -0700 (PDT) X-Received: by 10.140.41.148 with SMTP id z20mr7027qgz.3.1439521134237; Thu, 13 Aug 2015 19:58:54 -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:19854 Archived-At: ------=_Part_185_1486388530.1439521133556 Content-Type: multipart/alternative; boundary="----=_Part_186_1888314699.1439521133557" ------=_Part_186_1888314699.1439521133557 Content-Type: text/plain; charset=UTF-8 Ville informs me that someone needs to champion this proposal in front of the Evolution WG. I reckon, if someone isn't found, the alternative is that it will be simply disregarded. Is anyone going to the next WG meeting who is super passionate about efficient relocation, and wants to present this proposal? If no one volunteers, I'll have to go to Hawaii, and you know how much I would hate that. :) I believe such a volunteer should be sufficiently comfortable with the current state of the proposal as to be comfortable putting their name on it. Since this person would be presenting and defending the proposal in front of the EWG, I imagine they would be added to the proposal as co-author. On Thursday, August 13, 2015 at 8:54:17 PM UTC-6, isocp...@denisbider.com wrote: > Thanks for your reply! > > > Finally read it; sorry it took so long. > > No worries at all. > > I have uploaded a new version again, based on this feedback: > > http://denisbider.com/Relocator.pdf > > - It now has a proper proposal number, P0023, currently R0. > > - It adds a single-object version of relocate_or_move, as suggested. > > - It switches around Annex 1 and Annex 2, so that relocate_or_move is in > Annex 1, reflecting it's more central. > > - Changed wording related to realloc_in_place, now in Annex 2, to make it > clearer that it's related to, but not essential to the proposal. > > - Added discussion headings "Why not a const reference?" and "Why not an > rvalue reference?" > > > > > I still wonder if the indirection for the relocation > > operator shouldn't somehow indicate that the > > parameter will be destroyed when the outermost > > relocation completes. (If not 'T~'/'T~&', I wonder > > if it should at least be a 'T&&'? Not sure though...) > > The problem with an rvalue reference is that you then have to consistently > do this: > > > > >>A(A&& x) : >>B(std::move(x)), >>c(std::move(x.c)) {} > > > > I think this would be inconvenience for the sake of inconvenience alone. > Not much is gained, since an rvalue reference is not needed to e.g. resolve > an overload conflict. > > A new reference type is a whole new animal altogether and probably not > warranted as long as this would be the only usage case. There is no > technical problem we'd be solving with a new reference type, just a > subjective problem of indication. > > I would argue that indication is already handled sufficiently by the > syntax >>A, so that there's no need to handle it additionally via > reference type, also. > > > > Might want to say, instead of "std::relocate, > > defined as" with "might be defined as", > > Good point. I have changed that to "behaving as follows". > > > > the relocator should also be deleted if any > > subobject *lacks* a relocator (i.e. "not declared"). > > Good point. I have added this stipulation. > > > > I'm not sure this is as tightly coupled to > > realloc_in_place as is suggested. > > I agree, the championing of realloc_in_place was overdone. I have toned > it down to make it clear that the relocator proposal stands on its own, > without it. :-) > > > > Where you run into problems is if the base > > class relocator fiddles with memory that the > > derived class still needed. > > True. However, I'd prefer for modification of the original object to be > defined behavior, and to let the user beware and not shoot themselves in > the foot; rather than to preclude access "for yer protection". :-) > > > On Thursday, August 13, 2015 at 10:12:15 AM UTC-6, Matthew Woehlke wrote: > >> On 2015-08-11 15:45, isocp...@denisbider.com wrote: >> > Good points, thank you! >> > >> > I have uploaded a new version of the draft addressing the following: >> >> Finally read it; sorry it took so long. >> >> Thanks for the improved examples section! >> >> I still wonder if the indirection for the relocation operator shouldn't >> somehow indicate that the parameter will be destroyed when the outermost >> relocation completes. (If not 'T~'/'T~&', I wonder if it should at least >> be a 'T&&'? Not sure though...) >> >> > - proposed single object invocation is now similar to placement new >> >> Cool :-). >> >> > - there is now an Annex 2 defining a proposed std::relocate_or_move >> >> Cool :-). >> >> I wonder if there should also be single-object versions? >> >> Nit: Might want to say, instead of "std::relocate, defined as" with >> "might be defined as", in case implementations need to insert some >> compiler voodoo to denote creation and deletion of objects in the >> memmove case. (Presumably, the relocation operator has this built in, >> but the trivial case isn't calling that...) Or, just if libraries come >> up with some better implementation. I don't think the actual definition >> needs to be codified, just the effect. >> >> > - proposed implicit declaration rules have been relaxed, so that >> explicitly >> > defaulting a special member does not block implicit relocator >> declaration >> >> Cool; thanks :-). >> >> > - added explicit statement that lifetime of object in original location >> > ceases when outermost relocator completes >> >> Cool :-). I think we needed this, and your wording LGTM. Thanks. >> >> > - added explicit statement that invocation of subobject relocator >> outside >> > of outer object relocation is undefined behavior >> >> Erk... yes, it had better be ;-). Good catch; thanks. >> >> >> Other comments: >> >> I think this isn't exactly an omission vs. a language loophole that >> should be closed, but the relocator should also be deleted if any >> subobject *lacks* a relocator (i.e. "not declared"). Or if not declared >> and the conditions for implicit declaration are not met. (Both will >> close the loophole, the former might be preferred however.) >> >> I'm not sure this is as tightly coupled to realloc_in_place as is >> suggested. If we have realloc_in_place, we don't need relocation for the >> case where that succeeds. If we assume that realloc always fails, we >> don't see any benefit from realloc_in_place. (That's not to say that we >> don't *want* realloc_in_place, just that Annex 1 makes it sound like >> both are significantly less useful without the other, which I don't >> believe is true. I think they are closer to orthogonal.) >> >> Overall, looks very good; thanks again! >> >> >> the second form should take an 'A[]' rather than an 'A*'. >> > >> > I have decided against this because the argument may in fact be a slice >> of >> > an array, not a whole array. Overlapping memory is also explicitly >> > supported, so I would not like to suggest that only a whole array may >> be >> > passed. >> >> Okay, I can follow that. >> >> >> (Which also makes me wonder if relocation should be const w.r.t. >> >> the old object?) >> > >> > I think not, because: >> > >> > - the user may want to explicitly destroy subobjects if initializing >> their >> > counterparts via means other than relocation; >> > >> > - the user may want to zero out memory being moved from. >> >> These are good points, but can cut both ways. Where you run into >> problems is if the base class relocator fiddles with memory that the >> derived class still needed. >> >> I'm not saying I feel strongly about it either way, just trying to >> explore the possible consequences of either decision. >> >> >> I've seen try_realloc more often than realloc_in_place. >> > >> > I find realloc_in_place more descriptive. >> >> Fair enough; I meant it more as an observation. >> >> -- >> 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_186_1888314699.1439521133557 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ville informs me that someone needs to champion this = proposal in front of the Evolution WG.

I reckon, i= f someone isn't found,=C2=A0the alternative is that it will be simply d= isregarded.

Is anyone going to the next WG meeting= who is super passionate about efficient relocation, and wants to present t= his proposal?

If no one volunteers, I'll have = to go to Hawaii, and you know how much I would hate that. :)

=
I believe such a volunteer should be sufficiently comfortable wi= th the current state of the proposal as to be comfortable putting their nam= e on it. Since this person would be presenting and defending the proposal i= n front of the EWG, I imagine they would be=C2=A0added to the proposal=C2= =A0as co-author.


On Thursday, August 13, 2015 at 8:54:17 = PM UTC-6, isocp...@denisbider.com wrote:
=
Thanks for your reply!

> = Finally read it; sorry it took so long.

No worrie= s at all.

I have uploaded a new=C2=A0version again= , based on this feedback:


- It now has a proper = proposal number, P0023, currently R0.

- It adds a = single-object version of relocate_or_m= ove, as suggested.

- It switches around Ann= ex 1 and Annex 2, so that relocate_or_= move is in Annex 1,=C2=A0reflecting it's=C2=A0more central.

- Changed wording related to realloc_in_place, now in=C2=A0Annex 2, to make it cleare= r that it's related to, but not essential to the proposal.
- Added discussion headings "Why not a const reference?&q= uot; and "Why not an rvalue reference?"

=

> I still wonder if the indirection for th= e relocation
> operator shouldn't=C2=A0somehow indicate th= at the
> parameter will be destroyed when the outermost
&g= t; relocation completes. (If not 'T~'/'T~&', I wonder
> if it should at least=C2=A0be a 'T&&'? Not su= re though...)

The problem with an rvalue refe= rence is that you then have to consistently do this:

=C2=A0

=C2=A0 >>A(A&& x)<= span style=3D"color: rgb(0, 0, 32); font-family: Consolas; font-size: 10pt;= "> : >>B= (std::move(x)), >>c(std::move(x.c)) {= }

=C2=A0


I think this would be inconvenience f= or the sake of inconvenience alone. Not much is gained, since an rvalue ref= erence is not needed to e.g. resolve an overload conflict.

A new reference type is a whole new animal altogether and probably= not warranted as long as this would be the only usage case. There is no te= chnical problem we'd be solving with a new reference type, just a subje= ctive problem of indication.

I would argue that in= dication is already handled sufficiently by the syntax >>A, so that there's no need to handle it= additionally via reference type, also.


=
> Might want to say, instead of "std::relocate,
>= defined as" with=C2=A0"might be defined as",

=
Good point. I have changed that to "behaving as follows&quo= t;.


> the relocator should also = be deleted if any
> subobject *lacks* a relocator (i.e. "not de= clared").

Good point. I have added this stipu= lation.


> I'm not sure this = is as tightly coupled to
> realloc_in_place as is suggested.

I agree, the championing of realloc_in_place was overdone. I have toned it down to= make it clear that the relocator proposal stands on its own, without it. := -)


> Where you run into problems= is if the base
> class relocator fiddles with memory that the=
> derived class still needed.

True. H= owever, I'd prefer for modification of the original object to be define= d behavior, and to let the user beware and not shoot themselves=C2=A0in the= foot; rather than to preclude access "for yer protection". :-)


On Thursday, August 13, 2015 at 10:12:15 = AM UTC-6, Matthew Woehlke wrote:
On 2015-= 08-11 15:45, isocp...@denisbider.com wrote:
> Good points, thank you!
>=20
> I have uploaded a new version of the draft addressing the followin= g:

Finally read it; sorry it took so long.

Thanks for the improved examples section!

I still wonder if the indirection for the relocation operator shouldn&#= 39;t
somehow indicate that the parameter will be destroyed when the outermos= t
relocation completes. (If not 'T~'/'T~&', I wonder = if it should at least
be a 'T&&'? Not sure though...)

> - proposed single object invocation is now similar to placement ne= w

Cool :-).

> - there is now an Annex 2 defining a proposed std::relocate_or_mov= e

Cool :-).

I wonder if there should also be single-object versions?

Nit: Might want to say, instead of "std::relocate, defined as"= ; with
"might be defined as", in case implementations need to insert= some
compiler voodoo to denote creation and deletion of objects in the
memmove case. (Presumably, the relocation operator has this built in,
but the trivial case isn't calling that...) Or, just if libraries c= ome
up with some better implementation. I don't think the actual defini= tion
needs to be codified, just the effect.

> - proposed implicit declaration rules have been relaxed, so that e= xplicitly=20
> defaulting a special member does not block implicit relocator decl= aration

Cool; thanks :-).

> - added explicit statement that lifetime of object in original loc= ation=20
> ceases when outermost relocator completes

Cool :-). I think we needed this, and your wording LGTM. Thanks.

> - added explicit statement that invocation of subobject relocator = outside=20
> of outer object relocation is undefined behavior

Erk... yes, it had better be ;-). Good catch; thanks.


Other comments:

I think this isn't exactly an omission vs. a language loophole that
should be closed, but the relocator should also be deleted if any
subobject *lacks* a relocator (i.e. "not declared"). Or if no= t declared
and the conditions for implicit declaration are not met. (Both will
close the loophole, the former might be preferred however.)

I'm not sure this is as tightly coupled to realloc_in_place as is
suggested. If we have realloc_in_place, we don't need relocation fo= r the
case where that succeeds. If we assume that realloc always fails, we
don't see any benefit from realloc_in_place. (That's not to say= that we
don't *want* realloc_in_place, just that Annex 1 makes it sound lik= e
both are significantly less useful without the other, which I don't
believe is true. I think they are closer to orthogonal.)

Overall, looks very good; thanks again!

>> the second form should take an 'A[]' rather than an &#= 39;A*'.
>=20
> I have decided against this because the argument may in fact be a = slice of=20
> an array, not a whole array. Overlapping memory is also explicitly= =20
> supported, so I would not like to suggest that only a whole array = may be=20
> passed.

Okay, I can follow that.

>> (Which also makes me wonder if relocation should be const w.r.= t.
>> the old object?)
>=20
> I think not, because:
>=20
> - the user may want to explicitly destroy subobjects if initializi= ng their=20
> counterparts via means other than relocation;
>=20
> - the user may want to zero out memory being moved from.

These are good points, but can cut both ways. Where you run into
problems is if the base class relocator fiddles with memory that the
derived class still needed.

I'm not saying I feel strongly about it either way, just trying to
explore the possible consequences of either decision.

>> I've seen try_realloc more often than realloc_in_place.
>=20
> I find realloc_in_place more descriptive.

Fair enough; I meant it more as an observation.

--=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_186_1888314699.1439521133557-- ------=_Part_185_1486388530.1439521133556-- .