220 19759 <5e70c6b8-7faf-4b6d-a4e2-dbf502116c39@isocpp.org> article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Move destructor draft Date: Mon, 10 Aug 2015 15:17:01 -0700 (PDT) Lines: 524 Approved: news@gmane.org Message-ID: <5e70c6b8-7faf-4b6d-a4e2-dbf502116c39@isocpp.org> References: <0A99E209-333B-4140-8F65-2F022E681AC1@gmail.com> <11799558.eJTBMtnS6W@tjmaciei-mobl4> <368db355-1910-4da3-b50e-96a595ee974a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5153_517007116.1439245021585" X-Trace: ger.gmane.org 1439245027 9265 80.91.229.3 (10 Aug 2015 22:17:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 22:17:07 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBXWFUSXAKGQE2PZHDAI@isocpp.org Tue Aug 11 00:17:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOvNQ-0005fv-Gv for gclcip-std-proposals@m.gmane.org; Tue, 11 Aug 2015 00:17:04 +0200 Original-Received: by igbjg10 with SMTP id jg10sf47363601igb.0 for ; Mon, 10 Aug 2015 15:17:03 -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=mKEoZ4Kix+ijDVPDOTzIafuXJEAvHWenyGz8I41RFIo=; b=hw9tQ8NTpFNLZsRbXOW/frphnvlR8eY8Wid2KvZFvxprtv688uWsjzYs1VYiqasEx5 7ycyhQaa+tfB7Is+sPtpALq2RzYMS0E2w39cAY0TtbH8j3IgaKDdEbuxqpDp4ql1FzP7 qm1tcvF0Xsdc0KI+/EB+s2EE6miznhp1k459JuabJy86UPSBTLYst4PGD0HEpQKiPDV4 HfGriqrXoj3Bab1vj044CdB/PI2De/P6G7hkOvWSzWhe/OQJuk11/hk7M/kwElyecw1T mEO9Mz2ixWcGq8cf2KWK5iFvJLEgLthFFtNeFyv4bUy4OFn7L8pNY0KnMawBg4n4MZVp KSNQ== X-Gm-Message-State: ALoCoQlG9wIBd3ctuf63qkz/S+r0oTpRzqSsX8Xf8ieBxylP8OrrqYc/GZCY72r6wbBZN17je8+m X-Received: by 10.182.143.70 with SMTP id sc6mr22645610obb.24.1439245023370; Mon, 10 Aug 2015 15:17:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.107.246 with SMTP id h109ls3215371qgf.1.gmail; Mon, 10 Aug 2015 15:17:02 -0700 (PDT) X-Received: by 10.140.98.147 with SMTP id o19mr98945qge.37.1439245022391; Mon, 10 Aug 2015 15:17:02 -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:19759 Archived-At: ------=_Part_5153_517007116.1439245021585 Content-Type: multipart/alternative; boundary="----=_Part_5154_539478872.1439245021586" ------=_Part_5154_539478872.1439245021586 Content-Type: text/plain; charset=UTF-8 However, if there's real desire for the wrapper you show to be legal, a better way to do it would probably be to allow this: >>A(A& x) : B(std::move(x)), >>c(x.c), >>i(x.i) { a = this; } But this means we: - say goodbye to the noexcept guarantee; - define the point when ~B is called in the original location - probably when >>A returns; - introduce another type trait, is_nothrow_relocatable I would have preferred to avoid this, but - I guess, if people *really* want to merge move and copy construction into relocation... *(shudder :)* On Monday, August 10, 2015 at 3:59:07 PM UTC-6, isocp...@denisbider.com wrote: > Hmm, good points. > > There are definitely situations where you don't want to mem-initialize a > trivial member, such as in the example: > > >>A(A& x) : >>B(x), >>c(x.c), >>i(x.i) > > { a = *this*; } > > However, one might definitely argue that situations where you want to > mem-initialize a base or a member, but with a non-corresponding member, are > practically nonexistent. So, we may in fact prefer the following: > > >>A(A& x) : >>B, >>c, >>i > > { a = *this*; } > > The relocate_wrapper you suggest I think looks neat, and should be legal. > I don't see a reason why it wouldn't be legal, if the mem-initializer-list > is not implicit. > > It seems to me, intuitively, that there's no reason to make it illegal to > access any data member of the moved-from subobject until the outermost > relocator exits. > > I see no obvious reason why virtual methods shouldn't continue to work, as > well. But this is not to say, of course, that one should call them. > > In general, anything that's const ought to be safe to call. Which is an > argument in favor of making the signature >>T(T const&) - except that would > prevent zeroing out of members. > > > On Monday, August 10, 2015 at 2:20:28 PM UTC-6, Edward Catmur wrote: > >> A few queries: >> >> What exactly are the semantics of the mem-initializer-list, particularly >> with regard to omitted, duplicated or misplaced bases/members: >> >> struct A { >> std::string q, r, s; >> >>A(A& x) : >>r(x.r), >>s(x.r) { /* oops */ } >> }; >> >> Is it ever legitimate for a mem-initializer to be omitted or to take any >> form other than >>id(x.id) where the two identifiers are equivalent? If >> so, whose responsibility is it to call the destructor on the corresponding >> member of the source object? If not, would it be better to omit the >> mem-initializer-list entirely, as with destructors? >> >> Within the body of the relocator special member function, what are the >> lifetime statuses of the source and destination objects, particularly with >> regard to [class.cdtor]? Is it permissible to form lvalues to the bases and >> members of the source object, or is this undefined behavior as they are >> destructed? If the type is polymorphic, is it permissible to dynamic_cast >> or invoke virtual functions on the source? Indeed, is it permissible to >> invoke any member functions on the source? >> >> In particular, I'd like to make this utility class legal (noting that >> aligned_storage_t is a POD but my utility class is not): >> >> template >> struct relocate_wrapper { >> template relocate_wrapper(Args&&... args) { >> new (&buf) T(std::forward(args)...); >> } >> ~relocate_wrapper() { reinterpret_cast(buf).~T(); } >> >>relocate_wrapper(relocate_wrapper& rhs) { >> new (&buf) T(reinterpret_cast(rhs.buf)); >> reinterpret_cast(rhs.buf).~T(); >> } >> std::aligned_storage_t buf; >> }; >> >> Hm... it might be nice to ensure that the relocator doesn't do any >> unnecessary work copying the buffer that's just going to be placement new >> moved into. Is that an argument against an implicit mem-initializer-list? >> > -- --- 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_5154_539478872.1439245021586 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
However,=C2=A0if there's real desire for the wrap= per you show to be legal, a better way to do it would probably be to allow = this:

