220 19786 <80721d48-888b-4dc8-b938-28f2ca329f04@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: Tue, 11 Aug 2015 12:45:55 -0700 (PDT) Lines: 446 Approved: news@gmane.org Message-ID: <80721d48-888b-4dc8-b938-28f2ca329f04@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-444b-a1dc-333a52be7873@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5883_731942981.1439322355380" X-Trace: ger.gmane.org 1439322360 27584 80.91.229.3 (11 Aug 2015 19:46:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2015 19:46:00 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRB5FBVGXAKGQESMKCV7Q@isocpp.org Tue Aug 11 21:45:59 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZPFUk-0000Xl-Ub for gclcip-std-proposals@m.gmane.org; Tue, 11 Aug 2015 21:45:59 +0200 Original-Received: by pdbpr2 with SMTP id pr2sf354561735pdb.3 for ; Tue, 11 Aug 2015 12:45:57 -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=uOykTzdxT3EZJHNg6z9fZNX8sqV4W4asloFPDb+EEAc=; b=Vw/d2UyaMkyWUhqayx04PPkouxNXgLOAnQz88dnKZWtWwxdqMgU0TErNonKfHH9OXO qNy0TXsBnPWTGFUmNqGF3Wl7N1o2V5K0AWy8BOY0+YV6kg2bgtAMiBBm1CR0a9pV8IIx hJMGIW3WEWQroXfL71FbhiKkylsEktj++fE6CIz/gn9CaXFAeRp8ejWB3BWYjaeCaoV6 ikZzHDmnQLLXL8gZJ8+lvmG54MbKPrKvUxNLbARX8qwSHzGj0AO/+f5otJXCBs6EE6LR vS+x3JPaV7Fj4P4GEYLQdhc2MULCc5dd0T+grmVKIQ054bzqrp7gWGvjqvWouyWmAiBQ sR0A== X-Gm-Message-State: ALoCoQkZXTv+hQwgzJnA6ErTHYaGLz47T7/y0TwZChOi/EVEa0J1zUi1ujUw/0bEXpGFc3ie0I0r X-Received: by 10.66.197.230 with SMTP id ix6mr26027636pac.1.1439322357723; Tue, 11 Aug 2015 12:45:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.41.38 with SMTP id y35ls3887973qgy.82.gmail; Tue, 11 Aug 2015 12:45:56 -0700 (PDT) X-Received: by 10.140.25.144 with SMTP id 16mr63853qgt.41.1439322356407; Tue, 11 Aug 2015 12:45:56 -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:19786 Archived-At: ------=_Part_5883_731942981.1439322355380 Content-Type: multipart/alternative; boundary="----=_Part_5884_61882751.1439322355381" ------=_Part_5884_61882751.1439322355381 Content-Type: text/plain; charset=UTF-8 Good points, thank you! I have uploaded a new version of the draft addressing the following: - proposed single object invocation is now similar to placement new - there is now an Annex 2 defining a proposed std::relocate_or_move - proposed implicit declaration rules have been relaxed, so that explicitly defaulting a special member does not block implicit relocator declaration - added explicit statement that lifetime of object in original location ceases when outermost relocator completes - added explicit statement that invocation of subobject relocator outside of outer object relocation is undefined behavior New version: http://denisbider.com/Relocator.pdf > 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. > (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. > I'm not sure I agree that argument order for a cting-dtor > is counterintuitive :-). Besides whether or not cting-dtor syntax is intuitive - there's the additional issue that it doesn't blend well with this: >>A(A& x) : B(std::move(x)) { x.B::~B(); } Providing a way to do this with destructor-like syntax would be inventing alternate syntax for something we already have. > I've seen try_realloc more often than realloc_in_place. I find realloc_in_place more descriptive. Strictly speaking, the existing realloc already has "try" implied, since it won't block or abort the program if it fails. So the "try" is implied, and what one really wants to express is which sub-step of realloc one is attempting. > if you are growing a container in order to do a > middle insertion, and cannot grow in place, > it is more efficient to allocate uninitialized > memory and do a piecewise move Interesting point, very true. On Tuesday, August 11, 2015 at 8:22:44 AM UTC-6, Matthew Woehlke wrote: > On 2015-08-08 04:37, isocp...@denisbider.com wrote: > > I have published an updated draft: > > http://www.denisbider.com/Relocator.pdf > > > >> In the defaulted example, s.b. ~int(int&). > > > > Good point, done that. > > Thanks! > > >> The multiple object helper should work > >> on overlapping memory. > > > > It should indeed. :) Fixed! > > Thanks! > > >> 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? > > > > Hmm. I wouldn't necessarily mind, but [...] > > > > For consistency as well as safety, it would make sense to me to use the > > same rules for the relocator. > > To revisit this, my main "concern" is to not suppress relocatability for > classes that are trivially relocatable, merely because a copy/move ctor > or dtor was explicitly defaulted. IOW, relocation should always be > available if the default implementation is provably correct. Otherwise > we are penalizing existing code needlessly. > > > Er... on that note, I just realized, we probably should make it UB to > invoke the relocator on an object's base class outside of the relocator > itself doing > > IOW, this is UB: > > class Foo { public: virtual ~Foo(); ... }; > class Bar : public Foo { ... }; > > auto pfoo1 = new Bar; > auto pfoo2 = (Foo*)malloc(sizeof(Foo)); > pfoo1-> >>(*pfoo2); > > I don't see that this should be a problem with the proposal, since the > main use case is containers where the final type is definitely known and > the same on both ends of the relocation, but it would be possible to > write code like the above, and I don't see offhand how such code could > be made to do anything reasonable. > > >> 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 agree, but I think it should be at a level above this. I have added a > > discussion in the Rationales section. > > I can live with it, I guess. I'd feel better if the proposal also > specified such function, though. (std::relocate?) > > >> 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 > > > > The relocator performs the tasks of both a constructor and a destructor, > so > > one of the two orders have to be chosen. I have added a section for this > in > > the Rationales section. > > > > I hope also that calling the special member a "relocator"; expressing > its > > duality and impartiality, rather than a bias toward construction or > > destruction; might also help alleviate this concern. > > The only "true" solution I can envision is that the old base is not > destroyed until the new object is fully constructed. This would conflict > with the notion of relocation destroying the (old copy of the) thing > relocated. > > On the other hand, it's expected that relocation does not change the > actual bytes of the old object, so if relocation of the derived type > needs to read those, it can. (Which also makes me wonder if relocation > should be const w.r.t. the old object?) > > Anyway, still just thinking out loud, really... > > > > Okay, on to the new draft... > > I'm not sure I agree that argument order for a cting-dtor is > counterintuitive :-). Basically, the question here is if we use push > order (source first) or pull order (destination first). You're using > pull order, which honestly, IMHO is counterintuitive :-). OTOH, memcpy > also uses pull order. Essentially this is the same as the AT&T vs. Intel > assembly dialect... as much a matter of personal taste as anything. > > That said, I'd probably keep the static operator order as-is for > consistency with memcpy. The only other comment I'd make is that I feel > like there should be some indication that the source is destroyed by the > call. This is accomplished by cting-dtor, as you're calling a dtor. It's > also accomplished by e.g. 'T const~' (not sure if there should also be a > '&' there, or if '~' should imply by-reference...). > > Pedantic: I want to say I've seen try_realloc more often than > realloc_in_place. Not terribly important however since AFAIK neither > exists yet. > > Last, and not a comment on the paper as such, we really could use such a > function. Besides allowing us to work around using straight realloc (and > thus as mentioned, causing problems for static analysis tools), it may > be the case that a realloc is less efficient. As I just pointed out on > the Qt list, if you are growing a container in order to do a middle > insertion, and cannot grow in place, it is more efficient to allocate > uninitialized memory and do a piecewise move (which we can do with the > proposal in a "correct" manner) of the portions before and after the > insertion point to their correct final locations. > > > p.s. FWIW I do prefer the type trait names 'is_[trivially_]relocatable' > :-). > > -- > 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_5884_61882751.1439322355381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good points, thank you!

