220 19733 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: Sun, 9 Aug 2015 03:57:09 -0700 (PDT) Lines: 753 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> <94331665-f7f3-444b-a1dc-333a52be7873@isocpp.org> <5A4BB28D-A1EE-4B78-99FF-6BCFEA7E2FF3@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3543_1715180924.1439117829563" X-Trace: ger.gmane.org 1439117836 18295 80.91.229.3 (9 Aug 2015 10:57:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 10:57:16 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBBXETSXAKGQEBYXRVPA@isocpp.org Sun Aug 09 12:57:15 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOOHx-0005au-C9 for gclcip-std-proposals@m.gmane.org; Sun, 09 Aug 2015 12:57:13 +0200 Original-Received: by ioei189 with SMTP id i189sf241431280ioe.0 for ; Sun, 09 Aug 2015 03:57:12 -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=VQQlFq4nRLegWuRIkWQYaqTlRxRMDr1nbo8z1VBEcZw=; b=A823hCHeySJQGuB9ba9cStGmx+iBDV1fhubOEiiLlbABsSV9HGtMvs3nJ9QhwKriSk ZZT3hSpSuTou0g91KUX7RZ+UZ7dZhQWg+YZczetRmVOBn2XZEaPD1PnTJcVUtI2kLCyT yjVQeqR/5jPsGrG8jIJEstnio5eTZ3Qp0essqjygLdXsqar1D9rwK/myZm6eRxadgE7a K54OipIf/GNOQW8tNhFwZtTL+LNsp64t23MH+ssmWcZzrOvg39ifMC6SoQmBRz3GQn7h 2eOksv5YaWRlbhRtdPP0BD50ouqQXdL31NSroB7acEswqrmxmWQCvKHDMw1XFWbgkbrM sWlg== X-Gm-Message-State: ALoCoQnsLixEN4ds4n7jERiUnM1zPMgBphiQFJwuaEJUMgL4Sl0Px1WYcXjVCMb71f287OzAs0SK X-Received: by 10.182.94.240 with SMTP id df16mr14365691obb.17.1439117831850; Sun, 09 Aug 2015 03:57:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.97.226 with SMTP id m89ls2686831qge.62.gmail; Sun, 09 Aug 2015 03:57:10 -0700 (PDT) X-Received: by 10.140.94.168 with SMTP id g37mr96421qge.13.1439117830536; Sun, 09 Aug 2015 03:57:10 -0700 (PDT) In-Reply-To: <5A4BB28D-A1EE-4B78-99FF-6BCFEA7E2FF3@gmail.com> 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:19733 Archived-At: ------=_Part_3543_1715180924.1439117829563 Content-Type: multipart/alternative; boundary="----=_Part_3544_663496519.1439117829564" ------=_Part_3544_663496519.1439117829564 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > If construction order is indeed more appropriate (which I > think you are correct on), doesn=E2=80=99t it speak that this is > more naturally thought of as a destructive move constructor? Yes, I think you're very right! I have updated the proposal with an annex that presents an alternate=20 constructor-like syntax, and discusses the merits and demerits of the two= =20 approaches: http://denisbider.com/Relocator.pdf It seems to me that the constructor-like approach may in fact be superior;= =20 no more complex, yet more intuitive; and potentially more extensible, if=20 needed. If folks like this, I'm leaning to promote constructor-like syntax from the= =20 annex, and place it in the center of the proposal. > distinction between the multiple & single relocators? Yes - it's just a formal distinction to emphasize cost-less optimization of= =20 the single-object case. I have added to the text to make this clearer. > The static keyword preceding the function A::~A > seems out-of-place no? It is illegal in the definition, yes. It's okay in the declaration. I have changed the definition to put "static" into C-style comments. I'm=20 still keeping it, to make it clear that the wrappers are invoked as static= =20 members. > it sounds like this is trying to solve the memcpy problem > but it seems like it solves both that & realloc, no? To properly solve the realloc problem, it would be necessary to have the=20 equivalent of realloc_in_place. If realloc_in_place or equivalent fails: - The equivalent of malloc needs to be used to allocate new memory, while= =20 keeping old memory. - The static relocator needs to be called to move objects from old location= =20 to new. This could be as trivial as memcpy, or may require fix-ups. - The old memory is freed. In the absence of realloc_in_place; and for trivially relocatable objects= =20 only; it would work for a container to call realloc, also. To permit use with realloc with non-trivially relocatable objects, the=20 relocator would have to: - use constructor-like syntax (the old location is gone when it is called); - accept a ptrdiff_t instead of reference to the old location. The ptrdiff_t would be the offset between the old location and the new one,= =20 and would allow the relocator to perform any patch-ups.=20 The drawback of this approach is that, if you have a small object; e.g.=20 libc++ std::string, which is just one pointer in size; and this object=20 requires a patch-up during relocation; it's twice as costly to execute=20 realloc + patch-up, than to execute a relocator that performs the copy as= =20 part of its process. Basically, the lack of a realloc_in_place or equivalent is the=20 deficiency. A feature such as relocation should not be designed around a=20 library deficiency that should relatively trivial to solve. > does "user-declared=E2=80=9D also cover declarations that are "=3D defaul= t=E2=80=9D? Yes, it does. For example, if you have this: struct B { B(B const&) { ... } B(B&&) { ... } }; struct A : B { A(A const&) =3D default; }; The user declaration of A(A const&) - even as default - blocks an implicit= =20 declaration of a move constructor for A. To get an implicitly defined move= =20 constructor, one must use either this: struct A : B { }; or this: struct A : B { A(A const&) =3D default; A(A&&) =3D default; }; On Saturday, August 8, 2015 at 4:27:16 PM UTC-6, vlovich wrote: > I like many things about this proposal & thank you for trying to tackle= =20 > this. Apologies if already covered, but can you clarify why there is a= =20 > distinction between the multiple & single relocators? Am I correct in=20 > guessing that it=E2=80=99s to try & avoid the loop overhead when you only= have a=20 > single object? Some other reason? > > The =E2=80=9Ccomposition=E2=80=9D section seems to read kind of contradic= tory to the=20 > terminology being used to frame the solution. If construction order is= =20 > indeed more appropriate (which I think you are correct on), doesn=E2=80= =99t it=20 > speak that this is more naturally thought of as a destructive move=20 > constructor? Beyond just semantics, I think users writing their own may= =20 > easily get confused about which order they need to destroy/construct & bu= gs=20 > in this area will be very subtle, hard-to-find & particularly nasty. > > nitpicks: > > The static keyword preceding the function A::~A seems out-of-place no? I= =20 > could be mistaken, but the static keyword is illegal in this context & ca= n=20 > only be there on free-standing functions or on functions as part of the= =20 > class declaration; it cannot be used for external class function=20 > definition. Is the static keyword in this place new to this proposal or= =20 > C++17? > > While discussion relocation, there is what amounts to a footnote=20 > mentioning realloc. Is it correct that this is the language proposal tha= t=20 > would complement any eventual library features that would enable the use = of=20 > realloc within containers? I think that could do with some clarification= =20 > to properly frame the discussion; it sounds like this is trying to solve= =20 > the memcpy problem but it seems like it solves both that & realloc, no? > > I=E2=80=99m not very familiar with the standardese terminology, so apolog= ies for=20 > the silly question, but In the "Implicit relocator=E2=80=9D section, does= =20 > "user-declared=E2=80=9D also cover declarations that are "=3D default=E2= =80=9D? > > Thanks, > Vitali > > > On Aug 8, 2015, at 1:37 AM, isocp...@denisbider.com wrote: > > I have published an updated draft: > > http://www.denisbider.com/Relocator.pdf > > I have consistently renamed move destructor -> relocator and move=20 > destruction -> relocation. Reason is explained in a new section,=20 > Rationales, on last page. > > > Comments: > > > Might want to explain "destructive move" > > in the opening paragraph.=20 > > Very good, done. > > > > - 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=20 > > constructor and "interesting" destructor.=20 > > I've spent a fair amount of time thinking about this, but I cannot think= =20 > of a container scenario involving unique_ptr that's worse than string.=20 > unique_ptr already has nothrow move construction; and has nothrow=20 > destruction as long as the object has nothrow destruction; and in any cas= e,=20 > it will not throw after a move. I'm having some trouble conjuring a=20 > situation where the lack of relocation for unique_ptr does not result in= =20 > strictly a performance penalty for having to execute a non-trivial=20 > destructor. > > Did you have a specific scenario involving unique_ptr in mind? > > > > In the defaulted example, s.b. ~int(int&). > > Good point, done that. > > > > explain elsewhere when a cting-dtor is trivial > > Edited text where trait types are defined in an attempt to better explain= =20 > this. > > > > The multiple object helper should work > > on overlapping memory. > > It should indeed. :) Fixed! > > > > 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 current rules for move constructor= =20 > wouldn't implicitly declare one if a copy constructor or destructor, or= =20 > any other special member, is user-declared. The way I read 12.8, para 9,= =20 > the following: > > struct A { > A(A const&) =3D default; > }; > > would result in a move constructor NOT being implicitly declared. > > As far as I can test right now, this is the case. If A inherits from B,= =20 > which implements both move and copy construction, I can observe that tryi= ng=20 > to move A actually results in copy construction of B. I need add: > > struct A : B { > A(A const&) =3D default; > A(A&&) =3D default; > }; > > ... in order for B(B&&) to be called. > > For consistency as well as safety, it would make sense to me to use the= =20 > same rules for the relocator. > > > > 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= =20 > discussion in the Rationales section. > > > > 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,= =20 > so one of the two orders have to be chosen. I have added a section for th= is=20 > in the Rationales section. > > I hope also that calling the special member a "relocator"; expressing its= =20 > duality and impartiality, rather than a bias toward construction or=20 > destruction; might also help alleviate this concern. > > > > 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:=20 >> > I believe the destructive move Jesus is upon us!=20 >> >=20 >> > I have uploaded the following draft:=20 >> >=20 >> > http://www.denisbider.com/MoveDestructor.pdf=20 >> >> Editorial comments:=20 >> >> - Might want to explain "destructive move" in the opening paragraph.=20 >> >> - Might want to mention std::unique_ptr? This is a really simple example= =20 >> of a class that is trivially relocatable but has an "interesting" move= =20 >> constructor and "interesting" destructor.=20 >> >> >> Nits:=20 >> >> - In the defaulted example, s.b. ~int(int&). That is, define the default= =20 >> behavior as cting-dtor for ALL members, and explain elsewhere when a=20 >> cting-dtor is trivial (i.e. for POD types; the "consists of trivially=20 >> relocatable members" case seems sufficiently covered) and that trivial= =20 >> means to just copy the bits. (Also, it's expected that the compiler will= =20 >> combine trivial cting-dtors of adjacent members into a single memcpy.)= =20 >> At least, I'd do that... seems cleaner. (Shouldn't actually change=20 >> anything.)=20 >> >> >> Not-so-nits:=20 >> >> - The multiple object helper should work on overlapping memory. I=20 >> imagine you intended this, but I don't see any wording to that effect;= =20 >> it seems to me that such wording may be important.=20 >> >> - Should(n't) the cting-dtor be implicit-default if the class has a) a= =20 >> *default* move ctor *or copy ctor*, *and* b) a default dtor, whether or= =20 >> not such are declared?=20 >> >> - I feel fairly strongly that there should be a cutoff point for which= =20 >> we can use the same syntax to relocate objects that can't be simply=20 >> relocated. I proposed that there is *always* a cting-dtor (except for=20 >> objects that explicitly delete it, or can't be copied/moved and/or=20 >> destroyed at all, i.e. the fallback implementation would be ill-formed),= =20 >> but at any rate, I think the helpers should work regardless.=20 >> >> - I'm not entirely confident that the composition case is solved. As=20 >> worded, the class members are relocated after the base class has been=20 >> destroyed (moveover, the derived class itself is technically "destroyed"= =20 >> after the base class has been destroyed), which seems like it could=20 >> present problems... :-( Unfortunately I don't have any suggestions here.= =20 >> I do hope that this won't kill the proposal though.=20 >> >> >> Comments:=20 >> >> - It took me a minute or two to understand the invocation helpers, but= =20 >> now that I do, I like! IIUC what these mean is that instead of libraries= =20 >> having to check a type trait and write a memmove themselves, the=20 >> compiler will do so. Cool!=20 >> >> >> Bikesheds (JFTR):=20 >> >> - ~A(A&) vs. ~A(A*) vs. ~A(void*).=20 >> >> - "cting-dtor" vs. "move-dtor" ;-).=20 >> >> - Type trait names.=20 >> >> >> Thanks for sticking with this!=20 >> >> --=20 >> Matthew=20 >> >> > --=20 > > ---=20 > You received this message because you are subscribed to the Google Groups= =20 > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to std-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org . > Visit this group at=20 > http://groups.google.com/a/isocpp.org/group/std-proposals/. > > > --=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_3544_663496519.1439117829564 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> If construction order is indeed more appropriate= (which I
> think you are correct on), doesn=E2=80=99t it speak that = this is
> more naturally thought of as a destructive move constructor= ?

