220 19770 <27908c41-e089-41b2-af9c-dee052e890d5@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: Tue, 11 Aug 2015 04:05:56 -0700 (PDT) Lines: 135 Approved: news@gmane.org Message-ID: <27908c41-e089-41b2-af9c-dee052e890d5@isocpp.org> References: <0A99E209-333B-4140-8F65-2F022E681AC1@gmail.com> <1528887.sKF5tWFGbJ@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_242_928082258.1439291156908" X-Trace: ger.gmane.org 1439291165 32729 80.91.229.3 (11 Aug 2015 11:06:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2015 11:06:05 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBFVOU6XAKGQECQAHVJA@isocpp.org Tue Aug 11 13:06:00 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZP7NY-0005dX-7T for gclcip-std-proposals@m.gmane.org; Tue, 11 Aug 2015 13:06:00 +0200 Original-Received: by iojj196 with SMTP id j196sf332150744ioj.2 for ; Tue, 11 Aug 2015 04:05:59 -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: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=0aeBwYtj0vs4yzv9XTcvN3ugexVUSKk7YHwVuLhJ2is=; b=j1O8OE7ltIwanQDfk5CS5YKvelRRtlahaD5r8qY9fCgLF7tg9M+tSbTqykbBVT1wde QGteNMvUeywzAcZ52XrY5JERkQydDxlTULtWY1KREIFgMYWrE2MGonTYwGI7m9tl3yhM uhUIQXW2g2bdSxZ+C7mser0zCzQrO2EUPiDO1WKMIRY4xK1bFv4rXAGo9WipyPSpBxni uFF8c8PkAJ5R/Gbyd/CXA5ZXIWI/50QxlRo5FL0Tk/Va0jY7BECJ4uLtgUZ2ChBhEdAz LNPz/1lC1m/SYx1IIhNekJnvPinwsBZ4Xx6tfESnZFxHkJl6w1NfRiMnJ1mRJ86dsY0n Bmlg== X-Gm-Message-State: ALoCoQkxPxTL3AuY+SaJw3H+chqawUsB+pjs27tUPBUuo2If+M5n67uLeuAUaZNTeGfoHG1L4lhh X-Received: by 10.107.10.160 with SMTP id 32mr24198832iok.25.1439291158959; Tue, 11 Aug 2015 04:05:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.205 with SMTP id b71ls1830152qge.83.gmail; Tue, 11 Aug 2015 04:05:57 -0700 (PDT) X-Received: by 10.140.95.79 with SMTP id h73mr263056qge.30.1439291157681; Tue, 11 Aug 2015 04:05:57 -0700 (PDT) In-Reply-To: <1528887.sKF5tWFGbJ@tjmaciei-mobl4> 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:19770 Archived-At: ------=_Part_242_928082258.1439291156908 Content-Type: multipart/alternative; boundary="----=_Part_243_344741560.1439291156908" ------=_Part_243_344741560.1439291156908 Content-Type: text/plain; charset=UTF-8 You're probably right. I was thinking a static T::>>T could be an anchor for static analysis tools; but I see no reason an std::relocate cannot also serve this purpose. I have modified the proposal to make the wrapper a library function. I still believe each facility should do one thing, so I do not propose bundling of copy/move construction into std::relocate. I propose that this be implemented by expanding std::move_if_noexcept, or an alternative such method. On Monday, August 10, 2015 at 5:17:46 PM UTC-6, Thiago Macieira wrote: > On Monday 10 August 2015 09:00:02 isocp...@denisbider.com > wrote: > > T* newArray = T::>>T(newStorage, oldArray, n); > > I don't think this should be a built-in function. Instead, the array move > should be an external, template function in the std namespace. > > T *newArray = std::relocate(newStorage, oldArray, n); > > Internally, it should just DTRT and either: > 1) memcpy / memmove if T is trivially movable and trivially destructible > 2) memcpy / memmove OR call the relocating constructor for the array > [The effect should be the same, so it's a QoI detail how it's > implemented] > 3) call the move constructor + destructor > > I'd also be ok if #3 weren't implemented and caused a compilation error. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- --- 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_243_344741560.1439291156908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're probably right. I was thinking=C2=A0a=C2= =A0static T::>>T could be an=C2=A0anchor for static analysis tools; b= ut=C2=A0I see=C2=A0no reason an=C2=A0s= td::relocate cannot also serve this purpose.

I have modified the proposal to make the wrapper a library function.

I still believe each facility should do one thing, so = I do not propose bundling of copy/move construction=C2=A0into std::relocate. I propose that this be implem= ented by expanding std::move_if_noexce= pt, or an alternative such method.


On Monday, Augu= st 10, 2015 at 5:17:46 PM UTC-6, Thiago Macieira wrote:
On Monday 10 August 2015 09:00:02 isocp...@denisbider.com wro= te:
> T* newArray =3D T::>>T(newStorage, oldArray, n);

I don't think this should be a built-in function. Instead, the arra= y move=20
should be an external, template function in the std namespace.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0T *newArray =3D std::re= locate(newStorage, oldArray, n);

Internally, it should just DTRT and either:
=C2=A01) memcpy / memmove if T is trivially movable and trivially destr= uctible
=C2=A02) memcpy / memmove OR call the relocating constructor for the ar= ray
=C2=A0 =C2=A0 [The effect should be the same, so it's a QoI detail = how it's implemented]
=C2=A03) call the move constructor + destructor

I'd also be ok if #3 weren't implemented and caused a compilati= on error.
--=20
Thiago Macieira - thiago (AT) macieira= ..info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4= 5358

--

---
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_243_344741560.1439291156908-- ------=_Part_242_928082258.1439291156908-- .