220 34925 <2e191a96-1952-479b-b78b-22e31f8e03de@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea about "std::pmr::memory_resource" Date: Sat, 14 Oct 2017 10:29:38 -0700 (PDT) Lines: 137 Approved: news@gmane.org Message-ID: <2e191a96-1952-479b-b78b-22e31f8e03de@isocpp.org> References: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> <07ddb1f6-d3af-43df-bf96-8975c1ab4313@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14163_948040027.1508002178536" X-Trace: blaine.gmane.org 1508002190 25236 195.159.176.226 (14 Oct 2017 17:29:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 17:29:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBA4TRHHQKGQEC6EII7A@isocpp.org Sat Oct 14 19:29:46 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3QFg-0004RI-W5 for gclcip-std-proposals@m.gmane.org; Sat, 14 Oct 2017 19:29:33 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id q13sf4432657vkb.16 for ; Sat, 14 Oct 2017 10:29:40 -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=qAKP+Xo/ewKn4HDj39rohBqqTw7LB/44IlkNlmLWOZw=; b=BuxaB0ZaG/8jLOhtGyFT/t3DQXqLeJWXqLiUf4gFJGD+th/stOLmXmKsT8/2mM3a6E HNVv4sTiHkCsLjoucpMAEjMVOt0QJCMh2bS/1q/rxTXoIPxTw41RopbImkr6ODP26Q9r bXjdKRx9/nnnpGr/pUFkS77/yfJUmDel1+Pt4YqVHocJ8WsZdYAU7qLd6NsJ6A8lkHU4 RpF8fvV5kwNNxjsXE9jp0VwiV6O7x7Dd9iirQl/0Q2aRo7H4xOcm0troyQlPnbbfI88S HrEmWZ1A8OeWkOtXCGxr3/a1C5vjlOUp0LzE7Lm42i5hsz4fxo8pFprKyfgbaacjqgWN 0+IA== 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=qAKP+Xo/ewKn4HDj39rohBqqTw7LB/44IlkNlmLWOZw=; b=pqCSAwcrAgsJjWxy+sJIqA30g9D+i/illgoYTTg/B0qwcykj1C2cHs/6ccHM5tkfhB +CitqMyyemAvLuY+x1OOZHgA4OW+sNtPBIUSV5JoNJVYbNgccK64+m3ugYu1zHCdgV1S q6iYPZviKn489Fy1bhxxRYhzdpFjeqvfFWUj/0GvLtIznVYOHLXTLdDq+bixI2b8atCd eDMRF7KCa6FU2buQgb15olCmb5JGcwOY5wkvy73V9JXunPrOpKLXbSp/ovfU66Vkcz08 h/jvNv/HVdt8pFh0aGlpaPKkN18AwecyH2RaMmVyrIF+qiRIGaGMXeyM7/1wH5uhVx4f jtPQ== X-Gm-Message-State: AMCzsaWrt/FWX42yAP5g7JtEyvdJfkKDUyMv5/M9D6oMDXEjZv9Oq7vZ Gx2sbGZHBJQ8SoGo/ejQi7AP2w== X-Google-Smtp-Source: AOwi7QCQOAU3AGP+TjlBoXshzodyVBKFylrPNkwnrmg9ZUIK4A0fWn1TIhYxSeJojqU0CCEjtUbuYg== X-Received: by 10.31.193.138 with SMTP id r132mr2537851vkf.76.1508002180363; Sat, 14 Oct 2017 10:29:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.149.209 with SMTP id x200ls2380519vkd.11.gmail; Sat, 14 Oct 2017 10:29:39 -0700 (PDT) X-Received: by 10.31.142.13 with SMTP id q13mr319131vkd.1.1508002178984; Sat, 14 Oct 2017 10:29:38 -0700 (PDT) In-Reply-To: <07ddb1f6-d3af-43df-bf96-8975c1ab4313@isocpp.org> X-Original-Sender: wmx16835vv@163.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:34925 Archived-At: ------=_Part_14163_948040027.1508002178536 Content-Type: multipart/alternative; boundary="----=_Part_14164_1524026157.1508002178536" ------=_Part_14164_1524026157.1508002178536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your comments! On Saturday, October 14, 2017 at 10:57:42 PM UTC+8, Nicol Bolas wrote: > > > If you didn't need "polymorphism in memory allocation", why would you be= =20 > using polymorphic allocators? > This proposal is targeting at other polymorphic facilities in the standard,= =20 such as std::function, std::any, etc., because I think `memory_resource` is= =20 the facility with the most appropriate semantics defined in the standard=20 that provides an abstraction for type-independent memory allocation=20 algorithms. However, if I were a implementator of `std::any`, I will not=20 use it in the implementation due to performance considerations. =20 > If you have some type `allocator` that can allocate bytes, and you don't= =20 > mind the fact that `vector` will be different from other=20 > `vector` types... why would you use a `pmr::vector`? > I will only use `pmr::vector` if I have requirements on the polymorphism= =20 of allocators, and this seems to have nothing to do with what I'm saying=20 here. Actually, I think this idea will help improve the usability of=20 std::any and other polymorphic facilities. Maybe we could have something=20 like `template class any` defined in the standard in the= =20 future, and users are free to specify any memory management strategies.=20 Although this will require more effort to design and review, I think the=20 motivation to define MemoryResouece as a concept is relatively enough. > > Your proposal seems like a heavy-weight version of what we already have. > > And, generally speaking, people who need PMR aren't the people who turn= =20 > off RTTI in their builds. > I think RTTI is not necessary here, and a good design should avoid=20 unnecessary potential performance reduction in future implementation. If=20 the virtual function `is_equal` is removed from a memory resource (say,=20 =C2=B7pmr::synchronized_pool_resource=C2=B7), and `bool operator=3D=3D(cons= t=20 pmr::synchronized_pool_resource&)` is overloaded, there is no requirement= =20 for RTTI at all, so that the runtime overhead is reduced. Mingxin Wang --=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/2e191a96-1952-479b-b78b-22e31f8e03de%40isocpp.or= g. ------=_Part_14164_1524026157.1508002178536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments!

