220 40697 article Path: news.gmane.org!.POSTED!not-for-mail From: Bryce Adelstein Lelbach aka wash Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Inferring stateless deleter from a partially stateful allocator Date: Wed, 24 Oct 2018 00:04:44 -0700 Lines: 223 Approved: news@gmane.org Message-ID: References: <5f11127d-1ab8-41d8-8b8d-8e9781770f20@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008e86370578f41a5d" X-Trace: blaine.gmane.org 1540364573 16232 195.159.176.226 (24 Oct 2018 07:02:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2018 07:02:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCWL3JV7Z4FRBGNTYDPAKGQEP457O5Q@isocpp.org Wed Oct 24 09:02:48 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it1-f200.google.com ([209.85.166.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFDBn-00045z-WB for gclcip-std-proposals@m.gmane.org; Wed, 24 Oct 2018 09:02:48 +0200 Original-Received: by mail-it1-f200.google.com with SMTP id e197-v6sf3914059ita.9 for ; Wed, 24 Oct 2018 00:04:58 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540364698; cv=pass; d=google.com; s=arc-20160816; b=RFTS67t9eVpAxjejFHZ2KPiTvH4GHqFy/0mnLfdx9fALyF6sy1HT+SeclktMvI8roa IkE3Q3RQP7nUwdK1SWp/hfRtdHLCdsRQo0poPGqdQIJrO8vnyEszypB0c/6Idh2Iqe3P frSyp7tf4suS2bBM9YsAFSrxXyMwMBAVhV4sW/YMgoflsY8eVgZVBsbfsoIi3YCy2pWG 8iO4y72c4RZGU3gBN142mVIJpn7lfoAOI6mkJr/CGX64DYJGOxv5IH883ttzZt2Boxrc 7u6WS002Nc6t4592AQ/K431huIz+vx5KOKbGGA8msRQ7vZ0RDjncj0bFD8Vxbxs4sQZN hLTw== 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:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=dUqOe2aRiPBbVLFq66szRicWmt0EhkgSCNAVYS4dvOg=; b=rryzSVZ1iHq5ZKt2D3wvkhCIFMH0o/rSb7N4QdJiG1yciKxcPwGW6XUBh38eTQjaa6 hV5YDHp/I/kzPlqUTeAe+ZibxpSRZAR9yg4FQoVOja2Hnpim58xxQ+eivT0oWuZXTETy t58E0zBLjwl6qLexgFlRSdAc3Fq+oLa5WTKWC/bKb34DOhdpbH+5sEl04O5SERum+4qh GmZp29t9cfMml1egZfLtoqwV00n7QrkdbywB/r2PSPL13lrtE6UfxqfydW2A4n+HN+AX nkxmgxdLQa3/sqP8MfmdyX+yIpscGpEoIan5KjNLOTlXSYUiOiPG8hOzB52XqtI8hxmc ZowQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mt2RGHkU; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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:references:in-reply-to:from:date:message-id:subject:to :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=dUqOe2aRiPBbVLFq66szRicWmt0EhkgSCNAVYS4dvOg=; b=fldGWqLQMoDtw9h+0l6ydkCmQaJepwg3qdfbiAx/1ClPeRwV01WJDRPTdcDB/RyOMV Is2lWQer36Qmuk0iHKVTNGzFI8BkdjUyUJ11Y9TqHWXjXc6pbxusUyUmqjEcrAUUMS1H wE2kCIRPBWFwv7diwe0pdY2DK/uRhXk9DFUEgDG5sF/LITzkf3f9dIHwZ9OaqtIr6pr+ My7NmtijVKxzj5o42jm0KeoyW47b4CAG6D2FCR3atEo6FaG092vnPPUrbA/yfHcMo2OF 1+ppTjJWROdvQ9XgauxsuDBPA7yIYOO51UFBfDiLuAyygv9uu56R+JwZxMrjc37sK4d9 w/3w== 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: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=dUqOe2aRiPBbVLFq66szRicWmt0EhkgSCNAVYS4dvOg=; b=rsLE3NwPdnFfq97Oxz7piXi8GWMAjmcpIsiq+eFu8o9nhOlBKw5kzByMIGLvboBSfZ emBfiSMQIKPf0nc2V/Uc7RJfaYOtdjtmHrAQjqud2kK3pE+0B8RsOIoW6/7AEkMGl24L 3DjulkdoPzXaQSU6t3FYUNNW3Et7RD6nZtRVj3LNF95vbf7rZT+R3Cbw9y8L28JZuJ8H j8yYMNjD2Tz7FsyE+DCAZ23PqjzHcy5ayT79sqwKSJLsFBvoPHjG04s/kiP/qHJEbFtq wdy6KvXCx573TYE6tH6aveZmR8W8OWDs7Rp5dkw1SVXuyz6GN+VzCGiWP3vgL1zwubRq UTjA== X-Gm-Message-State: AGRZ1gJeSEYCaE5or1eoUcZxW/W9G7rgMh8mQYR80+GL5wLYrkcgpavY fsJdz11GFEuo0Bb30MEix8aayQ== X-Google-Smtp-Source: AJdET5eBarNYhL0AbMiP/vSB7jOilCVfrtpPNfXLC42hS3E6QhMWRwf9aoRYA+g50hMAakZ7+XIQuw== X-Received: by 2002:a24:650c:: with SMTP id u12-v6mr940050itb.20.1540364698080; Wed, 24 Oct 2018 00:04:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a5e:990d:: with SMTP id t13-v6ls1051554ioj.8.gmail; Wed, 24 Oct 2018 00:04:57 -0700 (PDT) X-Received: by 2002:a6b:5208:: with SMTP id g8-v6mr2757847iob.273.1540364697052; Wed, 24 Oct 2018 00:04:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540364697; cv=none; d=google.com; s=arc-20160816; b=Us6MS3+g7JCvYJ7q6FAj7IBUwiMPEh5/8ZSFYNEBGRZD3eAyI7hLeOTRRxZAxbhCut keBItLW/xqRhgH9agWSo1VbxArw54OV8DWEJ3BcMf0dR6llMal9XCPphVBGq6kVAylZq AVhonA2dBACrWBJqX06/0rkgM7NHDwBXrjkYebNOnI7uX8w84Ab/pLEcrnPRg6qbeMLO /kH69E0BVEX9GmNYxGNi18Wf3Q9/GIkIotOcJOrnshYAp/yybxlGB+vJ477Qtq0iwZT7 Cxzk/t+WHY25JhyhIIhcSecbeIQogK6ydNxWjxzcJM0r0GTaQYb4dTm5ikpYfK5sXCne kgpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=9E7JYENNkNH/X5XgxxW41wW5ON5B0zi/UKju2UG2SV8=; b=Tuff/ovVUrDcrOAXHSpQuB5PgTdbZE0yjWHu0lO9bGjX9J44AZzCpph5QOGAYUav0L qScfF3oh0qHb3QdX7ReG/HoRzWJqMxmzcBwuuU7/9yngwxf72b6WJx6VmoZIwuWdE71j csHMAWlry6E6SYYajQ917OsZ4+YskGUQn/+Ze6C8OWtUnTy/1bANKmnq1i4TMr1/mmuP SdtQOfrtiiytqSEWO3ZCKdJ5vq4bq2743rt32GTTlDQBOknlvjK3wYKizmiSuPWiDQn5 M3ewVEPE8a5QU5+h94pMfWpkMhjWNL1OnZkKG4BlPEXgsNw1uZdWD8/gQErDcLVKH2Ij hXcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mt2RGHkU; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE 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 x8-v6sor5949340itb.36.2018.10.24.00.04.56 for (Google Transport Security); Wed, 24 Oct 2018 00:04:57 -0700 (PDT) Received-SPF: pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a24:1144:: with SMTP id 65-v6mr812815itf.103.1540364696452; Wed, 24 Oct 2018 00:04:56 -0700 (PDT) In-Reply-To: X-Original-Sender: brycelelbach@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mt2RGHkU; spf=pass (google.com: domain of brycelelbach@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=brycelelbach@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.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:40697 Archived-At: --0000000000008e86370578f41a5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An example of a weird destroy: the object lives on an accelerator and needs to be destroyed by a thread local to the accelerator. On Mon, Oct 22, 2018, 5:17 PM Gareth Lloyd wrote: > IIUC and AFAICT, the only situation where this comes up in practice is >> with memory resources (heaps) where `deallocate` is a no-op. >> >> In practice `destroy` is always "stateless" because its behavior depends >> only on the type T being destroyed, not on the identity of the allocator >> doing the destruction. (In fact, I think Mark Zeren is working on a >> proposal to deprecate `destroy`, although I don't see it in the pre=E2= =80=93San >> Diego mailing.) >> > > I can't think of a useful customization of `destroy` but one may exist, > I'd like to hear more on the idea of deprecating it. > > >> Furthermore, observe that when `has_trivial_deallocate_v>`, then th= e >> `unique_ptr` returned from `allocate_unique>` can be *trivially >> destructible*. This seems like a very nice property to have, >> philosophically speaking, even though I can't off the top of my head com= e >> up with any concrete application for it. >> > > `unique_ptr` itself would need specializing to make it actually trivially > destructibe and not just noop destructor. value_type must be trivailly > destructible, allocator uses default destroy and noop deallocate. (On a > related note see > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmE= s5Isw > ) > > >> A compromise approach might be to permit the allocator to specify a >> member typedef `using deleter =3D ...` (defaulted to `allocator_delete>` >> in `allocator_traits`) which could be customized by the designer of the >> allocator type. Then this deleter could be stateless and/or have a trivi= al >> `deallocate` method. >> > > This possibly hints that a dual concept of a `maker` to mirror that of th= e > `deleter`. Those would be a convient allocator_trait additions to have. > > >> Bottom lines: >> - I think the property of *trivial* deallocate is much more directly >> relevant to your use-case than is the property of *stateless* deallocate= .. >> > > I think both are important. > > - I think it is not worth asking WG21 to pursue the *detection and >> exploitation* of either property, until there *exists* some standard >> allocator having the property, which is not likely ever to happen. It's >> easy to hack up the existence and detection mechanisms within your own >> codebase, as you've done, and then provide `my::allocate_unique` to expl= oit >> them. You don't need to be friends with `std::unique_ptr` to make that >> happen; you just need to provide a custom deleter type, which is already >> possible in standard C++. >> > > Custom deleter only gives us the noop deallocation, trivial destruction o= f > unique_ptr requires more. > Should P0316R0 "allocate_unique and allocator_delete" only consider the > standard allocator? If it makes it into that standard then it will need t= o > allow specialized allocator_delete? > In my other post ( > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmE= s5Isw) > I show limitations of the winked-out optimization with existing container= s > and existing allocators. This may motivate the need for either more > allocators in the standard or better facilities to make your own. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/abd7a3bc-e43= 8-4fa3-b26a-a8888bfec11a%40isocpp.org > > . > --=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/CAP3wax_tk%2B_%3DGiVrsCUFrDvzV08OOcpMkK7j%3Dk_Uf= hZmAVCuiA%40mail.gmail.com. --0000000000008e86370578f41a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An example of a weird destroy: the object lives on a= n accelerator and needs to be destroyed by a thread local to the accelerato= r.

