220 34936 <15f8c5ba-3a6a-4441-9620-92e157c66094@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 21:09:40 -0700 (PDT) Lines: 189 Approved: news@gmane.org Message-ID: <15f8c5ba-3a6a-4441-9620-92e157c66094@isocpp.org> References: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> <07ddb1f6-d3af-43df-bf96-8975c1ab4313@isocpp.org> <2e191a96-1952-479b-b78b-22e31f8e03de@isocpp.org> <0e37b5ae-64f6-4a8a-86bd-f44b119ed40a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15406_28269110.1508040580648" X-Trace: blaine.gmane.org 1508040587 7270 195.159.176.226 (15 Oct 2017 04:09:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 04:09:47 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBBN7RPHQKGQE6I7T4SA@isocpp.org Sun Oct 15 06:09:42 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3aF5-0000RM-BX for gclcip-std-proposals@m.gmane.org; Sun, 15 Oct 2017 06:09:35 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id w32sf5795799uaw.23 for ; Sat, 14 Oct 2017 21:09:43 -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=APcxHg+UqwZI9nHNtwf584EQcYAEk7C7O8e3rO7KjBw=; b=c/AEkyjj0j5ZvQV7ZvtN1IHrpeg7llq5VOc6PphtHx09sojbk7a8JIEuvb8MIvNuJF dwTj/6w4sBllX2eideLMEgRV3U4yZH86sDsZi1MUueZK00X3UmTrFgBS+bOrvTkzJqej 6o9f+uM+aNqCKTSRgsFnHZpzip7tIU8tNNPdK70dJMd4vxWB/uH93r64hQf+ZRxPq7qW wRVJkUn5umtx/PYDDbqgiCRQJDKPUkb+eHkdisqTGo9doqnElc4qn2iF2pae39rvZ7Ql vzF/oP6Q1cZTuuoMsgz5rn0Qztepdzgp1tNsEHeDYE9M8B3NmesCY36SuRvyrD1ZkI8D hTOQ== 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=APcxHg+UqwZI9nHNtwf584EQcYAEk7C7O8e3rO7KjBw=; b=l7L1LZ7mhj3NRZegBAcPU8sGU3NGGp8CrGnTuVsJV4zzy9GMsDIMF/Obf24saZS7EJ aKfCdnJEINADjp40NWJuQeE4Bno5x4JOwLQvGHvJ7dgJ2aF43F2CxbjDc4T1H+rgd75h LsYFIadTL0rUNwoe598QDiWc338A89LDJR2HuCZHXKppWodER1JElPwlWRWUfKoUT5Tr xgu6MxPZo+zOh0yZKMupbGRnPhKEHlmRabn5+TrPi1K3HMCFnChcpVxZpPNjI1hM9JvU OHocfJlBMbvU6nSuFgA2OotT8dgivl+RtS4IlPZG/PPOob+1/k+ivlBCHh8gTeLtP5gh klxw== X-Gm-Message-State: AMCzsaWbuxmvpuSkWCn2Ec98mrii6TIVEWndeiQPZsDFW7MVPIzrc/yu VcqibBLKNLV6JH9uWbl/j6NWhw== X-Google-Smtp-Source: AOwi7QA1OAsBYPx6ws2fXoAgmlDRNndKq379mR6rpPg4l+3Xfk1du4wsGrVPiTX7Iel+qysSUHuqSw== X-Received: by 10.176.84.214 with SMTP id q22mr3197743uaa.33.1508040582552; Sat, 14 Oct 2017 21:09:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.76 with SMTP id j73ls2639102vke.12.gmail; Sat, 14 Oct 2017 21:09:41 -0700 (PDT) X-Received: by 10.31.168.133 with SMTP id r127mr74828vke.8.1508040581228; Sat, 14 Oct 2017 21:09:41 -0700 (PDT) In-Reply-To: <0e37b5ae-64f6-4a8a-86bd-f44b119ed40a@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:34936 Archived-At: ------=_Part_15406_28269110.1508040580648 Content-Type: multipart/alternative; boundary="----=_Part_15407_1360794511.1508040580648" ------=_Part_15407_1360794511.1508040580648 Content-Type: text/plain; charset="UTF-8" On Sunday, October 15, 2017 at 4:39:33 AM UTC+8, Nicol Bolas wrote: > > On Saturday, October 14, 2017 at 1:29:38 PM UTC-4, Mingxin Wang wrote: >> >> 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 >>> using polymorphic allocators? >>> >> >> This proposal is targeting at other polymorphic facilities in the >> standard, such as std::function, std::any, etc., because I think >> `memory_resource` is the facility with the most appropriate semantics >> defined in the standard that provides an abstraction for type-independent >> memory allocation algorithms. However, if I were a implementator of >> `std::any`, I will not use it in the implementation due to performance >> considerations. >> > > OK, so you're trying to find a way to solve the "type-erased allocators > don't work in `std::function`" problem. I don't see how what you've > suggested does that. > > PMR, at its core, is based on polymorphism via inheritance. That is, > dynamic polymorphism. Polymorphism based on concepts is either static > polymorphism (ie: `vector`) or dynamic polymorphism > via a type-erased mechanism. > > Static polymorphism isn't appropriate for `function` and `any`. And > dynamic polymorphism via type-erasure *does not work*; that's why there's > a problem to begin with. > I am saying that "static polymorphism *could be* appropriate for `function` and `any`" if a concept for type-independent allocators is introduced, and I think it should be "MemoryResource". So the only form of polymorphism that can work here is inheritance-based > polymorphism. > > If you have some type `allocator` that can allocate bytes, and you don't >>> mind the fact that `vector` will be different from other >>> `vector` types... why would you use a `pmr::vector`? >>> >> >> I will only use `pmr::vector` if I have requirements on the >> polymorphism of allocators, and this seems to have nothing to do with what >> I'm saying here. >> > > But... *you* were the one who brought up the whole PMR system. > > >> Actually, I think this idea will help improve the usability of std::any >> and other polymorphic facilities. Maybe we could have something like >> `template class any` defined in the standard in the >> future, and users are free to specify any memory management strategies. >> Although this will require more effort to design and review, I think the >> motivation to define MemoryResouece as a concept is relatively enough. >> > > Adding static polymorphism to a type whose *whole purpose* is built > around dynamic polymorphism (through type-erasure) makes no sense. Even if > we were going to do this, we'd just use the already existing Allocator > concept. > I think "polymorphic allocator" and "allocator for polymorphic types" are not same concepts. On the one hand, "polymorphic allocator" is the type that could have polymorphic allocation behaviour, but could also be type-specific (Allocator::value_type), like the class template `std::pmr::polymorphic_allocator` does. On the other hand, "allocator for polymorphic types" is the type that could be used to allocate memory for any type, but may not have polymorphic allocation behaviour. I think the semantics of "std::pmr::memory_resource" should be "allocator for polymorphic types" instead of "polymorphic allocator", and therefore it shall not be polymorphic. Mingxin Wang -- 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/15f8c5ba-3a6a-4441-9620-92e157c66094%40isocpp.org. ------=_Part_15407_1360794511.1508040580648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, October 15, 2017 at 4:39:33 AM UTC+8, Nicol Bol= as wrote:
On S= aturday, October 14, 2017 at 1:29:38 PM UTC-4, Mingxin Wang wrote:
Thanks for your commen= ts!

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

