220 40678 article Path: news.gmane.org!.POSTED!not-for-mail From: Gareth Lloyd Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Inferring stateless deleter from a partially stateful allocator Date: Mon, 22 Oct 2018 17:17:12 -0700 (PDT) Lines: 189 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/mixed; boundary="----=_Part_4740_922585725.1540253832801" X-Trace: blaine.gmane.org 1540253709 1665 195.159.176.226 (23 Oct 2018 00:15:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 00:15:09 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJTSELJQIITUNZ3YCRUBDULQSNE@isocpp.org Tue Oct 23 02:15:05 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f200.google.com ([209.85.219.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEkLh-0000LE-1g for gclcip-std-proposals@m.gmane.org; Tue, 23 Oct 2018 02:15:05 +0200 Original-Received: by mail-yb1-f200.google.com with SMTP id u14-v6sf2146029ybi.3 for ; Mon, 22 Oct 2018 17:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=rVnpixy8Y7jKoMIN3TKnIIzDxA9gylNy6Zgg8QSL4Pk=; b=c1ma3MSyC8AhIWTxMOMXrDJ9hALck5A7UqeKOWeSgV1lyKtVIXutOda1v1Zoqtw5JG jk4epXCGo+1lU25rep2tjjhmVFRtd0crLr/bbM/u+DRETcpVf9UEzzwrArXxYn0qCT6Q ABO7HK8OLQZE+sjLEWp+ZTAJ9K0/9IDqtu/rtDVnkV4OILqWKQvI6EFl9bwdU9V7r3CH 5uFnXxwbdNbMfiEBDLGY+KkLB2ZY4WyMFS4eEpLl7XtEHFCvY35JoxywmgBOdpMmdXLh LtS3jQxO+xB664uSrRQLn0qhi7CtC8Pt2CnWs9BJCkjIzkqlZqhQEHH/OObye5zFc2uV WCfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=rVnpixy8Y7jKoMIN3TKnIIzDxA9gylNy6Zgg8QSL4Pk=; b=sNipM7Ek2J4eoCgyVJPVD7IRrL4M7ZEGWZDpBKvHWHBaAcCUbZO2QoqDchJZ5/UJkF +3rh3vE45AFOcMAOQW1pDxT06ybjdjRfNB0JIrXUTqfVBvFXU2x9S/i1ET0OFlBZeItQ W4zQZ24HSdlqgNioqG+FmtOa5ysY0TC09Apcvfayj3v682WNNE0T9ucrSv/MKQFNsYuT KozqLdJ4pdmufzdCBPzgpPnXGZgxv9r4FGOWwvvqsghtMG/D9RO/NusRS/T4gADuMuSt RxHcmQ46rytYnK8gg6QpgrjXxzQqYBbrIPtmvdEjllN/UEOZMb3NBP8kD6zDWnngV2Ae MGqA== X-Gm-Message-State: AGRZ1gIIkwvdNjkDErbjEB3uuZgPZWyP2g7+vXaTqQObGVn92WXmkI2V d5ogv2Ng4EdiDLMoemoL/6CkoA== X-Google-Smtp-Source: AJdET5eJtxF7+mhv+RaMsHbPk3c/OXeZv4DNuovHdXlkL1t7qnXHKpGpIrOWfXA7A01J1p+B4/BzVg== X-Received: by 2002:a25:d904:: with SMTP id q4-v6mr2130378ybg.38.1540253835053; Mon, 22 Oct 2018 17:17:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:2c03:: with SMTP id s3-v6ls1172326yws.12.gmail; Mon, 22 Oct 2018 17:17:13 -0700 (PDT) X-Received: by 2002:a81:1a07:: with SMTP id a7-v6mr539561ywa.1.1540253833361; Mon, 22 Oct 2018 17:17:13 -0700 (PDT) In-Reply-To: <5f11127d-1ab8-41d8-8b8d-8e9781770f20@isocpp.org> X-Original-Sender: gareth@ignition-web.co.uk 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:40678 Archived-At: ------=_Part_4740_922585725.1540253832801 Content-Type: multipart/alternative; boundary="----=_Part_4741_1451322860.1540253832801" ------=_Part_4741_1451322860.1540253832801 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > IIUC and AFAICT, the only situation where this comes up in practice is=20 > with memory resources (heaps) where `deallocate` is a no-op. > > In practice `destroy` is always "stateless" because its behavior depends= =20 > only on the type T being destroyed, not on the identity of the allocator= =20 > doing the destruction. (In fact, I think Mark Zeren is working on a=20 > proposal to deprecate `destroy`, although I don't see it in the pre=E2=80= =93San=20 > Diego mailing.) > I can't think of a useful customization of `destroy` but one may exist, I'd= =20 like to hear more on the idea of deprecating it. =20 > Furthermore, observe that when `has_trivial_deallocate_v>`, then the= =20 > `unique_ptr` returned from `allocate_unique>` can be *trivially= =20 > destructible*. This seems like a very nice property to have,=20 > philosophically speaking, even though I can't off the top of my head come= =20 > up with any concrete application for it. > `unique_ptr` itself would need specializing to make it actually trivially= =20 destructibe and not just noop destructor. value_type must be trivailly=20 destructible, allocator uses default destroy and noop deallocate. (On a=20 related note see=20 https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5= Isw) =20 > A compromise approach might be to permit the allocator to specify a membe= r=20 > typedef `using deleter =3D ...` (defaulted to `allocator_delete>` in= =20 > `allocator_traits`) which could be customized by the designer of the=20 > allocator type. Then this deleter could be stateless and/or have a trivia= l=20 > `deallocate` method. > This possibly hints that a dual concept of a `maker` to mirror that of the= =20 `deleter`. Those would be a convient allocator_trait additions to have. =20 > Bottom lines: > - I think the property of *trivial* deallocate is much more directly=20 > relevant to your use-case than is the property of *stateless* deallocate. > =20 I think both are important. - I think it is not worth asking WG21 to pursue the *detection and=20 > exploitation* of either property, until there *exists* some standard=20 > allocator having the property, which is not likely ever to happen. It's= =20 > easy to hack up the existence and detection mechanisms within your own=20 > codebase, as you've done, and then provide `my::allocate_unique` to explo= it=20 > them. You don't need to be friends with `std::unique_ptr` to make that=20 > happen; you just need to provide a custom deleter type, which is already= =20 > possible in standard C++. > Custom deleter only gives us the noop deallocation, trivial destruction of= =20 unique_ptr requires more. Should P0316R0 "allocate_unique and allocator_delete" only consider the=20 standard allocator? If it makes it into that standard then it will need to= =20 allow specialized allocator_delete? In my other post=20 (https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs= 5Isw)=20 I show limitations of the winked-out optimization with existing containers= =20 and existing allocators. This may motivate the need for either more=20 allocators in the standard or better facilities to make your own. --=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/abd7a3bc-e438-4fa3-b26a-a8888bfec11a%40isocpp.or= g. ------=_Part_4741_1451322860.1540253832801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIUC and AFAICT, the only situation where this comes up in practic= e is with memory resources (heaps) where `deallocate` is a no-op.

In practice `destroy` is always "stateless" becau= se its behavior depends only on the type T being destroyed, not on the iden= tity of the allocator doing the destruction. (In fact, I think Mark Zeren i= s 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 m= ay 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>>` can be trivially destructible. This seems li= ke a very nice property to have, philosophically speaking, even though I ca= n't off the top of my head come up with any concrete application for it= ..

`unique_ptr` itself would nee= d specializing to make it actually trivially destructibe and not just noop = destructor. value_type must be trivailly destructible, allocator uses defau= lt destroy and noop deallocate. (On a related note see https://groups.googl= e.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw)
= =C2=A0
<= div>
A compromise approach might be to permit the allocator to sp= ecify a member typedef `using deleter =3D ...` (defaulted to `allocator_del= ete<A<T>>` in `allocator_traits`) which could be customized by = the designer of the allocator type. Then this deleter could be stateless an= d/or have a trivial `deallocate` method.

<= /div>
This possibly hints that a dual concept of a `maker` to mirror th= at 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 more directly relevant to your use= -case than is the property of=C2=A0stateless deallocate.
=C2=A0
I think both are important.

- I think it is not worth asking WG21 to pursue the detect= ion and exploitation of either property, until there exists some standard allocator having the property, which is not likely eve= r to happen. It's easy to hack up the existence and detection mechanism= s within your own codebase, as you've done, and then provide `my::alloc= ate_unique` to exploit them. You don't need to be friends with `std::un= ique_ptr` to make that happen; you just need to provide a custom deleter ty= pe, which is already possible in standard C++.

Custom deleter only gives us the noop deallocation, trivial= destruction of unique_ptr requires more.
Should P0316R0 "al= locate_unique and allocator_delete" only consider the standard allocat= or? If it makes it into that standard then it will need to allow specialize= d allocator_delete?
In my other post (https://groups.google.com/a= /isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw) I show limitations of = the winked-out optimization with existing containers and existing allocator= s. 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 &= 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/abd7a3bc-e438-4fa3-b26a-a8888bfec11a= %40isocpp.org.
------=_Part_4741_1451322860.1540253832801-- ------=_Part_4740_922585725.1540253832801-- .