I ha= ve uploaded a new version of the draft addressing the following:
=
- proposed single object invocation is now similar to placem= ent new

- there is now an Annex 2 defining a propo= sed std::relocate_or_move
=

- proposed implicit declaration rules have been relaxed= , so that explicitly defaulting a special member does not block implicit re= locator declaration

- added explicit statement tha= t lifetime of object in original location ceases when outermost=C2=A0reloca= tor completes

- added explicit statement that invo= cation of subobject relocator outside of outer object relocation is undefin= ed behavior

New version:



> the second form s= hould take an 'A[]' rather than an 'A*'.

I have decided against this because the argument may in fact be a sl= ice of an array, not a whole array. Overlapping=C2=A0memory is also explici= tly supported, so=C2=A0I would not like to suggest that only a whole array = may be passed.


>=C2=A0 (Which al= so makes me wonder if relocation
> should be const w.r.t. the old ob= ject?)

I think not, because:

- the user may want to explicitly destroy subobjects if initializi= ng their counterparts via means other than relocation;

=
- the user may want to zero out memory being moved from.

> I'm not sure I agree that argument orde= r for a cting-dtor
> is=C2=A0counterintuitive :-).
<= br>
Besides whether or not=C2=A0cting-dtor syntax is intuitive -= =C2=A0there's the additional issue that it doesn't blend well with = this:

>>A(A& x) : B(std::move(x)) { x.B:= :~B(); }

Providing a way to do this with destructo= r-like syntax would=C2=A0be inventing alternate syntax for something=C2=A0w= e already have.


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