On Satu= rday, October 14, 2017 at 10:57:42 PM UTC+8, Nicol Bolas wrote:

If yo= u didn't need "polymorphism in memory allocation", why would = you be using polymorphic allocators?

This proposal is targeting at other polymorphic facilities in the sta= ndard, such as std::function, std::any, etc., because I think `memory_resou= rce` is the facility with the most appropriate semantics defined in the sta= ndard that provides an abstraction for=C2=A0type-independent memory allocat= ion algorithms. However, if I were a implementator of `std::any`, I will no= t use it in the implementation due to performance considerations.
=C2=A0
=
If you have some type `allocator` that can allocate bytes, and you don= 't mind the fact that `vector<T, allocator>` will be different fr= om other `vector` types... why would you use a `pmr::vector<T>`?

I will only use `pmr::vector<T&g= t;` if I have requirements on the polymorphism of allocators, and this seem= s to have nothing to do with what I'm saying here. Actually, I think th= is idea will help improve the usability of std::any and other polymorphic f= acilities. Maybe we could have something like `template <class MR =3D ..= ..> class any` defined in the standard in the future, and users are free = to specify any memory management strategies. Although this will require mor= e effort to design and review, I think the motivation to define MemoryResou= ece as a concept is relatively enough.

Your proposal seems like= a heavy-weight version of what we already have.

And, generally speaking, people who need PMR aren't the people who t= urn off RTTI in their builds.

I= think RTTI is not necessary here, and a good design should avoid unnecessa= ry potential performance reduction in future implementation. If the virtual= function `is_equal` is removed from a memory resource (say, =C2=B7pmr::syn= chronized_pool_resource=C2=B7), and `bool operator=3D=3D(const pmr::synchro= nized_pool_resource&)` is overloaded, there is no requirement for RTTI = at all, so that the runtime overhead is reduced.

M= ingxin Wang

--
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/2e191a96-1952-479b-b78b-22e31f8e03de= %40isocpp.org.
------=_Part_14164_1524026157.1508002178536-- ------=_Part_14163_948040027.1508002178536-- .