220 19758 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 14:59:07 -0700 (PDT) Lines: 440 Approved: news@gmane.org Message-ID: 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_866_2035194516.1439243947633" X-Trace: ger.gmane.org 1439243956 25229 80.91.229.3 (10 Aug 2015 21:59:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 21:59:16 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBLN5USXAKGQEUI2KNQQ@isocpp.org Mon Aug 10 23:59:12 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZOv67-0008DH-9l for gclcip-std-proposals@m.gmane.org; Mon, 10 Aug 2015 23:59:11 +0200 Original-Received: by pdrn6 with SMTP id n6sf43719050pdr.1 for ; Mon, 10 Aug 2015 14:59:10 -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=1qcGumcoFI/QC2AYXNVYCT9yomLlOLeeM7SKDk8xM6M=; b=XbynfNv9ltd83mK0WnlNSAEsxNOA+Ty/f4sFWygvKb3wvsPaguss/mC5BWzNoqNBLo OxZ3/hLYMZyIplEEjuyyQFTYzdHP3blVoGdYi3gcrY/Q3jg5xtQiZ7sv8R3mjTDtjYsZ vEba1DupyVh4i23yOWDQ94ph0RIXzpZ0dsLPsXcn/0DndY1T/jgSFQbJAB7nn333TFKf OmJBsDonGtb0MHtE5x1kv6j90uZIPVhUETHHI7H/jkESkOBIef9taDhIVQFHP+zBu1CW vcG+orJ0Qj9IRsNO82MTL4hGpc60DySQ8JWPpo6lfpBlpJjc9L/lEXKajWHCbfRQXaHM 0BOA== X-Gm-Message-State: ALoCoQluscn7nnu/TuD8VcmUl6+s3d3A2Y/UcSy4C0LF6fh00KSfZgyOD5skwdAu309qqxb3Nowp X-Received: by 10.66.185.195 with SMTP id fe3mr20996325pac.13.1439243950233; Mon, 10 Aug 2015 14:59:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.81.115 with SMTP id e106ls3322839qgd.4.gmail; Mon, 10 Aug 2015 14:59:08 -0700 (PDT) X-Received: by 10.140.93.38 with SMTP id c35mr218341qge.38.1439243948803; Mon, 10 Aug 2015 14:59:08 -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:19758 Archived-At: ------=_Part_866_2035194516.1439243947633 Content-Type: multipart/alternative; boundary="----=_Part_867_988721069.1439243947634" ------=_Part_867_988721069.1439243947634 Content-Type: text/plain; charset=UTF-8 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_867_988721069.1439243947634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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) : >>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) : >>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:

st= ruct A {
= =C2=A0 =C2=A0 std::<= span style=3D"color: rgb(0, 0, 136);">string q, r, s;=
=C2=A0 =C2=A0 >><= /span>A(A& x) : >>= r(x.r), >>s(xr) <= span style=3D"color: rgb(102, 102, 0);">{ /* oops */<= span style=3D"color: rgb(0, 0, 0);"> }
};

Is it ever legitimate = for a mem-initializer to be omitted or to take any form other than >>id(x.id) where the t= wo identifiers are equivalent? If so, whose responsibility is it to call th= e destructor on the corresponding member of the source object? If not, woul= d it be better to omit the mem-initializer-list entirely, as with destructo= rs?

Within the body of the relocator special membe= r function, what are the lifetime statuses of the source and destination ob= jects, particularly with regard to [class.cdtor]? Is it permissible to form= lvalues to the bases and members of the source object, or is this undefine= d behavior as they are destructed? If the type is polymorphic, is it permis= sible 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 (n= oting that aligned_storage_t is a POD but my utility class is not):

template<class T>
struct relocate_wrapper {
= =C2=A0 template<class... Args> relocate_wrapper(Arg= s&&... args) {=
=C2=A0 =C2=A0 new<= span style=3D"color: rgb(0, 0, 0);"> (&buf) T(stdforward<Args>(args)...);
=C2=A0= }
=C2=A0 ~relocate_wrapper() { r= einterpret_cast<<= span style=3D"color: rgb(0, 0, 0);">T&>(buf<= span style=3D"color: rgb(102, 102, 0);">).~T(); }
=C2=A0 = >>relocate_wrapper(relocate_wrapper& rhs) {
=C2=A0 =C2= =A0 new (&am= p;buf) T(reinterpret_cast<T&&>(rhs.buf));
=C2=A0 =C2=A0= reinterpret_cast<T&>(= rhs.buf).~T();
=C2=A0 }
=C2=A0 std= ::aligned_storage_t<sizeof(T), alignof(T)> buf;=
};
<= /div>

Hm... it might be nice to ensure that the re= locator doesn't do any unnecessary work copying the buffer that's j= ust going to be placement new moved into. Is that an argument against an im= plicit 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_867_988721069.1439243947634-- ------=_Part_866_2035194516.1439243947633-- .