Yes,=C2=A0I think you're=C2=A0very right!

I have updated the proposal with an annex that prese= nts an alternate constructor-like syntax, and discusses the merits and deme= rits of the two approaches:

=

It seems to me that the constructor-like approach may i= n fact be superior; no more complex,=C2=A0yet more intuitive; and potential= ly more extensible, if needed.

If folks like this,= I'm leaning to=C2=A0promote constructor-like syntax=C2=A0from the anne= x, and=C2=A0place it in the center of the proposal.


> distinction between the multiple & single relocat= ors?

Yes - it's just a formal distinction to= =C2=A0emphasize cost-less optimization of the single-object case. I have ad= ded=C2=A0to the text=C2=A0to make this clearer.

> The static keyword preceding the function=C2=A0A::~A
> seems out-of-place no?

It is illegal in= the definition, yes. It's okay in the declaration.

I have changed the definition to put "static" into C-style = comments. I'm still keeping it, to=C2=A0make it clear that the wrappers= are=C2=A0invoked as static members.


> it sounds like this is trying to solve the memcpy problem
= > but it seems like it solves both that & realloc, no?
To properly solve the real= loc problem, it would be necessary to have=C2=A0the equivalent of=C2= =A0realloc_in_place.
=
If realloc_in_place or equivalent fails:

- The equivalent of mallo= c needs to be used to allocate new memory, while keeping old memory.
<= div>
- The static relocator needs to be called to move object= s from old location to new. This could be as trivial as memcpy, or may requ= ire fix-ups.

- The old memory is freed.
=
In the absence of reall= oc_in_place; and for trivially relocatable objects only; it would wo= rk for a container to call realloc, also.

To permit use with realloc with=C2=A0non-trivially relocatable=C2=A0ob= jects, the relocator would have to:

- use construc= tor-like syntax (the old location is gone when it is called);
- accept a ptrdiff_t instead of reference to the old location.

The ptrdiff_t would be the offset bet= ween the old location and the new one, and would allow the relocator to=C2= =A0perform any patch-ups.=C2=A0

The drawback of th= is approach is that, if you have a small object; e.g. libc++ std::string, w= hich is just=C2=A0one pointer=C2=A0in size; and this object requires a patc= h-up during relocation; it's twice as costly to execute realloc + patch= -up, than to execute a relocator that performs the copy as part of its proc= ess.

Basically, the lack of a realloc_in_place or equivalent is the deficiency.= =C2=A0A feature such as relocation should not be designed around a library = deficiency that should=C2=A0relatively trivial to solve.


> does "user-declared=E2=80=9D also cover dec= larations that are "=3D default=E2=80=9D?

