220 34985 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 11:30:09 -0700 Lines: 271 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="94eb2c19516c30efc0055bc25084" X-Trace: blaine.gmane.org 1508265017 24039 195.159.176.226 (17 Oct 2017 18:30:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 18:30:17 +0000 (UTC) Cc: "ISO C++ Standard - Future Proposals" , Andrew Hunter To: Richard Smith Original-X-From: std-proposals+bncBDLZJYWNDQILHGEZZ4CRUBGYCDV6S@isocpp.org Tue Oct 17 20:30:11 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4Wcu-0004hW-VP for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 20:30:05 +0200 Original-Received: by mail-wm0-f72.google.com with SMTP id r202sf1214463wmd.17 for ; Tue, 17 Oct 2017 11:30:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508265012; cv=pass; d=google.com; s=arc-20160816; b=pfvEez8f+yIWiox18GN9fyWPPGVQ6Aj+gmRUw25C5uByz3z2T3hYCyAiKZyAJrVIL2 +hf7WwZrfxLsWzWyl20NEop4G/cT56PiRaTEv9Np8XpSV5fHXHF5CXmQpZcUy1YxNZ4R glVTgIlzkk5f7VDKd7cMhGqYuVshg74g7gPEkbM8fpKZfG688gxygA/79yTqh1FdN+rM 2BHacSawHrPL9aGLyZMdUfgpu4xESti1402ho00Q83DeILO3v6LquQetQWuF0v29bDGJ JnSqPv/b7H3m9H2GW0WSWkAttfOLaBLWSYOigCwBj6F8s2wcE9einAH/ibVRz4uFWvHd LhXA== 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=VwChKBz9+CvtPmR2T0Vsit31zmXUf5XszsZBUbooEYw=; b=iIYLt+zvKbigTfbZUDlE1f0lbbaBX7QMALagbkITudNfdQ8GKhN1smPiYJml6r6dHj sipyVJgsIdrnaSOKKJDh47huShZbFcyBAWHnxj++hdO+UeVM8r18ESRxD2vjB1rj6Snv Sc/icyzodoopLa7hBblL+avvIVREr9Tx0PDo+N5Se90+rhlCtw1AjBgCfloPkM5p7kvN R6lA0qEHEgBccTWccENgkV94ZElEOfCF2xB0csu7PQJQ/IzqJtKstjIPncjacltJDHFe jwsDZl+NYiUNTcfKN4c9KRPXf0MIUQXDGCaKGRFJNn7KNiY2qn2JQS9YIVHsz8wMZkZ/ LWSQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DMog8yJ7; 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=VwChKBz9+CvtPmR2T0Vsit31zmXUf5XszsZBUbooEYw=; b=SZKZVMc/rlPkKBgQd55SyvbaV42FdpshiqzExvcsIftVAZKRNX8tub2qBbllTrL86l nqjrZn0WohRKV/ShJqnxgLmvtuRuJ5kakPlBUUaRaUd2epH41cljZKKUMgiGbaH4ymac 2xZVR9+KoLCK3ySI0PjxSR1jbZFFEwOcuARTw+5Q88V5ubBdORBr/0D9ZI1ZelaeP2tu Lgrb59xRrJ/Xo36h/ZITvkhHQNyRmwj0p0diXeQ0YZ6n9PDSMzsA7QljnXdCU9MFM3Ru 9pEetHwKMw4zo+Ouv9pKK/H4V5UcuRc1Z/NndLdg4V2HMrzEHYFZnQTr7DEIIIjFRTCK 1zJQ== 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=VwChKBz9+CvtPmR2T0Vsit31zmXUf5XszsZBUbooEYw=; b=T3ifck9uv0urzOoxrpFoNdPw46vfvxeTAcg6DZJo9NHm2TGMmo/IJOPLFw0aG/2d0t lTmQpTt+zWKzL+oFOwWwMPxyWTnMTuWkXo6lcyHga51VhmaO2CyTyzNCgAgbwmqMzpZY sFUE8L72+ORvKxyZJ5ezXoMXQr6IF0SuHauqsW4Yf/+X8rFVqAQdJI6LdpGIUCLd2bPL HO6KwmQZRib+NNCogsJH5QIm1blf6tD5/b/gqjrzL1+YI/SHr9SyVhsbwDFf++I6Fc1L qDFTPHEIryQaR4XeBxSf/JEWZ8kn7og/oNj4C5U4LoeZfbvkwGx+WUikNI15Ho8Aw94i n1Ig== X-Gm-Message-State: AMCzsaW7qAPKd08RHd+cr/BmZjBDQ2sRu3ZpkF7se5ENf0V+wpwqRzA9 i3BvDbCt0xkwEre8E7Xf4XkEJA== X-Google-Smtp-Source: AOwi7QAZzzJUhDdagf2huNTLkW5CP/FrvBoYB39xIBNF1XmRbbJ3SdWxugMIhTaR9s2PYAv5lPIMGg== X-Received: by 10.80.139.209 with SMTP id n17mr3548857edn.10.1508265012561; Tue, 17 Oct 2017 11:30:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.80.167.100 with SMTP id h91ls1002876edc.8.gmail; Tue, 17 Oct 2017 11:30:11 -0700 (PDT) X-Received: by 10.80.180.187 with SMTP id w56mr18170746edd.15.1508265011080; Tue, 17 Oct 2017 11:30:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508265011; cv=none; d=google.com; s=arc-20160816; b=bUUR09KsV5xS4WNxhxIBO6YbW5gswENLKQJTa8ueRA1xITDJ14wGUQsjmE0LSQGE+d 9lJL/VF6G7wb3TNAPqDZglHsBuSjaWZwJ9KyLOGX3S1NhFq2Y7g9P+fxF5ubbRAT3tQI zcMtjMqO8erkD8fJIbCKiyp2yrEepoSC90pmGwEB4E2pfM0X2S79SU4t0tC4HnAxVW2O Wd0ZH11h9lWzLSNNk1YZgCWk8lsTXxZWsfPnrpZaHOxx80cFWLHYrcTbXkBe4mnyLKhm RQHqS5ZIFFzX3Q4P9pv5Vr+LHHfT7rz6f5KBEsEk5d2Bg23aNmKDlkVAYTGj5YjTGFU0 NqZA== 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=eWeiFuXeI3J4Q4//F/uQhNlX3xrlblO5OuqJj15TicQ=; b=yPrwGlGwyGak62FPx+FbXuDoeb6JBOcV40BG4Qk5K3QKTV4MAjX5gKdQsEMPv14KX8 LIJ5mbr3SNcCgeMffo8Rv1IcCZs5GtH0/p4mS2Elr7Nbm81+soPQdZo/pt4AEXREN0G4 CBFLsEGw5qTrfhesTwiuDUQF6wDCFiaQWcMiz/Rll384sjaqaCuraK7HYuijPj67AERY 9dnzODXXb+79tTga541cb/vUrP7bracOr8Eo/7wi6BfIJZOd8DyGzD+NzViH0c51l54a qI1Z0H8y574ZW0OKKKCBsFBijuz2BLEAOlI8oXgTU3zoZ+2qKN81GbWLBtpK+XFRLEje ueqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DMog8yJ7; 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 p7sor4936264edj.40.2017.10.17.11.30.11 for (Google Transport Security); Tue, 17 Oct 2017 11:30:11 -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.143.98 with SMTP id 89mr18144293edy.273.1508265010718; Tue, 17 Oct 2017 11:30:10 -0700 (PDT) Original-Received: by 10.80.154.162 with HTTP; Tue, 17 Oct 2017 11:30:09 -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=DMog8yJ7; 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:34985 Archived-At: --94eb2c19516c30efc0055bc25084 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2017 at 10:02 AM, Richard Smith wrote: > On Tue, 17 Oct 2017, 09:39 Arthur O'Dwyer, > wrote: > >> This defines what is (effectively) a variable-sized object, using that t= o >> implement an array of size determined at runtime while saving a pointer >> indirection. (Note: this pattern is simpler (and generally written) with >> flexible array members, despite their being nonstandard.) >> >> However, what happens when we delete such a string s in the presence of >> sized-delete? >> >> >> Well, you get misbehavior, of course. Syntactically, C++ allows you to >> use "delete" on any pointer; but semantically, you should use "delete" o= nly >> on pointers that were originally obtained from "new". And in your case, = you >> didn't obtain the pointer from "new"; you obtained it from the public >> factory function "Make". >> This code is broken because it has a public "Make" factory and private >> constructor, but it is missing a public "Destroy" factory and private >> destructor. If you rewrite it to use that idiom, then the problem goes a= way. >> > > Please read to the end of the paper; that alternative is discussed and we > explain why it is not entirely satisfactory. > I saw the end of the paper, but I interpreted it as just a continuation of the mistaken idea that it's okay to "delete" an object that was not created with "new". P0722R0 ends like this: The obvious and natural alternative to this proposal is to destroy and dele= te objects with custom deletion semantics by using special-case logic, instead of using 'operator delete'. This has a number of disadvantages: * It violates the principle that user-defined types are used like built-in types: as soon as you use more advanced allocation techniques, you don't get to use delete expressions any more. Yes, this is accurate. The programmer should never expect "delete expressions" to work with objects that were not created via "new expressions". The programmer should always expect that if a pointer is gotten from a "factory", then it should be returned to the corresponding "glue factory" when the programmer is done with it. You can use RAII to ensure that this happens. One built-in RAII approach is to use std::shared_ptr as in my corrected example . Another approach is to have the "factory" return a value-semantic wrapper around the polymorphic object, in which case you have exactly type-erasure =C3=A1 l=C3=A0 std::fun= ction. *Sometimes* the appropriate "glue factory" is "delete p", but it should be unsurprising that sometimes the appropriate "glue factory" is *not* "delete p". As soon as your "allocation technique" becomes more advanced than "p = =3D new T(...)", you should expect that your "deallocation technique" will have to be more advanced than "delete p". * Existing class hierarchies with virtual destructors cannot be transparen= tly extended with derived classes that allocate dynamic leading or trailing storage. Mmmm, I'd say yes they can (although it's not a good idea). If the existing class hierarchy provides a "factory" function for creating objects of the polymorphic type, then it would make sense for the derived class to try to "override" that factory function, and to override the corresponding "glue factory" function for destruction-and-deallocation. If the class author intended for the "glue factory" function to be overridden, they'll have made it a virtual method: virtual void Destroy() { inlined_fixed_string *p =3D this; size_t full_size =3D sizeof(*p) + p->size(); p->~inlined_fixed_string(); ::operator delete(p, full_size); } However, this is fundamentally different from a destructor alone. A derived class's destructor implicitly calls its base's destructor (there's no way around that in C++ today); but a derived class's Destroy() *must not* call its base's Destroy(). This suggests that the derived class must *itself* know everything about how to clean up its base; which means that this is *probably* not a good fit with classical OOP. Can you imagine a derived class extending inlined_fixed_string? How would it look and act? Especially, how would I construct and destroy instances of the derived class? * The local choice of deallocation strategy leaks out to clients of the co= de. For example, a custom deleter must be specified when using unique_ptr= , and make_unique and make_shared can't be used any more. Note that the standard requires specializations of default_delete to hav= e the same effect as calling "delete p;", so specializing default_delete is n= ot a correct alternative in C++17. We could lift that restriction, but that wo= uld not help for other (perhaps user-defined) resource management types that us= e new and delete to manage objects. The last bullet and its subsequent paragraph seem to hold two competing views of how-and-whether to extend C++. The bullet says, "We want to use 'delete' on factory-made pointers and have it Just Work. We must change the language to make that syntax work!" But the paragraph says, "You want to use 'default_delete' on factory-made pointers and have it Just Work? No, that would just complicate the language." Whereas my attitude is "You want to use *anything other than the corresponding factory method* to deallocate factory-made pointers and expect it to work? Just say no." =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/CADvuK0JauVfSmsCMLgvdhwZmGkpYrx%2BnYh4rQc64%2Bx9= YaG5u1g%40mail.gmail.com. --94eb2c19516c30efc0055bc25084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 17, 2017 at 10:02 AM, Richard Smith <r= ichardsmith@google.com> wrote:
=
On Tue, 17= Oct 2017, 09:39 Arthur O'Dwyer, <arthur.j.odwyer@gmail.com> wrote:
= 
This=
 defines what is (effectively) a variable-sized object, using that to
implement an array of size determined at runtime while saving a pointer
indirection. (Note: this pattern is simpler (and generally written) with
flexible array members, despite their being nonstandard.)

However, what happens when we delete such a string s in the presence of
sized-delete?

Well, you get misbehavior, of course. Syntactically,= C++ allows you to use "delete" on any pointer; but semantically,= you should use "delete" only on pointers that were originally ob= tained from "new". And in your case, you didn't obtain the po= inter from "new"; you obtained it from the public factory functio= n "Make".
This code is broken because it has a public &= quot;Make" factory and private constructor, but it is missing a public= "Destroy" factory and private destructor. If you rewrite it to u= se that idiom, then the problem goes away.

Please read t= o the end of the paper; that alternative is discussed and we explain why it= is not entirely satisfactory.

= I saw the end of the paper, but I interpreted it as just a continuation of = the mistaken idea that it's okay to "delete" an object that w= as not created with "new". P0722R0 ends like this:

= 
The obvious and natural alternat=
ive to this proposal is to destroy and delete
objects with custom deletion semantics by using special-case logic, instead
of using 'operator delete'. This has a number of disadvantages:

 * It violates the principle that user-defined types are used like built-in
   types: as soon as you use more advanced allocation techniques, you don&#=
39;t
   get to use delete expressions any more.
Yes, this is accurate. The programmer should never expect "d= elete expressions" to work with objects that were not created via &quo= t;new expressions".=C2=A0 The programmer should always expect that if = a pointer is gotten from a "factory", then it should be returned = to the corresponding "glue factory" when the programmer is done w= ith it. You can use RAII to ensure that this happens. One built-in RAII app= roach is to use std::shared_ptr as in my corrected example.=C2=A0 Another approach is to= have the "factory" return a value-semantic wrapper around the po= lymorphic object, in which case you have exactly type-erasure =C3=A1 l=C3= =A0 std::function.
Sometimes the appropriate "glue fa= ctory" is "delete p", but it should be unsurprising that som= etimes the appropriate "glue factory" is not "delete = p". As soon as your "allocation technique" becomes more adva= nced than "p =3D new T(...)", you should expect that your "d= eallocation technique" will have to be more advanced than "delete= p".


 * Exis=
ting class hierarchies with virtual destructors cannot be transparently
   extended with derived classes that allocate dynamic leading or trailing
   storage.

Mmmm, I'd say yes they can (although it= 's not a good idea). If the existing class hierarchy provides a "f= actory" function for creating objects of the polymorphic type, then it= would make sense for the derived class to try to "override" that= factory function, and to override the corresponding "glue factory&quo= t; function for destruction-and-deallocation. If the class author intended = for the "glue factory" function to be overridden, they'll hav= e made it a virtual method:

=C2=A0 =C2=A0virtual void Destroy() {
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0inlined_fixed_string= *p =3D this;
=C2=A0 = =C2=A0 =C2=A0size_t full_size =3D sizeof(*p) + p->size();
=C2=A0 =C2=A0 =C2=A0p->~inlined_f= ixed_string();
=C2=A0 = =C2=A0 =C2=A0::operator delete(p, full_size);
=C2=A0 =C2=A0}

<= div>However, this is fundamentally different from a destructor alone. A der= ived class's destructor implicitly calls its base's destructor (the= re's no way around that in C++ today); but a derived class's Destro= y()=C2=A0must not call its base's Destroy(). This suggest= s that the derived class must itself know everything about how to cl= ean up its base; which means that this is probably not a good fit wi= th classical OOP.
Can you imagine a derived class extending inlin= ed_fixed_string?=C2=A0 How would it look and act?=C2=A0 Especially, how wou= ld I construct and destroy instances of the derived class?

* The local choice of deallocation strategy = leaks out to clients of the code. For example, a custom deleter must be specified when using unique_ptr<= ;T>, and make_unique and make_shared can't be used any more. Note that the standard requires specializations of default_delete<T> = to have the same effect as calling "delete p;", so specializing default_d= elete is not a correct alternative in C++17. We could lift that restriction, but that wo= uld not help for other (perhaps user-defined) resource management types that us= e new and delete to manage objects.
The last bullet and its s= ubsequent paragraph seem to hold two competing views of how-and-whether to = extend C++. The bullet says, "We want to use 'delete' on facto= ry-made pointers and have it Just Work. We must change the language to make= that syntax work!" =C2=A0But the paragraph says, "You want to us= e 'default_delete' on factory-made pointers and have it Just Work? = No, that would just complicate the language."
Whereas my att= itude is "You want to use anything other than the corresponding fac= tory method to deallocate factory-made pointers and expect it to work? = Just say no."

=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/CADvuK0JauVfS= msCMLgvdhwZmGkpYrx%2BnYh4rQc64%2Bx9YaG5u1g%40mail.gmail.com.
--94eb2c19516c30efc0055bc25084-- .