I fi= nd realloc_in_place more descri= ptive. Strictly speaking, the existing realloc already has "try" implied, since it won't blo= ck or abort the program if it fails. So the "try" is implied, and= what one really wants to express is which sub-step of realloc one is attempting.


>=C2=A0if you are growing a container in order to do a
> middle insertion, and cannot grow in place,
> it= is more efficient to allocate uninitialized
> memory and do a= piecewise move

Interesting point, very true.


On Tuesday, August 11, 2015 at 8:22:44 AM UTC-6, Matthew Woe= hlke wrote:
On 2015-08-08 04:37, isocp...@deni= sbider.com wrote:
> I have published an updated draft:
> http://www.denisbider.com/Relocator.pdf
>=20
>> In the defaulted example, s.b. ~int(int&).
>=20
> Good point, done that.

Thanks!

>> The multiple object helper should work
>> on overlapping memory.
>=20
> It should indeed. :) Fixed!

Thanks!

>> 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?
>=20
> Hmm. I wouldn't necessarily mind, but [...]
>=20
> For consistency as well as safety, it would make sense to me to us= e the=20
> same rules for the relocator.

To revisit this, my main "concern" is to not suppress relocat= ability for
classes that are trivially relocatable, merely because a copy/move ctor
or dtor was explicitly defaulted. IOW, relocation should always be
available if the default implementation is provably correct. Otherwise
we are penalizing existing code needlessly.


Er... on that note, I just realized, we probably should make it UB to
invoke the relocator on an object's base class outside of the reloc= ator
itself doing

IOW, this is UB:

=C2=A0 class Foo { public: virtual ~Foo(); ... };
=C2=A0 class Bar : public Foo { ... };

=C2=A0 auto pfoo1 =3D new Bar;
=C2=A0 auto pfoo2 =3D (Foo*)malloc(sizeof(Foo));
=C2=A0 pfoo1-> >>(*pfoo2);

I don't see that this should be a problem with the proposal, since = the
main use case is containers where the final type is definitely known an= d
the same on both ends of the relocation, but it would be possible to
write code like the above, and I don't see offhand how such code co= uld
be made to do anything reasonable.

>> 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.
>=20
> I agree, but I think it should be at a level above this. I have ad= ded a=20
> discussion in the Rationales section.

I can live with it, I guess. I'd feel better if the proposal also
specified such function, though. (std::relocate?)

>> 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
>=20
> The relocator performs the tasks of both a constructor and a destr= uctor, so=20
> one of the two orders have to be chosen. I have added a section fo= r this in=20
> the Rationales section.
>=20
> I hope also that calling the special member a "relocator"= ;; expressing its=20
> duality and impartiality, rather than a bias toward construction o= r=20
> destruction; might also help alleviate this concern.

The only "true" solution I can envision is that the old base = is not
destroyed until the new object is fully constructed. This would conflic= t
with the notion of relocation destroying the (old copy of the) thing
relocated.

On the other hand, it's expected that relocation does not change th= e
actual bytes of the old object, so if relocation of the derived type
needs to read those, it can. (Which also makes me wonder if relocation
should be const w.r.t. the old object?)

Anyway, still just thinking out loud, really...



Okay, on to the new draft...

I'm not sure I agree that argument order for a cting-dtor is
counterintuitive :-). Basically, the question here is if we use push
order (source first) or pull order (destination first). You're usin= g
pull order, which honestly, IMHO is counterintuitive :-). OTOH, memcpy
also uses pull order. Essentially this is the same as the AT&T vs. = Intel
assembly dialect... as much a matter of personal taste as anything.

That said, I'd probably keep the static operator order as-is for
consistency with memcpy. The only other comment I'd make is that I = feel
like there should be some indication that the source is destroyed by th= e
call. This is accomplished by cting-dtor, as you're calling a dtor.= It's
also accomplished by e.g. 'T const~' (not sure if there should = also be a
'&' there, or if '~' should imply by-reference...).

Pedantic: I want to say I've seen try_realloc more often than
realloc_in_place. Not terribly important however since AFAIK neither
exists yet.

Last, and not a comment on the paper as such, we really could use such = a
function. Besides allowing us to work around using straight realloc (an= d
thus as mentioned, causing problems for static analysis tools), it may
be the case that a realloc is less efficient. As I just pointed out on
the Qt list, if you are growing a container in order to do a middle
insertion, and cannot grow in place, it is more efficient to allocate
uninitialized memory and do a piecewise move (which we can do with the
proposal in a "correct" manner) of the portions before and af= ter the
insertion point to their correct final locations.


p.s. FWIW I do prefer the type trait names 'is_[trivially_]relocata= ble' :-).

--=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_5884_61882751.1439322355381-- ------=_Part_5883_731942981.1439322355380-- .