220 34989 article Path: news.gmane.org!.POSTED!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Contra P0722R0 "destroying operator-delete" Date: Tue, 17 Oct 2017 13:06:54 -0700 Lines: 232 Approved: news@gmane.org Message-ID: References: <89c7d198-0eec-4099-ba31-bad92706ebae@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045c14682afdf3055bc3aaf4" X-Trace: blaine.gmane.org 1508270830 1302 195.159.176.226 (17 Oct 2017 20:07:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 20:07:10 +0000 (UTC) Cc: Richard Smith , "ISO C++ Standard - Future Proposals" To: Andrew Hunter Original-X-From: std-proposals+bncBDLZJYWNDQIN7RMZZ4CRUBAMF4FGS@isocpp.org Tue Oct 17 22:07:02 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4Y8W-0006OO-Ul for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 22:06:49 +0200 Original-Received: by mail-wr0-f199.google.com with SMTP id z96sf1310503wrb.21 for ; Tue, 17 Oct 2017 13:06:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508270816; cv=pass; d=google.com; s=arc-20160816; b=sJrL+8irLQs/g7aqGyxFTYkecFz7iGbgOwxXqn+nIyGG6gqDTksQlCc2QW1Al4Cbi+ mLO8pogpi6IsOiO98azbTWVYSc//KjGBUdhapMudgF29t/9ul4FrLbpTt65L9wddVQUc oCN9M4mRIiiwssp6VGQYtI3+ZRKzoyNOsmx5xLx8SYzPahU+t05zNBc2QVX05SGTFugu p4Ul9cZUJy8PjFj+jEV7nW+c7grC2qSPEym3/0+52wEyH4Ib5q3+CKx9StRifGNHhpFV Qk9vV112VSlWKweZ6N9uAqbl7OAjYD2TCJeP7fUlWl/lMJhAW8l90LgNIHBm2M1YHTjF IRDw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:references:in-reply-to:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=FRU7JS03MyPY+E3SmlaHgJPIAdllAef87Y7mKiKLago=; b=gzr0BXEytDnifRJI6Zg7gR8klnsYXqbT4iHdpFCkqg7voantuowVnin3jx0kGzWIph 7BkamsqZYLS4Xw/WvtdI0S30wviCs5ZsU1FLd7IRjYFY6qR4C9BqgDwRm7MiK2QyLQp3 i03IgEkj97Fl31pPhSWQzOgscrZYazH0RuyvtTYTiHmRqmh9dLXzc9D1U7tUficOfs0D ZDf2FiJ61CrRImaGjQELDi33C32M2WKpoCdCHKSS9U84HQ+wIF4ipS4wQO9pGq8oDcD6 VxbMH4U3EbD5L7gY1MnmeA4WpycAVlDiRXwtVCT5FAdS3KJJEeAo6abGiYaKdL8MztPS TXZQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PXbNkGor; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FRU7JS03MyPY+E3SmlaHgJPIAdllAef87Y7mKiKLago=; b=RfHodrWwNnAfW9yUv6PKDiKDfbnBUdEsJY5YY0AoQk5K56MatottwAMSFAto5H7h8R fU5wnsvUj3a7dmeo3phoclCwWEcY9TSuS+kCBg+QBc3ZE+Pbw1S5Q5qroOw3Zy6Rs12l ZhFCK23jGXi0skItAhSUPyj1BB1Md3neqU12n210fgzlUzr1p1km75JYbBcClLwahQ4h PXJIpcqEtHp3GB5VpDVc9JYXGnhvL2+Y/NzgQHybfiJrc0kw377005vt6+3K95xZmzow aNFElocGSnVezOvbw3W4+6AZgATAJoBDN7s3jXOPkq6nn/DpYExSo0xTDGm8uxh1UcdR uT1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FRU7JS03MyPY+E3SmlaHgJPIAdllAef87Y7mKiKLago=; b=a+nxJ4mTBMwRe54t7pJUgj574bzkXcZv19TyUscyLxeMqU+AKxS4iZpAEUmy1hWOTJ VQQuvyYYXwgISsEtA6dp20qDqF+44AHRNbn84/fCwfwBR7BROgrHq94G6MKiUGNDzoVe MQKDAn4XuI+GL7ZDCx9PyRtFv6dWtB419HoBbTqvwob9sQLFLAX8SAnRnJ2dlxhKBgB4 I2AH4wvpKDDn53xSh2MYTwQ6zBoVPF2HQIfWF5ztKbKZw7AMvhLa4JMKmJ8j/4BSkLQJ TpPgxBAgjglpfPCW2W3jkD8l5K1a9ws26YnX8fTkc2hk1q2hh9/gIorbXtlaTUDIVIPi JQfA== X-Gm-Message-State: AMCzsaWZIeJQMxfVANonL9nMoGTd3GxuyiJkj1EOo3gzDLzVO0vCPAyU 7HA9PtG9xl3TO+oBjAzzuq/tLQ== X-Google-Smtp-Source: ABhQp+S+FocmUWc4L0eswixpQiOq9CadDQwD5XVBzfacOxMuYeOR0dnC0Gb72dg7RVT4/Dre29sdEQ== X-Received: by 10.80.230.12 with SMTP id y12mr2072660edm.6.1508270816568; Tue, 17 Oct 2017 13:06:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.80.171.29 with SMTP id s29ls1081397edc.4.gmail; Tue, 17 Oct 2017 13:06:55 -0700 (PDT) X-Received: by 10.80.240.136 with SMTP id v8mr18654678edl.52.1508270815620; Tue, 17 Oct 2017 13:06:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508270815; cv=none; d=google.com; s=arc-20160816; b=pTdgNEKgVJQB7iERSjUfIGqOvvyEVDljFhWLkDlR6iX63yroQpra7OdnJh2OAityh2 Tkd54h2kKR7ahhXtpJvGZa5sOMiIF/9Eg/2+u3pAlgAjSPnwTwL2xSwWNj+sVPVxiIPa kbnaxlocAOcfifR4qcfOVkeCyOKng7hJ32knOUdFV2lXaJ8QonSlp0kQ1wlwrUVMVg+n /OeP8IQtPIaZ/y6LmNdutxpjJJAD8wnprPsU9yFRCHzQibq7l8oTq1tZiunLnjoFB817 1PPYM037LaEku7xWpv+W+OSiIlRb5GaKYEbLhq+FapXMHEcLbqTKb4XrgO5TCQypbjuQ MmXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=AJ6Qaey9hEWWZYDl1ZAd0iJfi9+LRA+MoBYSjyL8jMo=; b=BnABIH6LBgu6oIsNcmK5kz/is+K2Eb9pVWf3PE6jy3zN6A5AO+uhQqBxgKzmd9tGYg HXix57qmE2D143dRM/hmgLlT0gPT1U1YwBG/iY6mg/EcAIWyPkSoKa4uIMMbgEr+je2z 3jERt45WRMWxPFBKNwnM7GLOJ0iZydO2618UFHL5HrTedDMDE6Ecgo7lwbBD71/+oD7H e5bEypxRq9wO+dysKcez1CzSIS9+FjISOvQ5Q6obm0Rean1Qzt5INEMfY3W9Qtfe+vBK fVWtROav+5Ewl45RkbBwhNOdwX9WiUfySgqg+NRKhjnpKDRE5RaX3QBXzBUOkPJbGbef Cudw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PXbNkGor; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id s7sor4952517edi.48.2017.10.17.13.06.55 for (Google Transport Security); Tue, 17 Oct 2017 13:06:55 -0700 (PDT) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.80.137.91 with SMTP id f27mr18004284edf.18.1508270815246; Tue, 17 Oct 2017 13:06:55 -0700 (PDT) Original-Received: by 10.80.154.162 with HTTP; Tue, 17 Oct 2017 13:06:54 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PXbNkGor; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:34989 Archived-At: --f403045c14682afdf3055bc3aaf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2017 at 12:39 PM, Andrew Hunter wrote: > On Tue, Oct 17, 2017 at 11:30 AM, Arthur O'Dwyer > wrote: > > Yes, this is accurate. The programmer should never expect "delete > > expressions" to work with objects that were not created via "new > > expressions". > > Which programmer? > All of them. ;) Are you saying that > > Widget *Widget::Make(string widget_spec); > > is badly designed unless I always also specify Widget::Destroy? Yes. In fact, I would say that this function-returning-an-owning-raw-pointer is badly designed regardless of the existence of Widget::Destroy(), because the raw pointer does not say anything about its ownership and violates RAII. I would rather have Widget Widget::Make(string widget_spec); (value-semantics) or at least std::shared_ptr Widget::Make(string widget_spec); (handle-semantics, but with the appropriate "destroyer" bundled alongside the pointer). > (If so, why do we have virtual destructors at all?) Classical polymorphism. You could actually make the virtual destructor Do The Right Thing in this case, but that would require that your object instance know its own dynamic type. This type-safety is the cornerstone of classical OOP. In C++ we would write something like this : class fixed_string { public: static fixed_string *Make(const std::string &data) { assert(data.size() < 256); return make_impl(std::make_index_sequence<256>{}, data); } template static fixed_string *make_impl(std::index_sequence, const std::string &data); virtual ~fixed_string() =3D default; protected: size_t size_; }; template class inlined_fixed_string : public fixed_string { char data_[N ? N : 1]; public: inlined_fixed_string(const char *s) { size_ =3D N; memcpy(data_, s, N); } }; template fixed_string *fixed_string::make_impl(std::index_sequence, const std::string &data) { using FP =3D fixed_string* (*)(const char *); FP arr[] =3D { +[](const char *s) -> fixed_string* { return new inlined_fixed_string(s); } ... }; return arr[data.size()](data.data()); } Now we have a base class with a virtual destructor, and a family of derived classes all of which override that virtual destructor to do the correct cleanup for each respective derived class. We cannot create new derived classes at runtime =E2=80=94 we must specify at compile-time the complete s= et of derived classes that we care about =E2=80=94 but this is just the usual cos= t of type-safety. It's the same reason there's no std::visit(std::any). Again, I would probably argue that returning raw owning pointers in the classical-OOP fashion is a bad idea, and I'd encourage wrapping things up in value-semantic wrappers and not using inheritance at all (at least not in a way that's visible to the user-programmer). But if you must use classical-OOP and raw owning pointers, then classical-OOP does provide some tools for each derived instance to know how to destroy itself. =E2=80=93Arthur --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CADvuK0%2B5pBV7ee1OfT8c3DtP8XS6_7Dm1YnPH0G1TAE%2= BqEDcTw%40mail.gmail.com. --f403045c14682afdf3055bc3aaf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 17, 2017 at 12:39 PM, Andrew Hunter <ahh@google= ..com> wrote:
On Tue, Oct 17, 2017 at 11= :30 AM, Arthur O'Dwyer
<arthur.j.odwyer@gmail.com<= /a>> wrote:
> Yes, this is accurate. The programmer should never expect "delete=
> expressions" to work with objects that were not created via "= ;new
> expressions".