If you didn't need "polymorphism in memory al= location", why would you be using polymorphic allocators?
<= /blockquote>

This proposal is targeting at other polymor= phic facilities in the standard, such as std::function, std::any, etc., bec= ause I think `memory_resource` is the facility with the most appropriate se= mantics defined in the standard that provides an abstraction for=C2=A0type-= independent memory allocation algorithms. However, if I were a implementato= r of `std::any`, I will not use it in the implementation due to performance= considerations.

OK, so you'= ;re trying to find a way to solve the "type-erased allocators don'= t work in `std::function`" problem. I don't see how what you'v= e suggested does that.

PMR, at its core, is based = on polymorphism via inheritance. That is, dynamic polymorphism. Polymorphis= m based on concepts is either static polymorphism (ie: `vector<T, someAl= locatorType>`) or dynamic polymorphism via a type-erased mechanism.

Static polymorphism isn't appropriate for `functio= n` and `any`. And dynamic polymorphism via type-erasure does not work; that's why there's a problem to begin with.

I am saying that "static polymorphism could= be appropriate for `function` and `any`" if a concept for type-in= dependent allocators is introduced, and I think it should be "MemoryRe= source".

So the only form of polymorphism that can work = here is inheritance-based polymorphism.

If you have some type `allocator` that can= allocate bytes, and you don't mind the fact that `vector<T, allocat= or>` will be different from other `vector` types... why would you use a = `pmr::vector<T>`?

I will = only use `pmr::vector<T>` if I have requirements on the polymorphism = of allocators, and this seems to have nothing to do with what I'm sayin= g here.

But... you were = the one who brought up the whole PMR system.
=C2=A0
Actually, I think= this idea will help improve the usability of std::any and other polymorphi= c facilities. Maybe we could have something like `template <class MR =3D= ...> class any` defined in the standard in the future, and users are fr= ee to specify any memory management strategies. Although this will require = more effort to design and review, I think the motivation to define MemoryRe= souece as a concept is relatively enough.

=
Adding static polymorphism to a type whose whole purpose = is built around dynamic polymorphism (through type-erasure) makes no sense.= Even if we were going to do this, we'd just use the already existing A= llocator concept.

I think "= ;polymorphic allocator" and "allocator for polymorphic types"= ; are not same concepts. On the one hand, "polymorphic allocator"= is the type that could have polymorphic allocation behaviour, but could al= so be type-specific (Allocator::value_type), like the class template `std::= pmr::polymorphic_allocator` does. On the other hand, "allocator for po= lymorphic types" is the type that could be used to allocate memory for= any type, but may not have polymorphic allocation behaviour. I think the s= emantics of=C2=A0"std::pmr::memory_resource" should be "allo= cator for polymorphic types" instead of "polymorphic allocator&qu= ot;, and therefore it shall not be polymorphic.

Mi= ngxin 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/15f8c5ba-3a6a-4441-9620-92e157c66094= %40isocpp.org.
------=_Part_15407_1360794511.1508040580648-- ------=_Part_15406_28269110.1508040580648-- .