220 34983 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Richard Smith' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Contra P0722R0 "destroying operator-delete" Date: Tue, 17 Oct 2017 17:02:11 +0000 Lines: 272 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="001a11476de036456d055bc116e1" X-Trace: blaine.gmane.org 1508259750 30150 195.159.176.226 (17 Oct 2017 17:02:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 17:02:30 +0000 (UTC) Cc: std-proposals@isocpp.org, Andrew Hunter To: "Arthur O'Dwyer" Original-X-From: std-proposals+bncBDEYNNMOWAFBBH7PTDHQKGQEKULC2FQ@isocpp.org Tue Oct 17 19:02:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4VFz-0006QQ-F5 for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 19:02:19 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id 97sf2294524iok.19 for ; Tue, 17 Oct 2017 10:02:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508259746; cv=pass; d=google.com; s=arc-20160816; b=l6ShKBUfOgTPdNH3jAmyGLwWVJTG3UIl1M/LgjSMRCYI2xzClavOYTrUTz5sxLSxuG cnb1Woz3udph3AyRFGhl5xxMQXkMkibcS9IC4kBBmHJCybv9RR4SqrjiD3TL5NzjtagB 0RhaVjSzJuCd/3MJP1boC9Okp0u/p4Pxe/2vpJ6h5avhecFrzdEJeIzJjZfNtacrH9Xy ol4MLjDtg8J8Pz/LOGUzEGZKMRgNeQyTgwlMohg7sCZRf0OTABTL07kl6/Uz273v7klV YQtCifR+n+kSAmDSdW+u4knErRXdS1ZoAFuVJB5wgVpF7iXy2PgRwyi4Rz4z8BeAAFyb HnSg== 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:in-reply-to:references:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=cr+boYMaKeKkckHdXq6wHK9jtDmWKgNDPJhvonbEeQg=; b=yjit8Av+E3DbXpOagXkeMz1BtWtHkwFl7nV2K+wO/plVOm6EeFUrD+KcQtu9HvhGYs snbp3o+E+bNr4c2qFxTdF0qhlvRhDjKx/YDbuQ0EQBDICovzVnTmlnq7Q4HUkFhGZ5rG bihUQ3NRdIjeQKIsZPi+ZcGscTVDjL3bvrKIksJvgpoPsHexVYwiKy+usnx4HRQkQUn8 twaWa35f/fxRIX7RbdpgTtwgyg2VYAyLR8j7rHFFukRSROWE6rOGykCUMp5qRU7GKjFZ v+B8VINPrA6wfioXEV24cCQJ3TuwKh4SE9DxMYIrhtOFgBpWkbfyNu19Fk4xzgaPYZEn Ofjw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=m9XS85Px; spf=pass (google.com: domain of richardsmith@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=richardsmith@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to: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=cr+boYMaKeKkckHdXq6wHK9jtDmWKgNDPJhvonbEeQg=; b=esBsFVevwxg9YLKpaSh9cxZ3ztxHmHfgJk+1W5L9KGc92/zxoWLt5nMWXxDMY/+Vbk Ibu4+CzOv9oOzxw0hdldVLzisT3L4G5KxgXTV3oL970gdXcY5ZHn0E6ixg2xakXLOJ1L WNHnvEQzH9sceOi9smQE31c2TRx/jQPTDrTubYrRNbsmHuwKByk2ysES+iK7YJn9dGbt P4n9EwpmrFoqKTZVL7wtjqc7hoHNLk49VAFxtTalF7cQz2oVv9f38GKewzasMUKFqmpx uvF8cm1dtaXlDBHfppWZfCb8VkuLxq4YK9psI142jZqqHZ2s9SLlHxmSf2eVdaqXq2a0 FjUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=cr+boYMaKeKkckHdXq6wHK9jtDmWKgNDPJhvonbEeQg=; b=e7i/adRa2FuCXLMwaAiAw3Qv4XzBM5e08xYh/f5k5zjUr/FA58ENnk7EVTXnjNMeGW Dap7kVeTZARGvionfFkXpouRBXChRG5fdpB8ZZHR/zXj6h9PXibkBtSm8NwoI9xhhouS N7YN0gf0Ir3+KDKV4VbNOGQzvmMsVdnTiL7Ec0mq5sGBuxARCJyeKyFdRjmItHT5d3BI /0q5IEAnobMgkFt4l4awDxPQ7++sjKDLYojB1xaCm8eW4kJqfPtj6rbTUyzeV5Cbq0tk Y9DaVrvB2C+wiN4maMBkF89uZB4ve1+TexNoi8gqyEzVWEwpF3vi/Q+3f94lkMHA6Gox A5dg== X-Gm-Message-State: AMCzsaVreuZ3E0Fc5Q1dJeOfXCKzTIn4vz5lwKGcJJR6OBSux1q2eRCM wvXC+hk3UlVtGDBF0q9VX2o= X-Google-Smtp-Source: ABhQp+R87CGc0haxmp8J7n/uIu027F3CRQobKSGO1rhYhz01UKV3V4lyX1RBgNTAMDpTPQjEWjZVOA== X-Received: by 10.107.132.199 with SMTP id o68mr10030881ioi.132.1508259746470; Tue, 17 Oct 2017 10:02:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.57.211 with SMTP id l202ls436318ita.8.canary-gmail; Tue, 17 Oct 2017 10:02:23 -0700 (PDT) X-Received: by 10.107.59.211 with SMTP id i202mr16695238ioa.79.1508259743670; Tue, 17 Oct 2017 10:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508259743; cv=none; d=google.com; s=arc-20160816; b=WTsIUVLai3IXcVkcfQaSg9BwYCwgIkbAryCBicvaWSa7o41rEcm6SY8MiMuisJn+8W vbAYKugmGWFn+aG8MQS2Xrl/SoI9XBSdTOzvdMK/3Wrac0ULp6Z3y/VoRbaC1YPLO0Ya CULRSZf2Sz3fVXSQPsATDeu1vsNsX09LeXIg3upg0XUDWrTL5Q6UPmIOxdHX+ojyTu66 /HaaDUJeHm5QgkZZmbeIRT7DqRQWK6pX0N/5Hb5rcbMBphjChc16a0ecy7i69/JW7wgn MuEy+A5kcv11OJUwmqLY+yYmAvwtVv9eJz0nu23vxybWNHmaeGxytZcVSzFbVDt+aA0H rnsw== 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:in-reply-to:references :mime-version:dkim-signature:arc-authentication-results; bh=iATWvMAXX8fl6jVz0SIXhgtCBlecn2395O40EFmj5nE=; b=IsQzq/GRF75cPfbDPwQhNyS8Ky0AQ62nnxkhVXErmuR5OD0umZJ6Ogep89uOlehyWZ 2E13u30uHH3HZ3YP9A8lrSCCqvxK1x/zbTrF8K1ctWPoqd3z6LNZXx/lClBI61BTgLcP 3AaXjYm+MZ+QvHUpNz/BsNsHALhaWxVc2G1apOP9HfqSNyufwClGfZXlVZTvQsRnrvmW nLpIYUME9qRAhkyjw25XLVrceREbaCumrEN0OvDrVIyXBLLX3mitQln7Ub0udH/+11sd ORsZa0Hc3WaoLmQlv8eXb7hU1BHnQOkFyWODrjrbELwsZO6E3tctLvfRGBaDmGI7Q26I M1Fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=m9XS85Px; spf=pass (google.com: domain of richardsmith@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=richardsmith@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.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 u81sor2221671itf.75.2017.10.17.10.02.23 for (Google Transport Security); Tue, 17 Oct 2017 10:02:23 -0700 (PDT) Received-SPF: pass (google.com: domain of richardsmith@google.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.36.61.133 with SMTP id n127mr6655201itn.106.1508259742987; Tue, 17 Oct 2017 10:02:22 -0700 (PDT) In-Reply-To: <89c7d198-0eec-4099-ba31-bad92706ebae@isocpp.org> X-Original-Sender: richardsmith@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=m9XS85Px; spf=pass (google.com: domain of richardsmith@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=richardsmith@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Richard Smith 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:34983 Archived-At: --001a11476de036456d055bc116e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 17 Oct 2017, 09:39 Arthur O'Dwyer, wrote: > This is related to Richard Smith and Andrew Hunter's P0722R0 "Controlling > destruction in delete expressions" > . > The paper begins this way: > > Consider the following class: > > class inlined_fixed_string { > public: > inlined_fixed_string() =3D delete; > const size_t size() const { return size_; } > > const char *data() const { > return static_cast(this + 1); > } > > // operator[], etc, with obvious implementations > > inlined_fixed_string *Make(const std::string &data) { > size_t full_size =3D sizeof(inlined_fixed_string) + data.size(); > return new(::operator new(full_size)) > inlined_fixed_string(data.size(), data.c_str()); > } > > private: > inlined_fixed_string(size_t size, const char *data) : size_(size) { > memcpy(data(), data, size); > } > size_t size_; > }; > > 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 us= e > "delete" on any pointer; but semantically, you should use "delete" only o= n > 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 aw= ay. > Please read to the end of the paper; that alternative is discussed and we explain why it is not entirely satisfactory. The corrected code looks like this > , and requires absolutely > no core language changes. > > class inlined_fixed_string { > public: > inlined_fixed_string() =3D delete; > size_t size() const { return size_; } > > char *data() { > return reinterpret_cast(this + 1); > } > > // operator[], etc, with obvious implementations > > static inlined_fixed_string *Make(const std::string &data) { > size_t full_size =3D sizeof(inlined_fixed_string) + data.size(); > return new(::operator new(full_size)) > inlined_fixed_string(data.size(), data.c_str()); > } > > static void Destroy(inlined_fixed_string *p) { > size_t full_size =3D sizeof(*p) + p->size(); > p->~inlined_fixed_string(); > ::operator delete(p, full_size); > } > private: > inlined_fixed_string(size_t n, const char *s) : size_(n) { > memcpy(data(), s, n); > } > ~inlined_fixed_string() {} > size_t size_; > }; > > int main() { > inlined_fixed_string *s =3D inlined_fixed_string::Make("hello world")= ; > inlined_fixed_string::Destroy(s); > > std::shared_ptr p(inlined_fixed_string::Make("h= ello shared"), inlined_fixed_string::Destroy); > } > > > > That said, if you do pursue "destroy and delete in one atomic operation", > it will be of especial interest to the garbage-collection and RCU folks. > Louis Dionne is interested in building a deferred_reclamation_allocator > that can defer calls to destroy() and deallocate() in pairs, which is > essentially the primitive you wanted to provide in P0722R0. (But again, y= ou > don't need P0722R0, and I'd much much rather the Committee not pursue it. > Nobody understands new/delete as it is; let's not make the situation even > worse out of a misbegotten wish to "delete" objects we haven't "new"ed.) > > Incidentally, if the individual words didn't already have domain-specific > meanings, I would love to describe inlined_fixed_string's semantics in > terms of the Make "factory function" and the Destroy "glue factory > function". ;) > > my $.02, > =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/CAGL0aWf-x-A5YaYoQYQw%2BxdokBHxGJ4MgZkc0%2B-B%2B= %2B5Da%2BFpOQ%40mail.gmail.com. --001a11476de036456d055bc116e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, = 17 Oct 2017, 09:39 Arthur O'Dwyer, <arthur.j.odwyer@gmail.com> wrote:
This is related to Richard Smith and An= drew Hunter's P0722R0 "Controlling destruct= ion in delete expressions".
The paper begins this way:

= 
Consider the following class:

class inlined_fixed_string {
  public:
   inlined_fixed_string() =3D delete;
   const size_t size() const { return size_; }

   const char *data() const {
     return static_cast<const char *>(this + 1);
   }

   // operator[], etc, with obvious implementations

   inlined_fixed_string *Make(const std::string &data) {
     size_t full_size =3D sizeof(inlined_fixed_string) + data.size();
     return new(::operator new(full_size))
                  inlined_fixed_string(data.size(), data.c_str());
   }

  private:
   inlined_fixed_string(size_t size, const char *data) : size_(size) {
     memcpy(data(), data, size);
   }
   size_t size_;
};

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 to the end of= the paper; that alternative is discussed and we explain why it is not enti= rely satisfactory.

= The corrected code looks like this, and requires absolutely no core la= nguage changes.

cl=
ass inlined_fixed_string {
  public:
   inlined_fixed_string() =3D delete;
   size_t size() const { return size_; }

   char *data() {
     return reinterpret_cast<char *>(this + 1);
   }

   // operator[], etc, with obvious implementations

   static inlined_fixed_string *Make(const std::string &data) {
     size_t full_size =3D sizeof(inlined_fixed_string) + data.size();
     return new(::operator new(full_size))
                  inlined_fixed_string(data.size(), data.c_str());
   }

   static void Destroy(inlined_fixed_string *p) {
     size_t full_size =3D sizeof(*p) + p->size();
     p->~inlined_fixed_string();
     ::operator delete(p, full_size);
   }
  private:
   inlined_fixed_string(size_t n, const char *s) : size_(n) {
     memcpy(data(), s, n);
   }
   ~inlined_fixed_string() {}
   size_t size_;
};