Which programmer?



Are you=C2=A0saying t= hat

=C2=A0 =C2=A0 Widget *Widget::Make(string widget_spec);

is badly designed unless I always also specify Widget::Destroy?

Yes. In fact, I would say that this function-returning= -an-owning-raw-pointer is badly designed regardless of the existence of Wid= get::Destroy(), because the raw pointer does not say anything about its own= ership and violates RAII. I would rather have

=C2= =A0 =C2=A0 Widget Widget::Make(string widget_spec);

(value-semantics) or at least


<= /div>
(handle-semantics, but with the appropriate "destroyer"= bundled alongside the pointer).
=C2=A0
(If= =C2=A0so, why do we have virtual destructors at all?)

=

=
class fixed_string {
<= div>public:
=C2=A0 =C2=A0 static fixed_string *Ma= ke(const std::string &data) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert(data.size() < 256);
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 return make_impl(std::make_index_sequence<256>{}, data);
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
<= div>=C2=A0 =C2=A0 template<size_t...= Is>
=C2=A0 =C2=A0 = static fixed_string *make_impl(std::index_sequence<Is...>, const std:= :string &data);
= =C2=A0 =C2=A0=C2=A0
= =C2=A0 =C2=A0 virtual ~fixed_string() =3D default;
protected:
=C2=A0 =C2=A0 size_t size_;
};