Yes= , it does. For example, if you have this:

=C2=A0 struct B {
=C2=A0 =C2=A0 B(B const&) { ... }
=C2=A0 =C2=A0 B(B&&) { = .... }
=C2=A0 };

=C2=A0 struct A : B {
=C2=A0 =C2=A0 A(A const&) =3D default= ;
=C2=A0 };

The user declaration of A(A const&) -=C2=A0even = as default -=C2=A0blocks an implicit declaration of a=C2=A0move constructor= for A. To get an implicitly defined move constructor, one must use either = this:

=C2=A0 = struct A : B {
=C2=A0= };

or this:

= =C2=A0 struct A : B {
=C2=A0 =C2=A0 A(A const&) = =3D default;
=C2=A0= =C2=A0 =C2=A0A(A&&) =3D default;
=C2=A0 };


On Saturday, August= 8, 2015 at 4:27:16 PM UTC-6, vlovich wrote:
I like many things about this= proposal & thank you for trying to tackle this. =C2=A0Apologies if alr= eady covered, but can you clarify why there is a distinction between the mu= ltiple & single relocators? =C2=A0Am I correct in guessing that it=E2= =80=99s to try & avoid the loop overhead when you only have a single ob= ject? =C2=A0Some other reason?

The =E2=80=9Ccomposition= =E2=80=9D section seems to read kind of contradictory to the terminology be= ing used to frame the solution. =C2=A0If construction order is indeed more = appropriate (which I think you are correct on), doesn=E2=80=99t it speak th= at this is more naturally thought of as a destructive move constructor? =C2= =A0Beyond just semantics, I think users writing their own may easily get co= nfused about which order they need to destroy/construct & bugs in this = area will be very subtle, hard-to-find & particularly nasty.
=
nitpicks:

The static keyword preced= ing the function=C2=A0A::~A seems out-of-place no? =C2=A0I could be mistake= n, but the static keyword is illegal in this context & can only be ther= e on free-standing functions or on functions as part of the class declarati= on; it cannot be used for external class function definition. =C2=A0Is the = static keyword in this place new to this proposal or C++17?

<= /div>
While discussion relocation, there is what amounts to a foot= note mentioning realloc. =C2=A0Is it correct that this is the language prop= osal that would complement any eventual library features that would enable = the use of realloc within containers? =C2=A0I think that could do with some= clarification to properly frame the discussion; it sounds like this is try= ing to solve the memcpy problem but it seems like it solves both that &= realloc, no?

I=E2=80=99m not very familiar = with the standardese terminology, so apologies for the silly question, but = In the "Implicit relocator=E2=80=9D section, does "user-declared= =E2=80=9D also cover declarations that are "=3D default=E2=80=9D?

Thanks,
Vitali


=
On Aug 8, 2015, at 1:37 AM, isocp...@de= nisbider.com wrote:

I have publishe= d an updated draft:


I have c= onsistently renamed move destructor -> relocator and move destruction -&= gt; relocation.=C2=A0Reason is=C2=A0explained in a new section, Rationales,= on last page.


Comments:
=
> Might want to explain "destructive move"
> in the opening paragraph.

Very good, d= one.


> - Might want to mention s= td::unique_ptr?
> This is a really simple example=C2=A0 of a c= lass that is
> trivially relocatable but has an "interest= ing" move
> constructor and "interesting" destructor.=

I've spent a fair amount of time thinkin= g about this, but I cannot think of a container scenario involving unique_p= tr that's worse than string. unique_ptr already has nothrow move constr= uction; and has nothrow destruction as long as the object has nothrow destr= uction; and in any case, it=C2=A0will not throw after a move. I'm havin= g some trouble conjuring a situation where the lack of relocation for uniqu= e_ptr does not result in strictly a performance penalty for having to execu= te a non-trivial destructor.

Did you have a specific scenario= involving unique_ptr in mind?


>= In the defaulted example, s.b. ~int(int&).

Go= od point, done that.


> expla= in elsewhere when a cting-dtor is trivial

Edited t= ext where trait types are defined in an attempt to better explain this.


> The multiple object helper should= work
> on overlapping memory.

It sho= uld indeed. :) Fixed!


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

= Hmm. I wouldn't necessarily mind, but current rules for move constructo= r wouldn't implicitly declare one if a copy constructor or destructor, = or any=C2=A0other special member, is user-declared.=C2=A0The way I read 12.= 8, para 9, the following:

struct A {
=C2=A0 A(A const&) =3D default;
};

would result in a move= constructor NOT being implicitly declared.

As far= as I can test right now, this is the case. If A inherits from B, which imp= lements=C2=A0both move=C2=A0and copy construction,=C2=A0I can observe that = trying to move A actually results in copy construction of B. I need add:

struct A := B=C2=A0{
=C2=A0= A(A const&) =3D default;
=C2=A0 A(A&&) =3D default;
};

... in order for B(B&a= mp;&) to be called.

For consistency as well as= safety, it would make sense to me to use the same rules for the relocator.=


> I feel fairly strongly that t= here should be a cutoff point
> for which we can use the same = syntax to relocate
> objects that can't be simply relocate= d.

I agree, but I think it should be at a level ab= ove this. I have added a discussion in the Rationales section.

> I'm not entirely confident that the co= mposition case is
> solved. As worded, the class members are r= elocated
> after the base class has been destroyed
<= br>
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 sect= ion for this in the Rationales section.

I hope als= o that calling the special member a "relocator"; expressing its d= uality and impartiality, rather than a bias toward construction or destruct= ion;=C2=A0might also help alleviate this concern.

=

On Friday, August 7, 2015 at 3:32:51 PM UTC-6, Mat= thew Woehlke wrote:
On 2015-08-07 16:47, = isocp...@denisbider.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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/i= socpp.org/group/std-proposals/.

--

---
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_3544_663496519.1439117829564-- ------=_Part_3543_1715180924.1439117829563-- .