220 19725 <94331665-f7f3-444b-a1dc-333a52be7873@isocpp.org> article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Move destructor draft Date: Fri, 7 Aug 2015 13:47:13 -0700 (PDT) Lines: 229 Approved: news@gmane.org Message-ID: <94331665-f7f3-444b-a1dc-333a52be7873@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_758_1083495404.1438980433169" X-Trace: ger.gmane.org 1438980437 7662 80.91.229.3 (7 Aug 2015 20:47:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 20:47:17 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBUVSSSXAKGQEHFDCVKI@isocpp.org Fri Aug 07 22:47:17 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZNoXs-0002de-Qk for gclcip-std-proposals@m.gmane.org; Fri, 07 Aug 2015 22:47:16 +0200 Original-Received: by oio137 with SMTP id 137sf166424391oio.2 for ; Fri, 07 Aug 2015 13:47:15 -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=EJK9jfBTZ0y5cmDf/kqtBw2+xeBM8pQw/ikbK4D1Oro=; b=Oz91eL99CGR3GoQeb0mOnSZkM9soQx88z9hAlUvM69iAHco9B6+bMyiYvw5+IlGdJU SBKSXRujjubse0N0K83/rFhjiVpKv2S3iQADNPHHKEo7hlGI0zfvG1KCOg5Om9biRDR3 tGdU3j4TTFs/x/W9dLu2i+ppH5WLck2OyJ2L0reh1UQqxxLiF4LxXrnSrv4gLI64kKR8 HRp9dtQPY48AbFUKjHcEsrnZs3ZvVdQA0TwHHpwiKv2COiySJ/QNTmr1jQ6G2nVNMQUc hgeijZV1oB3OmumTGh260MTQw7sYLSPTyfty9+Li/GTGZGdd+5BmOiBsMnVk5QwlBtnM ZsQg== X-Gm-Message-State: ALoCoQnW4CDNiA/WkAMM0hJfJw5/6/BcmT6RDCc8e1Rup4rE/SL8UmLfjvuR9zrXXpkgXwaW8fIo X-Received: by 10.182.142.99 with SMTP id rv3mr7041191obb.2.1438980435573; Fri, 07 Aug 2015 13:47:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.40.42 with SMTP id w39ls2059568qgw.0.gmail; Fri, 07 Aug 2015 13:47:14 -0700 (PDT) X-Received: by 10.140.101.243 with SMTP id u106mr107237qge.27.1438980434062; Fri, 07 Aug 2015 13:47:14 -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:19725 Archived-At: ------=_Part_758_1083495404.1438980433169 Content-Type: multipart/alternative; boundary="----=_Part_759_732086829.1438980433169" ------=_Part_759_732086829.1438980433169 Content-Type: text/plain; charset=UTF-8 Hello everyone, I believe the destructive move Jesus is upon us! I have uploaded the following draft: http://www.denisbider.com/MoveDestructor.pdf @Matthew: > What if doing a memcpy is *wrong*? Now you've wasted a > bunch of work copying data that isn't useful. True. I have addressed this in the above draft. @Edward: > How does that deal with composition? Same way constructors deal with composition. I invite you to check out the above draft. @Matthew: > IMO the implicit behavior should definitely be the boring behavior, > i.e. invoke a copy/move ctor and the regular dtor. I disagree with this very passionately. This is a similar kind of default-bundling as getting IE with Windows. Move destructor invoking copy/move ctor: - Prevents the move destructor from being able to always provide the noexcept guarantee. - Takes choice away from the user. The user may want to use destructive move if it's available; but otherwise, something else. - Provides trifling convenience than can be trivially provided with a template along the lines of move_if_noexcept. If you check out the draft, feedback would be appreciated. On Friday, August 7, 2015 at 10:08:05 AM UTC-6, Matthew Woehlke wrote: > On 2015-08-07 11:42, isocp...@denisbider.com wrote: > > StringType* StringType::~StringType(void* d, StringType* s, std::size_t > n=1); > > > > This would perform the destructive move of one or more objects as a > > transaction, just like invoking keywords new or delete is a transaction. > > The "one *or more*" (emphasis added) part would be a significant > departure from the current language rules. I'm having a hard time seeing > the justification. > > The closest we have currently is delete[], which still calls each > object's dtor individually. > > If nothing else, 'this' makes no sense in such a context, i.e. you are > at least missing a 'static'. > > > It makes most sense to me that the implementation of this transactional > > move concept performs the equivalent of memcpy for an object before > calling > > the move destructor. It makes things a lot simpler. > > ...and far less generic. > > What if doing a memcpy is *wrong*? Now you've wasted a bunch of work > copying data that isn't useful. > > Having something like a cting-dtor has obvious benefit (don't waste work > maintaining the old object in a valid state when it's about to be > destroyed anyway). Having a cting-dtor *that can be trivial* has > *enormous* obvious value; many, many objects can be trivially > "relocated"... and indeed libraries already do this despite that it is > UB; having a way to "bless" such operation has obvious benefit. > > I'm less convinced that there is significant benefit to optimizing > corner cases. The *only* benefit, AFAICT, to e.g. the std::string case > is merging the memcpy's for an array of such objects into a larger memcpy. > > Do you have benchmarks showing that this is a significant improvement? > Keep in mind that the small memcpy will most likely be inlined, and that > there is at least a branch per object in either case in addition to > whatever memcpy(s) happen. (If the patch-up operator isn't inlined, > that's probably going to swamp the memcpy(s).) > > -- > 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_759_732086829.1438980433169 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

