220 40819 article Path: news.gmane.org!.POSTED!not-for-mail From: Gareth Lloyd Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Inferring stateless deleter from a partially stateful allocator Date: Mon, 29 Oct 2018 22:52:47 +0000 Lines: 160 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="000000000000499da3057965ee8a" X-Trace: blaine.gmane.org 1540853459 22709 195.159.176.226 (29 Oct 2018 22:50:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2018 22:50:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCTJTSELJQIM3HW63YCRUBAMBA5GU@isocpp.org Mon Oct 29 23:50:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr1-f69.google.com ([209.85.221.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHGN2-0005ly-H8 for gclcip-std-proposals@m.gmane.org; Mon, 29 Oct 2018 23:50:52 +0100 Original-Received: by mail-wr1-f69.google.com with SMTP id e11-v6sf8586482wrr.14 for ; Mon, 29 Oct 2018 15:53:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1540853582; cv=pass; d=google.com; s=arc-20160816; b=Qa5gAEE1dwjy34tAAQEaLrn1hFnxszpWPEPLYBAkG7kZMHgGphrqlixgCbnG2JNFJ6 frLnysc73f0buSqSavwM3kWzDtRkLfI3R0hxztMy53rlWNKiGOnzWM64gjA3JWg2vznc iN3YyBvCOZdwmtxebiI+vI5197nduaWimtTq4nMg9KkSYeEWNf65MuqwA+fEhZhFehdZ 8HeAQjblXf+CXvjb62/K9FQakVKggejtVcYf6wReqB8JzDWGGo0xxC7Y5UgV+PmQhKIK h0NNVzp3q2o9q8cVEjps2KSwjzJ1ugNORzANLNT66CwDHOOMeFgafCeA3rwLDMs+oKZh 3Y7g== 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=TyE66Y7dONxC2ulrJjVCiyf/1JPBmln36XCLLvUKd9s=; b=umme5+om4ieyMBult6q4Ymdyj5T6ZIb+xfMr1PX7Ng0OBdJlwDfiQeh3xcFW1wWxmE ZLzwm83Sm/AjowsTmP0ylJpChSHrFU6uBfcryEcS9PypraAWWv6OurdY/T3gC8SiLnxY VJERLY9RWczy4g0p58rZHgOBapJu7GgeslTW3FJtS57TmrOUurB6Yw85uCXejmeAebje IhG0kjAsa8uIJHPNwyqkKBdlI54H1lwWJJt+CncrPNlcD/0jkijf884/G62eZY6Hvn62 s/pH4Xaq8LHBFNyUrr2bOdsEo3mg4T8j7jV5l02sQX/gPs4SXU+Xy2kcvE5ffpPIYzZs CadA== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of gareth.andrew.lloyd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gareth.andrew.lloyd@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=TyE66Y7dONxC2ulrJjVCiyf/1JPBmln36XCLLvUKd9s=; b=Dmig7nOQu0IQSIxn07dRqAX/bP3xiZyGonXXMWC6pixXNbrIJpZWUmBZ12ttGdFYtA qKZAZPWvISpKHSromhMADnBEGmWfY6WyuLW35b8F7lPHoolYwCC8x6Cn/QUSHEnnpKf5 LpBtX7+PpChCHQchOcwyDFO6zfBbzCW1EQsN10b9qirMKc1gTbDUhS0JmZk9Fn71iRy7 DyqchoNxeiQUnLf7cZ+uQg7/daKOUEb1fTJ3I3SiBk/8uN7HctIHHUyT9ihkSbp/YEHo mBlLo5FqjE1OgzWULGWIXe0l4CKu3MidHtRgA6R+j2R0iSk9/IZKyplbB0wr39BrEsTu ZQWw== 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=TyE66Y7dONxC2ulrJjVCiyf/1JPBmln36XCLLvUKd9s=; b=GzDvUjyYT0U8WsD8wCie0HYS3WJksFg/wYLwMgHWWokl3wmwQBp8Lbr3sMMKk6LW2h JXHH8qzX6HLeY1CjhbbB1r8mEIyT5wN9I5BHu3CAokVfbdn51+rQZsBBroMlX5tqV/hU G04cZ6/uBWu27ySIf/E4IdGUIg7yMckVl0AvBkiVdgtjEKzp3ppCrPfUeY73HM829Wj0 +KNBnBn5Szkhl7uqBJT/kGU2JgLR5PHCeG0Jryh4j5gChEoRfmrWxM1DspjoXAyx3t7s IavVmK6LopXeCxgO6ops3rEuBt0k1f9714rooRFMXhsdweKx5lGL5ItMQ/sDHQa4EADm Jr8g== X-Gm-Message-State: AGRZ1gITReHR9GsAk1O6kT/y/ReAlqd2PehqnZBZrQD4a9q7Bz7K+YwG pd+vE+FEzR8ZzPTqIRftjmU= X-Google-Smtp-Source: AJdET5fje18cnsrcW+Qh0bvko5pWTLYzN3xN2IFcyxXPE0csC0ssqI2td4i2SvRTSGPs7aMBb7iR+g== X-Received: by 2002:a1c:f704:: with SMTP id v4-v6mr1378717wmh.20.1540853582777; Mon, 29 Oct 2018 15:53:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:b587:: with SMTP id c7-v6ls952301wre.21.gmail; Mon, 29 Oct 2018 15:53:00 -0700 (PDT) X-Received: by 2002:adf:c650:: with SMTP id u16-v6mr17586984wrg.177.1540853580774; Mon, 29 Oct 2018 15:53:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540853580; cv=none; d=google.com; s=arc-20160816; b=AqT9T+n9fna5pw5qscQm60IKWo0C2e8pcLeFQ2O/MSdlf3CZfN1Pb4x7LgnGHBeSq3 SH8un109Jjo7eyKtv1HXHesTFtsXEMurmK0PdjYitIOq/6vAKEpMp6uvuZ58RmNIn9NS jibHY12Y1n21wOfNDU0jHY7SPubnWBlW2w2YotJMik/c0lJSsNSjPDOwN6VY/c5dTgzM 496YJ3yY7uGjQ3iIqUDrE5Vs7/PYiIWIpkKF+7Dxu7rKoGuGe8g75NK1NqQ/fNOU0nfA 0ZTUY+LFAsa0Yh1sGxRmpGc8Jp7ZQZ1balVqSVnLx6eoDp0qzJz3aeeJcJEugxDfPZtP CRTw== 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; bh=rrlpdmILCTDwCY+2UgdOZyE7NriqAb0v/EeFi7bzdZY=; b=Y2XM8tudDexZRZBBRYMmGplWrxdM4SWLsMy/E/sUv/9bvuhfHCXpGbMfYDAOt6LhxF WYbfx2cNKYmrvTyKX23Rf437RYldC4alnoDfupOv+xK4K8JCinyOhh36dF4Pr/A6/DkT Q50l7rZ9CCUtErKGQDh0Qa3KRzNomsyD5ty+nHLENKMStPfxunvismvnoRR1tikAheg+ mjv0tnQC8U/5CTxQo5sI3ZRK2oDoZyQ9XlY92SUbypxG+ovUAcDQ5XizS8zfw92H8/XD W3/qmpPabSyJqRXpTInx1Svfxpbw6VOtVStxy4Y7yr456+c89Ub+UkCZumKBFpnYy+iQ N41g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gareth.andrew.lloyd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gareth.andrew.lloyd@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 b11-v6sor11252947wrj.21.2018.10.29.15.53.00 for (Google Transport Security); Mon, 29 Oct 2018 15:53:00 -0700 (PDT) Received-SPF: pass (google.com: domain of gareth.andrew.lloyd@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:adf:9e8f:: with SMTP id a15-v6mr15348798wrf.70.1540853580011; Mon, 29 Oct 2018 15:53:00 -0700 (PDT) In-Reply-To: X-Original-Sender: gareth@ignition-web.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gareth.andrew.lloyd@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gareth.andrew.lloyd@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:40819 Archived-At: --000000000000499da3057965ee8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Furthermore, observe that when `has_trivial_deallocate_v>`, then the >>> `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 co= me >>> up with any concrete application for it. >>> >> >> `unique_ptr` itself would need specializing to make it actually triviall= y >> 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 t= he > standard library at all. > > >> value_type must be trivially destructible, allocator uses default destro= y >> and noop deallocate. (On a related note see >> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3Em= Es5Isw >> ) >> > > 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. > I urge that you read '=E2=80=9CWinked-out=E2=80=9D optimization on generic = collections"' https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5= Isw if you have not already. It should help frame my motivations better. It is not just unique_ptr this applies to, I have considering more that that. I desire such a facility within the standard library because something like this is required to enable all types in the standard, that use allocators, to have a standard mechanism to be trivial_destructible depending upon the provided allocator. These posts are based on a code transformation process, based on John Lakos ACCU and CppCon talks, that I've done on the codebase I work on. Using the PMR pattern with monotonic_buffer_resource lost the winked out optimization (LTO didn't help) and trivial destructable types that the codebase previously had. I did this work because of the shortcomings I found with using std::pmr::monotonic_buffer_resource with generic code. This pattern allowed me to decouple the allocator used (using regular allocator concept) which helps with testing a component, but in production still have an optimized datastructure with the more optimizable monotonic allocator given via template parameter. My findings were that current set of standard allocators are not complete/finished, pmr has demonstrated one way to do allocators but it is not nessisarily the holy grale or the end. --=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/CANgTfEhvTfauen%3DGS71y11T%2BQY48Z7joDNXB5O5T%3D= 8LpYNgTJg%40mail.gmail.com. --000000000000499da3057965ee8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Furthermore, observe that when `has_tri= vial_deallocate_v<A<T>>`, then the `unique_ptr` returned from `= allocate_unique<T, A<T>>` can be trivially destructible. This seems like a very nice property to have, philosophically speak= ing, even though I can't off the top of my head come up with any concre= te application for it.

`unique_= ptr` itself would need specializing to make it actually trivially destructi= ble 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 everyt= hing except make unique_ptr trivially destructible =E2=80=94 = can be done inside your::allocate_unique() in plain vanilla C++11 with no c= ooperation from the standard library at all.
=C2=A0
value_type= must be trivially destructible, allocator uses default destroy and noop de= allocate. (On a related note see https://= groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Rx3EmEs5Isw)=

For the former, std::is_tr= ivially_destructible<ValueType> is provided by the standard library.<= /div>
For the latter two, your::allocate_unique() would have to examine= your::has_noop_deallocate_method<Allocator>, but that's fine bec= ause no standard allocators have noop `deallocate` methods, so you d= on't have to cooperate with the standard library for that one.

I urge that you read '=E2=80=9CWinked-out=E2=80=9D o= ptimization on generic collections"' https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos= als/Rx3EmEs5Isw if you have not already. It should help frame my motiva= tions better.

It is not just unique_ptr this appli= es to, I have considering more that that. I desire such a facility within t= he standard library because something like this is required to enable all t= ypes in the standard, that use allocators, to have a standard mechanism to = be trivial_destructible depending upon the provided allocator.

These posts are based on a code transformation process, b= ased on John Lakos ACCU and CppCon talks, that I've done on the codebas= e I work on. Using the PMR pattern with=20 monotonic_buffer_resource lost the winked out optimization (LTO didn't help) and trivial destruct= able types that the codebase previously had.=20 I did this work because of the shortcomings I found with using=20 std::pmr::monotonic_buffer_resource with generic code. This pattern allowed= me to decouple the allocator used (using regular allocator concept) which = helps with testing a component, but in production still have an optimized d= atastructure with the more optimizable monotonic allocator given via templa= te parameter. My findings were that current set of standard allocators are not complete/finished, pmr has demonstrated one way to do allocators=20 but it is not nessisarily the holy grale or the end.=20

--
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/CANgTfEhvTf= auen%3DGS71y11T%2BQY48Z7joDNXB5O5T%3D8LpYNgTJg%40mail.gmail.com.
--000000000000499da3057965ee8a-- .