template&l= t;size_t N>
class i= nlined_fixed_string : public fixed_string {
=C2=A0 =C2=A0 char data_[N ? N : 1];
public:
=C2=A0 =C2=A0 inlined_fixed_string(const char *s) {<= /font>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 size_ =3D N;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 memcpy(data_, s, N);
=C2=A0 =C2=A0 }
};
template<siz= e_t... Is>
fixed_st= ring *fixed_string::make_impl(std::index_sequence<Is...>, const std::= string &data) {
= =C2=A0 =C2=A0 using FP =3D fixed_string* (*)(const char *);
=C2=A0 =C2=A0 FP arr[] =3D {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +[= ](const char *s) -> fixed_string* { return new inlined_fixed_string<I= s>(s); } ...
=C2=A0= =C2=A0 };
=C2=A0 =C2= =A0 return arr[data.size()](data.data());
}

Now we have a b= ase class with a virtual destructor, and a family of derived classes all of= which override that virtual destructor to do the correct cleanup for each = respective derived class. We cannot create new derived classes at runtime = =E2=80=94 we must specify at compile-time the complete set of derived class= es that we care about =E2=80=94 but this is just the usual cost of type-saf= ety. It's the same reason there's no std::visit(std::any).

Again, I would probably argue that returning raw owning po= inters in the classical-OOP fashion is a bad idea, and I'd encourage wr= apping things up in value-semantic wrappers and not using inheritance at al= l (at least not in a way that's visible to the user-programmer). But if= you must use classical-OOP and raw owning pointers, then classical-OOP doe= s provide some tools for each derived instance to know how to destroy itsel= f.

=E2=80=93Arthur

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B5pB= V7ee1OfT8c3DtP8XS6_7Dm1YnPH0G1TAE%2BqEDcTw%40mail.gmail.com.
--f403045c14682afdf3055bc3aaf4-- .