On Mon, Oct 22, 2018,= 5:17 PM Gareth Lloyd <gare= th@ignition-web.co.uk> wrote:
IIUC and AFAICT, the only situation where this comes up in practice i= s with memory resources (heaps) where `deallocate` is a no-op.
In practice `destroy` is always "stateless" because = its behavior depends only on the type T being destroyed, not on the identit= y of the allocator doing the destruction. (In fact, I think Mark Zeren is w= orking on a proposal to deprecate `destroy`, although I don't see it in= the pre=E2=80=93San Diego mailing.)

I can't think of a useful customization of `destroy` but one may = exist, I'd like to hear more on the idea of deprecating it.
=C2=A0
Furthermore, observe that when `has_trivial_deallocate_v<A<T>>= ;`, then the `unique_ptr` returned from `allocate_unique<T, A<T>&g= t;` can be trivially destructible. This seems like a very nic= e property to have, philosophically speaking, even though I can't off t= he top of my head come up with any concrete application for it.
=

`unique_ptr` itself would need specializin= g to make it actually trivially destructibe and not just noop destructor. v= alue_type must be trivailly destructible, allocator uses default destroy an= d noop deallocate. (On a related note see https://groups.google.com/a/isocpp.org/forum/#!topic/st= d-proposals/Rx3EmEs5Isw)
=C2=A0
A compromise approach = might be to permit the allocator to specify a member typedef `using deleter= =3D ...` (defaulted to `allocator_delete<A<T>>` in `allocator_= traits`) which could be customized by the designer of the allocator type. T= hen this deleter could be stateless and/or have a trivial `deallocate` meth= od.

This possibly hints that a = dual concept of a `maker` to mirror that of the `deleter`. Those would be a= convient allocator_trait additions to have.
=C2=A0
Bottom lines:
- I think the property of trivial deallocate is much m= ore directly relevant to your use-case than is the property of=C2=A0s= tateless deallocate.
=C2=A0
= I think both are important.

- I think it is not worth asking WG2= 1 to pursue the detection and exploitation of either property= , until there exists some standard allocator having the prope= rty, which is not likely ever to happen. It's easy to hack up the exist= ence and detection mechanisms within your own codebase, as you've done,= and then provide `my::allocate_unique` to exploit them. You don't need= to be friends with `std::unique_ptr` to make that happen; you just need to= provide a custom deleter type, which is already possible in standard C++.<= /div>

Custom deleter only gives us th= e noop deallocation, trivial destruction of unique_ptr requires more.
=
Should P0316R0 "allocate_unique and allocator_delete" only c= onsider the standard allocator? If it makes it into that standard then it w= ill need to allow specialized allocator_delete?
In my other post = (https://groups.google= ..com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw) I show limit= ations of the winked-out optimization with existing containers and existing= allocators. This may motivate the need for either more allocators in the s= tandard or better facilities to make your own.

--
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-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-propo= sals/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%40isocpp.org.

--
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/CAP3wax_tk%= 2B_%3DGiVrsCUFrDvzV08OOcpMkK7j%3Dk_UfhZmAVCuiA%40mail.gmail.com.
--0000000000008e86370578f41a5d-- .