I believe th= e destructive move Jesus is upon us!

=C2=A0I have = uploaded the following draft:



@Matthew:

=
> What if doing a memcpy is *wrong*? Now you've wasted a =
> bunch of work=C2=A0copying data that isn't useful.

True. I have addressed this in the above draft.
=


@Edward:

> H= ow does that deal with composition?

Same way const= ructors deal with composition. I invite you to check out the above draft.


@Matthew:

&= gt; IMO the implicit behavior should definitely be the boring behavior,
> i.e. invoke a copy/move ctor and the regular dtor.

I disagree with this very passionately. This is a similar = kind of=C2=A0default-bundling as getting IE with Windows.

Move destructor=C2=A0invoking copy/move ctor:

<= div>- Prevents the move destructor from being able to always provide the no= except guarantee.

- Takes choice away from the use= r. The user may want to use destructive move if it's available; but oth= erwise, something else.

- Provides=C2=A0trifling c= onvenience than can be trivially provided with a template along the lines o= f move_if_noexcept.
<= br>

If you=C2=A0check out the draft,=C2=A0feedback= would be appreciated.


On Friday, August 7, 2015 at 10:08= :05 AM UTC-6, Matthew Woehlke wrote:
On 2= 015-08-07 11:42, isocp...@denisbider.com wrote:
> StringType* StringType::~StringType(void* d, StringType* s, std::s= ize_t n=3D1);
>=20
> This would perform the destructive move of one or more objects as = a=20
> transaction, just like invoking keywords new or delete is a transa= ction.

The "one *or more*" (emphasis added) part would be a signific= ant
departure from the current language rules. I'm having a hard time s= eeing
the justification.

The closest we have currently is delete[], which still calls each
object's dtor individually.

If nothing else, 'this' makes no sense in such a context, i.e. = you are
at least missing a 'static'.

> It makes most sense to me that the implementation of this transact= ional=20
> move concept performs the equivalent of memcpy for an object befor= e calling=20
> the move destructor. It makes things a lot simpler.

...and far less generic.

What if doing a memcpy is *wrong*? Now you've wasted a bunch of wor= k
copying data that isn't useful.

Having something like a cting-dtor has obvious benefit (don't waste= work
maintaining the old object in a valid state when it's about to be
destroyed anyway). Having a cting-dtor *that can be trivial* has
*enormous* obvious value; many, many objects can be trivially
"relocated"... and indeed libraries already do this despite t= hat it is
UB; having a way to "bless" such operation has obvious benefi= t.

I'm less convinced that there is significant benefit to optimizing
corner cases. The *only* benefit, AFAICT, to e.g. the std::string case
is merging the memcpy's for an array of such objects into a larger = memcpy.

Do you have benchmarks showing that this is a significant improvement?
Keep in mind that the small memcpy will most likely be inlined, and tha= t
there is at least a branch per object in either case in addition to
whatever memcpy(s) happen. (If the patch-up operator isn't inlined,
that's probably going to swamp the memcpy(s).)

--=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_759_732086829.1438980433169-- ------=_Part_758_1083495404.1438980433169-- .