=C2=A0

=C2=A0 >>A(A& x) : B(std::move(x)), >>c(x.c), >>i(x.i) { a =3D this; }=

=C2=A0


But this means we:

- say goodbye to the noexcept guarantee;

- defin= e the point when=C2=A0~B is called=C2=A0in the original location - probably= =C2=A0when >>A returns;

- introduce another = type trait, is_nothrow_relocatable

I would have preferred to avoid this, but - I = guess, if people really want to merge move and copy=C2=A0construct= ion into relocation... (shudder :)


On= Monday, August 10, 2015 at 3:59:07 PM UTC-6, isocp...@denisbider.com wrote= :
Hmm, good points.=

There are definitely situations where you don'= ;t want to mem-initialize a trivial member, such as in the example:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { a =3D this; }


However, one might definitely argue that s= ituations where you want to mem-initialize a base or a member, but with a n= on-corresponding member,=C2=A0are practically nonexistent. So, we may in fa= ct=C2=A0prefer the following:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { a =3D this; }


The relocate_wrapper you suggest I think l= ooks neat, and should be legal. I don't see a reason why it wouldn'= t be legal, if the mem-initializer-list is not implicit.

It seems to me,=C2=A0intuitively,=C2=A0that there's no reason to= make it illegal to access any data member of the moved-from subobject unti= l the outermost relocator exits.

I see no obvious = reason why virtual methods shouldn't continue to work, as well. But thi= s is not to say, of course, that one should call them.

=
In general, anything that's const ought to be safe to call. Which = is an argument in favor of making the signature >>T(T const&) -= =C2=A0except that would prevent zeroing out of members.


On Monday, August 10, 2015 at 2:20:28 PM UTC-6, Edward Catmur wro= te:
A few queries:<= /div>

What exactly are the semantics of the mem-initiali= zer-list, particularly with regard to omitted, duplicated or misplaced base= s/members:

struct A {
=C2=A0 =C2=A0 std::string q, r, s;
=C2=A0 =C2=A0 >>A(A& x) : >&g= t;r(x.r), >>s(= x.r) { /* oops */ }
};
<= /div>

Is it ever legitimate for a mem-initializer to be = omitted or to take any form other than x.id) where the two identifiers are equivalen= t? If so, whose responsibility is it to call the destructor on the correspo= nding member of the source object? If not, would it be better to omit the m= em-initializer-list entirely, as with destructors?

Within the body of the relocator special member function, what are the lif= etime statuses of the source and destination objects, particularly with reg= ard to [class.cdtor]? Is it permissible to form lvalues to the bases and me= mbers of the source object, or is this undefined behavior as they are destr= ucted? If the type is polymorphic, is it permissible to dynamic_cast or inv= oke virtual functions on the source? Indeed, is it permissible to invoke an= y member functions on the source?

In particular, I= 'd like to make this utility class legal (noting that aligned_storage_t= is a POD but my utility class is not):

template<class T>
struct relocate_wrapper {
=C2=A0 tem= plate<class... Args> relocate_wrapper(Args&&a= mp;... args)= {
=C2=A0 =C2=A0 new (&buf) T(std::forward= <Argsargs)...);
=C2=A0 }
=C2=A0 ~relocat= e_wrapper() reinterpret_cast<T&>(buf).~T(); }>>relocate_wrapper(rel= ocate_wrapper& rhs) {
=C2=A0 =C2=A0 new (&buf) T(reinterpret_cast<T&&>(rhs.buf));
=C2=A0 =C2=A0 reinterp= ret_cast<T&>(rhs.buf).~T();
=C2=A0 }
=C2=A0 std::aligned_storage_t<sizeof(T), alignof(T)> buf;
= };

Hm... it might be nic= e to ensure that the relocator doesn't do any unnecessary work copying = the buffer that's just going to be placement new moved into. Is that an= argument against an implicit mem-initializer-list?

--

---
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_5154_539478872.1439245021586-- ------=_Part_5153_517007116.1439245021585-- .