220 40685 <5474c7c2-f539-4b53-85df-4f7449b8c285@isocpp.org> 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: Tue, 23 Oct 2018 05:36:35 -0700 (PDT) Lines: 89 Approved: news@gmane.org Message-ID: <5474c7c2-f539-4b53-85df-4f7449b8c285@isocpp.org> 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_5008_873197895.1540298195928" X-Trace: blaine.gmane.org 1540298072 15116 195.159.176.226 (23 Oct 2018 12:34:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 12:34:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJTSELJQINJK543YCRUBGTVRNBQ@isocpp.org Tue Oct 23 14:34:28 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEvtD-0003pn-LY for gclcip-std-proposals@m.gmane.org; Tue, 23 Oct 2018 14:34:27 +0200 Original-Received: by mail-yw1-f71.google.com with SMTP id 141-v6sf124598ywr.10 for ; Tue, 23 Oct 2018 05:36:38 -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=+Rx2796DTUP2DeTXmxTRKZDYJTd4rBz74dlrazMpWbw=; b=ltLYX086a2uQWYIL/U1CGsrJSCzcV6etmiC9sEH6ijqSSVRfCNbuJxbdYElNit7lrG nS+ABCrM8lPfbKOiiQ/JXdleLsMBrcaOdFSSNszGJ8a2Gp/NMBNY0FZtZBQoxecaK+OJ Vg9ltw5Jm7kPF3V8cfsu8lu6mHSyHUJttvIv0wYAesucY+M+UjtxRZ+LHYwllQawSQ5H vTXtYut8JAiMqlOa97Pkxh3pvbgwTUbZefpgOpKkNpTPFJap363OVj6FP4Bbt5ehF5vI mDZao7R606c80QoN2vkof/pZS2vRT8bdqK8RBffqKwsh38yuRysE98+bnRGEEgs4hRl1 tPPw== 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=+Rx2796DTUP2DeTXmxTRKZDYJTd4rBz74dlrazMpWbw=; b=ShvvfgO3H+tMhniId9yyHD2XqFbllAwyEWQU5he/pklk9ghRWxedmeOoTCI+YxTjPn boVvNsSbAgCcRK/LC3Zvj7/o3l/2A0bCwHpo91lX+CTg7Lj8jG4fFFtSFxTL+CXXA4ZS /cfdaXSryFrNXNFWKN7HGrly6LS1uFFGp1wK7VK59WMrZdCtuB0CShngQigXI31l4DZO cvtjXltoT34+FTdHUGrK38LcoQiBB43QRTwylDFj9wW4nVtoh9DOohX5niK5eu4qMbSj 9uccsMV+arygZL5T/5FUV7VEYZeKfBZrVcuuhoG+CGK6KSx7ZUHjW+ZEtvlkK7e6VpUg 3ftg== X-Gm-Message-State: ABuFfojM73Z8ew82g3SFsS7iALGv35EcjHmYXrIzs6Lx3I+RpBJwZpfM Qs54bqcaMzuyDrlrWKI4cNqEQw== X-Google-Smtp-Source: ACcGV631FdOGxjj/qXgUXLumPpWjCwvyWsQJboomheo41P0HEkdlaXym3LY00XTfE/FkocuxKkGWVw== X-Received: by 2002:a81:7307:: with SMTP id o7-v6mr29295852ywc.10.1540298198097; Tue, 23 Oct 2018 05:36:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:250f:: with SMTP id l15-v6ls1998317ywl.6.gmail; Tue, 23 Oct 2018 05:36:36 -0700 (PDT) X-Received: by 2002:a81:13d4:: with SMTP id 203-v6mr568268ywt.5.1540298196501; Tue, 23 Oct 2018 05:36:36 -0700 (PDT) In-Reply-To: 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:40685 Archived-At: ------=_Part_5008_873197895.1540298195928 Content-Type: multipart/alternative; boundary="----=_Part_5009_406449433.1540298195928" ------=_Part_5009_406449433.1540298195928 Content-Type: text/plain; charset="UTF-8" > > A compromise approach might be to permit the allocator to specify a member >> typedef `using deleter = ...` (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 trivial >> `deallocate` method. >> > > 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. > Having slept on this the obvious concept name would be `newer` (not a fan of the name). User defined types can provide new/delete overrides (customization point for external allocation). I know their are good reasons why allocators (customization point for internal allocations) did not go with the newer/deleter paradigm, there are advantages to working with raw memory separately from the object materialization(s). The newer/deleter typedefs do add convenience to the type designers that use allocators, but for the winked-out optimization giving a trivial destructible type `is_trivial_deleter_v` would also need to be part of the allocator (optional) + allocator_trait. That or some canonical implementation of the noop_deleter, that by convention is_same<> can be used to enable the is_trivial_destructible<> on the generic type (I do not advocate this approach). -- 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/5474c7c2-f539-4b53-85df-4f7449b8c285%40isocpp.org. ------=_Part_5009_406449433.1540298195928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A compromise approach might be to permit the allocator to specify a membe= r typedef `using deleter =3D ...` (defaulted to `allocator_delete<A<T= >>` in `allocator_traits`) which could be customized by the designer = of the allocator type. Then this deleter could be stateless and/or have a t= rivial `deallocate` method.

Thi= s possibly hints that a dual concept of a `maker` to mirror that of the `de= leter`. Those would be a convient allocator_trait additions to have.
<= /div>

Having slept on this the obvious conc= ept name would be `newer` (not a fan of the name). User defined types can p= rovide new/delete overrides (customization point for external allocation). = I know their are good reasons why allocators (customization point for inter= nal allocations) did not go with the newer/deleter paradigm, there are adva= ntages to working with raw memory separately from the object materializatio= n(s). The newer/deleter typedefs do add convenience to the type designers t= hat use allocators, but for the winked-out optimization giving a trivial de= structible type `is_trivial_deleter_v` would also need to be part of the al= locator (optional) + allocator_trait. That or some canonical implementation= of the noop_deleter, that by convention is_same<> can be used to ena= ble the is_trivial_destructible<> on the generic type (I do not advoc= ate this approach).

--
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/5474c7c2-f539-4b53-85df-4f7449b8c285= %40isocpp.org.
------=_Part_5009_406449433.1540298195928-- ------=_Part_5008_873197895.1540298195928-- .