220 40789 article Path: news.gmane.org!.POSTED!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Inferring stateless deleter from a partially stateful allocator Date: Fri, 26 Oct 2018 23:07:21 -0400 Lines: 134 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="00000000000011859605792d23a0" X-Trace: blaine.gmane.org 1540609535 9784 195.159.176.226 (27 Oct 2018 03:05:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2018 03:05:35 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIPLLGP3YCRUBF6SYEBQ@isocpp.org Sat Oct 27 05:05:30 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm1-f72.google.com ([209.85.128.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGEun-0002Ka-HJ for gclcip-std-proposals@m.gmane.org; Sat, 27 Oct 2018 05:05:29 +0200 Original-Received: by mail-wm1-f72.google.com with SMTP id u62-v6sf2998705wmd.6 for ; Fri, 26 Oct 2018 20:07:34 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540609654; cv=pass; d=google.com; s=arc-20160816; b=AfVpxf5/tSkZB8ChNvoVU5kvZA6CgHRoyx/RUKxx8onuYh8irtiTxcVe6cKdKjchkc S0O1n1pddssqUnAINN14X1ma60ZBZcTqo3DfayXsuW7M0eK0E1oeyGEciBGSIUOaq3eF guvzkMM2Zjs9zdo5Uqr8NIzfT+6125eqElXEnAF3NrHY9uqcH3aSSJAmdpD7XG8cSbKS jaywx8U/vNdGV6YNFNSTdEcwipSVyVdyhOkznKrNLaHPfHqA82CVTQ6j6DCoo07l7l/l 4UpxoEbTB6kaqeComzS3uR4caTqDoA1O3AJkm1wGeaU4WCufQshrxjpWyJ12Q3dC4RI5 HXYA== 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=GuZ05oGUu75x4Pqo/nVi49BqZ9syvSasxQUObIe57bw=; b=LGkV6R6MhogRExy5T3n7KR/4d3giwa/8GgB3pANdeKgkkm8b6PpPGPuMK1f9j6DKah yojRY/XYnbiZMzkkRHVjIKdOow+R9D5dYTIbfqg4STIQmKl8n9QlTydo0FWenGgUJzzE e2HOI3Au5YhFepyRTDebfLGJ+8O/pDGIBqiUicwOY6gqJFRDEkgO7KkJTCDDnuELE25E UAEUDP6yZQb1AuiVDXJnPINOm6IGi8rH/KXD8eoxyAtJrDSC6gFnNsHNKWsRj/wogOFN W+nlo58btVj7+a84fALiNiZX5vUPcfmMISF7zt6NEYomNGWy6vldK+gBO2ITH/TKrhxL cTpQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ksa1BadT; 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=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=GuZ05oGUu75x4Pqo/nVi49BqZ9syvSasxQUObIe57bw=; b=f/XmxiUi/z6x8e4VehwWaZRiUfEXr0X4ESWHRukz7tJAUuLGVOG9QUP3uYyYqHON4u pzMzC9otl7p+awNcPXPGZnoNdSeYZzIiY3irsOh3RbJhHsDAofRH/ZC7iiDgV1p47RlW BWt8xazQZ5vTvEeBjDeo2n6kgJl+gzCeeTtMcFvOUbR1We8zs1i2OOrbFDy6s8n95S5m PgJ4s5x63MzhuwDAtPAOVIMOJu439D3VdryJj/6q7Gq6twlMPdMA0621J6/2a3J67dI/ eFu0l5RxJnfeVNsLRJ3dpvcGv0FxPmMKznMSknJPFHm87uQ1jubB1W/Sga/rsQlSPJj1 dIjw== 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=GuZ05oGUu75x4Pqo/nVi49BqZ9syvSasxQUObIe57bw=; b=jSnu5dp61SaLiZs6LCDMFGi6bjPO/k/4XGZGQqmjISGTbWPyMYLPZ7wzvqNp1a+1cU 5aG4ukSqR5HWVZtR2c21MLEYqT+GNiITYxeojw3yDxm1EBu4w4ssIeSXrbp5Im8i+CLW zfM957kNUvQbdGso4oCZ6SAXgNxqrXOynhcQYVrG8CDDVUr53PykTQONPXArW8Q5fUL6 xw72JHqe6YPBTOkBT0DP1yWcAUziXyW0/8tH3mpE1dx84uS+539Cj5Zmq8pI1BQA85m2 QNPtfKN1oz0ieLbh6qqm4X1NxF/fSKJYqXNzq7sC5hph+CqG6pOooFG9gGMLGz8FqAwb aWVw== X-Gm-Message-State: AGRZ1gJpkPDt2Duo3uDdtDgIXxSzg8ZiBAMnEdCm/j3OtEAfdggdCklo 28KZssmE0jgHu3y1bOOsNJtKRw== X-Google-Smtp-Source: AJdET5dsU4y7/25xtZsXwiY8+XlMv5e8wuALZ17INzXXudEbk3AcDPZe0dEwH/mf0l4zza+CAYaHlA== X-Received: by 2002:a5d:4883:: with SMTP id g3-v6mr965939wrq.18.1540609654590; Fri, 26 Oct 2018 20:07:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a1c:8683:: with SMTP id i125-v6ls537081wmd.7.canary-gmail; Fri, 26 Oct 2018 20:07:33 -0700 (PDT) X-Received: by 2002:a1c:6543:: with SMTP id z64-v6mr7535439wmb.57.1540609653328; Fri, 26 Oct 2018 20:07:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540609653; cv=none; d=google.com; s=arc-20160816; b=bLeLfSusjne+G/n3koHKOcYYfeIqWLyXh3gr98y5DBFKHcUp4yp0JsXcTbPgF7S/U7 j349Cl+nvvxHl2H7X9UuhKvBwyv5vRdMPzT++qVzyzY63m43/EQwohMGr4wlmgaIaNX3 2wz+Af0keNJOBMFtjy3yXqufAnmrvFij7AOJVjwvpa/Xs8p1Ltq4gaWvKv7FsX+bYvAv yJ3OrW2FZ7o8RmQw15d173jCTVnUlCAN7vD4jUF1v6yH/3vgE8xfH8MCeIvFaqYvQmXP 2lZ58bCJsZ39BOv/W52jadFS5UsyWEUbT30zvt9G3Z65OgC2Mh69HGl93Cud1wbYke6N IN7Q== 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=MgP7vVIYS9+l5clIsBUP+lkh4aknVpW8mcYC/JQcVCA=; b=CxdcnMkyDi6f5mX2QQh4tb50nE1yNJndLgK/dSch2vu+Cm+ZQ82C7cVRBb7H2DZKJ4 OH5HcE2CjXqLke35w0uaKSxP6RaJMornBTRmYVhK5MDKppw8op6H0Go9pVtbt8X4DiOW OuaYDmKlSG4+r4kUmpBSrGbKs/+sN4y3Pr+Zr2NDOuvnJBIzSvPDYeTi0L5ziNmxExSk rYdR+y1MSuZXbZE3zPTgONksoI8VB/36ni44oZWntzS/iUbS2Ur/pZVkXK4xWfI52VUz GBYHnBBiioea9IviD9xWpULDfybakPGLlhnlK8xBN1Mq4U4NG7Giskc6RQ5ctOi0i70K 3QJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ksa1BadT; 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=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 d12-v6sor9002327wrj.1.2018.10.26.20.07.33 for (Google Transport Security); Fri, 26 Oct 2018 20:07:33 -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 2002:adf:ecc6:: with SMTP id s6-v6mr576255wro.208.1540609652391; Fri, 26 Oct 2018 20:07:32 -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=ksa1BadT; 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=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:40789 Archived-At: --00000000000011859605792d23a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2018 at 8: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 > destructible and not just noop destructor. > Right. This is the only reason (AFAICT) why you'd desire cooperation from the standard library. Everything else you want to do =E2=80=94 everything *= except* make unique_ptr trivially destructible =E2=80=94 can be done inside your::allocate_unique() in plain vanilla C++11 with no cooperation from the standard library at all. > value_type must be trivially 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 > ) > For the former, std::is_trivially_destructible is provided by the standard library. For the latter two, your::allocate_unique() would have to examine your::has_noop_deallocate_method, but that's fine because no *standard* allocators have noop `deallocate` methods, so you don't have to cooperate with the standard library for that one. =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/CADvuK0LocKvswhVB%2BiAtNCGazpJPKFwgMv0thmA8T_u%2= BxETbYA%40mail.gmail.com. --00000000000011859605792d23a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 22, 2018 at 8:17 PM Gareth Lloyd <gareth@ignition-web.co.uk> wro= te:
IIUC= and AFAICT, the only situation where this comes up in practice is with mem= ory resources (heaps) where `deallocate` is a no-op.

In practice `destroy` is always "stateless" because its behavi= or depends only on the type T being destroyed, not on the identity of the a= llocator 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.
=C2= =A0
Furt= hermore, observe that when `has_trivial_deallocate_v<A<T>>`, th= en the `unique_ptr` returned from `allocate_unique<T, A<T>>` ca= n be trivially destructible. This seems like a very nice prop= erty to have, philosophically speaking, even though I can't off the top= of my head come up with any concrete application for it.

`unique_ptr` itself would need specializing to m= ake it actually trivially destructible and not just noop destructor.
<= /div>

Right. This is the only reason (AFAIC= T) why you'd desire cooperation from the standard library. Everything e= lse you want to do =E2=80=94 everything except make unique_pt= r trivially destructible =E2=80=94 can be done inside your::allocate_unique= () in plain vanilla C++11 with no cooperation from the standard library at = all.
=C2=A0
=
value_type must be trivially destructible, allocator uses default des= troy and noop deallocate. (On a related note see https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/= Rx3EmEs5Isw)

For the fo= rmer, std::is_trivially_destructible<ValueType> is provided by the st= andard library.
For the latter two, your::allocate_unique() would= have to examine your::has_noop_deallocate_method<Allocator>, but tha= t's fine because no standard allocators have noop `deallocate` m= ethods, so you don't have to cooperate with the standard library for th= at one.

=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/CADvuK0LocKvs= whVB%2BiAtNCGazpJPKFwgMv0thmA8T_u%2BxETbYA%40mail.gmail.com.
--00000000000011859605792d23a0-- .