int main() {
    inlined_fixed_string *s =3D inlined_fixed_string::Make("hello worl=
d");
    inlined_fixed_string::Destroy(s);

    std::shared_ptr<inlined_fixed_string> p(inlined_fixed_string::Mak=
e("hello shared"), inlined_fixed_string::Destroy);
}


That said, if you do pursue "destroy and de= lete in one atomic operation", it will be of especial interest to the = garbage-collection and RCU folks. Louis Dionne is interested in building a = deferred_reclamation_allocator<T> that can defer calls to destroy() a= nd deallocate() in pairs, which is essentially the primitive you wanted to = provide in P0722R0. (But again, you don't need P0722R0, and I'd muc= h much rather the Committee not pursue it. Nobody understands new/delete as= it is; let's not make the situation even worse out of a misbegotten wi= sh to "delete" objects we haven't "new"ed.)
Incidentally, if the individual words didn't already have domain-speci= fic meanings, I would love to describe inlined_fixed_string's semantics= in terms of the Make "factory function" and the Destroy "gl= ue factory function". ;)

my $.02,
=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/CAGL0aW= f-x-A5YaYoQYQw%2BxdokBHxGJ4MgZkc0%2B-B%2B%2B5Da%2BFpOQ%40mail.gmail.com= ..
--001a11476de036456d055bc116e1-- .