220 34949 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: Sun, 15 Oct 2017 10:05:37 -0700 (PDT) Lines: 513 Approved: news@gmane.org Message-ID: 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> <15f8c5ba-3a6a-4441-9620-92e157c66094@isocpp.org> <26fe4cb4-98ca-41cc-ac96-5c51851799d1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12747_138489169.1508087137706" X-Trace: blaine.gmane.org 1508087144 31716 195.159.176.226 (15 Oct 2017 17:05:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 17:05:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBYVKR3HQKGQE5QPNQJI@isocpp.org Sun Oct 15 19:05:39 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 1e3mM0-0006le-Kw for gclcip-std-proposals@m.gmane.org; Sun, 15 Oct 2017 19:05:32 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id s198sf5214942vkf.10 for ; Sun, 15 Oct 2017 10:05: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=txd5CIoDRf3u0kDf5S9wEASxheUlfxBPrYpfj0gi4Mw=; b=JV2HwPmv7nPk13F29amEWh1mqcZ/YUqqEzrIdQib+g+vqC6ejslVej/3x2D9LJ9XQx X4rycqNi44MeOFgUiUba+Mf3P10ZqhrWzESaguy6d3jeGLgKH6oImSDI8P0iWmHyoCV8 zdKRcZzlQ/lBw4DTPwsl3YRxMu9aj4Y/ghrHpLOGzZ7KsmphTLFMClAb0YqJGI+ML4ZX fMijqvUwPv//KiYi4gDIcPUWCFf3xFoQu1D86GwTv9eMeRc+W9DCgq9ha3EmxzuAvI1B z6kyP3dXZxU0CnyeFrxBmStXewDpvIs3wZCMxoO5Tl+rg8gB3rM1OJLC0AStqmYwOIwM YUVA== 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=txd5CIoDRf3u0kDf5S9wEASxheUlfxBPrYpfj0gi4Mw=; b=tRPZi5qpJBrxcCFyqqU82d1TzjYZENoCzol0IOl/BUOHdVAVrxAjfJZ2L+6Pxequ/r lL8CgK+OoHXJAAEVagNwqF2zvOzpjklrr7k+Q8EmK7toYkywqx5sOiYxrozeIbi3yyKc 2vh4OIdBMgShYZk+K9oDGYHCSw21BqV1KAHx63whA3obLqn6h+7KsFthm1wtc06dMEBy /rKNcG9dxIpc9kdWU1QgvJKWEYVsNj4ZJwvaBQzShFMUMpTRUa+yJGn9Q7/ovoTbYTSy IDHdippIRB3oGsu/x4+rzfTzJqXEuQIegBNZlbZtuEFipS8zmO0F0F1RMOKnhktFUTtI tTQQ== X-Gm-Message-State: AMCzsaWq+uPF1E5Ld9rtStxNwtPTqeVz2C020DBLScWhkl17hROYuTS3 9bkP2U2MvklbSjyUwJMTybtTxQ== X-Google-Smtp-Source: AOwi7QBazvAlKlkDDdeGD0I62m8OJqJJClOjzBIsgRZzoCLnaxrHjRUTk/xQPm5kwNtaax0uS0P+JQ== X-Received: by 10.176.1.227 with SMTP id 90mr3922441ual.87.1508087139760; Sun, 15 Oct 2017 10:05:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.131.146 with SMTP id f140ls2707543vkd.13.gmail; Sun, 15 Oct 2017 10:05:38 -0700 (PDT) X-Received: by 10.31.96.146 with SMTP id u140mr533208vkb.2.1508087138207; Sun, 15 Oct 2017 10:05:38 -0700 (PDT) In-Reply-To: <26fe4cb4-98ca-41cc-ac96-5c51851799d1@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:34949 Archived-At: ------=_Part_12747_138489169.1508087137706 Content-Type: multipart/alternative; boundary="----=_Part_12748_2135675636.1508087137706" ------=_Part_12748_2135675636.1508087137706 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, October 15, 2017 at 11:12:03 PM UTC+8, Nicol Bolas wrote: > > On Sunday, October 15, 2017 at 12:09:40 AM UTC-4, Mingxin Wang wrote: >> >> 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= =20 >>>>> be using polymorphic allocators? >>>>> >>>> >>>> This proposal is targeting at other polymorphic facilities in the=20 >>>> standard, such as std::function, std::any, etc., because I think=20 >>>> `memory_resource` is the facility with the most appropriate semantics= =20 >>>> defined in the standard that provides an abstraction for type-independ= ent=20 >>>> memory allocation algorithms. However, if I were a implementator of=20 >>>> `std::any`, I will not use it in the implementation due to performance= =20 >>>> considerations. >>>> >>> >>> OK, so you're trying to find a way to solve the "type-erased allocators= =20 >>> don't work in `std::function`" problem. I don't see how what you've=20 >>> suggested does that. >>> >>> PMR, at its core, is based on polymorphism via inheritance. That is,=20 >>> dynamic polymorphism. Polymorphism based on concepts is either static= =20 >>> polymorphism (ie: `vector`) or dynamic polymorphi= sm=20 >>> via a type-erased mechanism. >>> >>> Static polymorphism isn't appropriate for `function` and `any`. And=20 >>> dynamic polymorphism via type-erasure *does not work*; that's why=20 >>> there's a problem to begin with. >>> >> >> I am saying that "static polymorphism *could be* appropriate for=20 >> `function` and `any`" if a concept for type-independent allocators is=20 >> introduced, and I think it should be "MemoryResource". >> > > You can think whatever you want, but we've got evidence that it doesn't= =20 > work. `std::function` used to have a constructor that took an allocator.= =20 > That was *removed* in C++17, because nobody implemented it correctly.=20 > Because nobody *could* implement it correctly.=20 > > =20 It is true that the concept Allocator is not suitable for `std::function`,= =20 which is because that Allocators are "type-specific" rather than=20 "type-erased" as they allocates memory based on the size of=20 "Allocator::value_type". However, the concept "MemoryResource" is=20 "type-erased", whose allocation behavior is based on the number of bytes,= =20 and this is the main difference from the concept "Allocator". I also oppose "MemoryResource" to be added to the constructor of a type=20 erased facility; instead, I think it would be a good idea to add it to the= =20 class template, e.g., template class function; // undefined template class function { ... }; If there are requirements in runtime polymorphism of "MemoryResource",=20 users are able to use a polymorphic wrapper instead of a concrete=20 implementation. Type-erased allocators don't work with `function`. > How did you conclude that? =20 > And there's no reason to expect that they'll work any better with `any`.= =20 > Library fundamentals v2 tries to give `function` an allocator through the= =20 > PMR system. That is, replacing type erased polymorphism with inheritance= =20 > polymorphism (sort of). > > So the only form of polymorphism that can work here is inheritance-based= =20 >>> polymorphism. >>> >>> If you have some type `allocator` that can allocate bytes, and you don'= t=20 >>>>> mind the fact that `vector` will be different from othe= r=20 >>>>> `vector` types... why would you use a `pmr::vector`? >>>>> >>>> >>>> I will only use `pmr::vector` if I have requirements on the=20 >>>> polymorphism of allocators, and this seems to have nothing to do with = what=20 >>>> I'm saying here. >>>> >>> >>> But... *you* were the one who brought up the whole PMR system. >>> =20 >>> >>>> Actually, I think this idea will help improve the usability of std::an= y=20 >>>> and other polymorphic facilities. Maybe we could have something like= =20 >>>> `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 t= he=20 >>>> motivation to define MemoryResouece as a concept is relatively enough. >>>> >>> >>> Adding static polymorphism to a type whose *whole purpose* is built=20 >>> around dynamic polymorphism (through type-erasure) makes no sense. Even= if=20 >>> we were going to do this, we'd just use the already existing Allocator= =20 >>> concept. >>> >> >> I think "polymorphic allocator" and "allocator for polymorphic types" ar= e=20 >> not same concepts. On the one hand, "polymorphic allocator" is the type= =20 >> that could have polymorphic allocation behaviour, but could also be=20 >> type-specific (Allocator::value_type), like the class template=20 >> `std::pmr::polymorphic_allocator` does. On the other hand, "allocator fo= r=20 >> polymorphic types" is the type that could be used to allocate memory for= =20 >> any type, but may not have polymorphic allocation behaviour. I think the= =20 >> semantics of "std::pmr::memory_resource" should be "allocator for=20 >> polymorphic types" instead of "polymorphic allocator", and therefore it= =20 >> shall not be polymorphic. >> > > It's that last sentence that does not follow from the rest.=20 > `pmr::memory_resource` already is an "allocator for polymorphic types". O= r=20 > perhaps a better term for it would be "raw memory allocator", while the= =20 > Allocator concept allocates *objects*. `pmr::memory_resource` has no=20 > interfaces for any particular `value_type`, nor is it required or even=20 > expected to do so. So it allocates memory and that's all. > > Whether `pmr::memory_resource` is itself polymorphic is essentially=20 > orthogonal to how it allocates memory. There's no reason you can't have a= =20 > "polymorphic allocator for polymorphic types", or with better terminology= a=20 > "polymorphic raw memory allocator". > =20 I did not deny that "polymorphic allocator for polymorphic types" is a=20 reasonable demand, and that is the reason why I suggest to turn=20 "std::pmr::memory_resource" from a "virtual base class" into a "polymorphic= =20 wrapper". The Allocator concept defines a "static object allocator" concept.=20 > `pmr::memory_resource` is a "polymorphic raw memory allocator" type. Sure= ,=20 > we could have a "static raw memory allocator" concept, but we wouldn't=20 > actually use it anywhere. And certainly not in the PMR system. > How did you conclude that "we wouldn't actually use 'static raw memory=20 allocator' anywhere"? I think the motivation for this was illustrated clear= =20 enough. =20 > `pmr::memory_resource` exists so that the PMR system can have a=20 > distinction between the allocation of raw memory and the Allocator=20 > interface to the container. It is a polymorphic base class because the *e= ntire=20 > purpose* of the PMR system is to allow the allocator used by a container= =20 > to not be a part of its type. That requires substituting static=20 > polymorphism for dynamic polymorphism. > At the beginning, I thought it would be better to define it as a standalone= =20 system (just as Jonathan M=C3=BCller did). After some research, I found tha= t it=20 has exactly the same semantics as the PMR system does, and it occurs to me= =20 that this shall be a part of the PMR system, as this will not reduce=20 neither usability nor performance comparing to the PMR system we have now.= =20 Thus, I think the PMR should do more than just "allow the allocator used by= =20 a container to not be a part of its type". =20 > The PMR Allocator type could in theory be implemented by type erasing the= =20 > `memory_resource`, but that wouldn't actually improve anything. Each call= =20 > into the allocation would still be an indirect call, whether it's through= =20 > virtual functions or the type-erasure mechanisms. > Right. I am not trying to improve performance in runtime polymorphism, but= =20 "compile-time polymorphism". =20 > And of course `is_equal` would be *impossible* to implement. > How did you conclude that? As a theoretical solution, `memory_resource` may= =20 also have member functions like`target_type` and `target` as=20 `std::function` does. You seem to have a reflexive assumption that type-erased polymorphism is=20 > superior to inheritance-based polymorphism. The reason to use type-erasur= e=20 > is if you're dealing with a case where it would be inconvenient or=20 > impossible to modify types to use inheritance. > Sometimes, it is not because "inconvenient or impossible to modify types to= =20 use inheritance", but because some types are not always necessary to be=20 polymorphic at all. =20 > `function` needs to be able to take arbitrary callables, including=20 > fundamental types like function pointers; that's the whole point of the= =20 > type. `any` needs to be able to take *anything* which is copyable,=20 > including fundamental types; that's the whole point of the type.=20 > Inheritance polymorphism is not even an option in those cases, since=20 > fundamental types are not inherited. > > This is not the case when dealing with PMR. Raw memory allocators are not= =20 > common types, so requiring you to use a virtual interface is not exactly = a=20 > heavy burden. So, what exactly is the problem with using a virtual=20 > interface? > How did you conclude that "raw memory allocators are not common types"? Why= =20 do you think "Callable" types are "common", while "MemoryResource" types=20 are not? 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/fee0a310-5dc5-4421-bf49-bc8fa164fe29%40isocpp.or= g. ------=_Part_12748_2135675636.1508087137706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, October 15, 2017 at 11:12:03 PM UTC+8, Nicol Bo= las wrote:
On = Sunday, October 15, 2017 at 12:09:40 AM UTC-4, Mingxin Wang wrote:
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, Mi= ngxin Wang wrote:
<= div>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 polymorphi= c allocators?

This proposal is = targeting at other polymorphic facilities in the standard, such as std::fun= ction, std::any, etc., because I think `memory_resource` is the facility wi= th the most appropriate semantics defined in the standard that provides an = abstraction for=C2=A0type-independent memory allocation algorithms. However= , if I were a implementator of `std::any`, I will not use it in the impleme= ntation 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= 9;t see how what you've suggested does that.

P= MR, at its core, is based on polymorphism via inheritance. That is, dynamic= polymorphism. Polymorphism based on concepts is either static polymorphism= (ie: `vector<T, someAllocatorType>`) or dynamic polymorphism via a t= ype-erased mechanism.

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

I am saying that "st= atic polymorphism could be appropriate for `function` and `any`"= ; if a concept for type-independent allocators is introduced, and I think i= t should be "MemoryResource".

You can think whatever you want, but we've got evidence that i= t doesn't work. `std::function` used to have a constructor that took an= allocator. That was removed in C++17, because nobody implemented it corre= ctly. Because nobody could implement it correctly.
=C2=A0
It is true that the concept Allocator= is not suitable for `std::function`, which is because that Allocators are = "type-specific" rather than "type-erased" as they alloc= ates memory based on the size of "Allocator::value_type". However= , the concept "MemoryResource" is "type-erased", whose = allocation behavior is based on the number of bytes, and this is the main d= ifference from the concept "Allocator".

= I also oppose "MemoryResource" to be added to the constructor of = a type erased facility; instead, I think it would be a good idea to add it = to the class template, e.g.,

templat= e <class T, class MR>
class functi= on; // undefined

template <class R, class... Args, class MR>
class function<R(Args...), MR> { ... };

If there are r= equirements in runtime polymorphism of "MemoryResource", users ar= e able to use a polymorphic wrapper instead of a concrete implementation.

Type-erased allocators don't work with `fun= ction`.

How did you conclude th= at?
=C2=A0
=
And there's no reason to expect that they'll = work any better with `any`. Library fundamentals v2 tries to give `function= ` an allocator through the PMR system. That is, replacing type erased polym= orphism with inheritance polymorphism (sort of).

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, allocator>` will be different from other `v= ector` types... why would you use a `pmr::vector<T>`?

I will only use `pmr::vector<T>` if I ha= ve requirements on the polymorphism of allocators, and this seems to have n= othing to do with what I'm saying here.
But... you were the one who brought up the whole PMR sy= stem.
=C2=A0
Actually, I think this idea will help improve the usabil= ity of std::any and other polymorphic facilities. Maybe we could have somet= hing like `template <class MR =3D ...> class any` defined in the stan= dard in the future, and users are free to specify any memory management str= ategies. Although this will require more effort to design and review, I thi= nk the motivation to define MemoryResouece as a concept is relatively enoug= h.

Adding static polymorphism t= o a type whose whole purpose is built around dynamic polymorphism (t= hrough type-erasure) makes no sense. Even if we were going to do this, we&#= 39;d just use the already existing Allocator concept.

I think "polymorphic allocator" and "= allocator for polymorphic types" are not same concepts. On the one han= d, "polymorphic allocator" is the type that could have polymorphi= c allocation behaviour, but could also be type-specific (Allocator::value_t= ype), 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 polymo= rphic allocation behaviour. I think the semantics of=C2=A0"std::pmr::m= emory_resource" should be "allocator for polymorphic types" = instead of "polymorphic allocator", and therefore it shall not be= polymorphic.

It's that las= t sentence that does not follow from the rest. `pmr::memory_resource` alrea= dy is an "allocator for polymorphic types". Or perhaps a better t= erm for it would be "raw memory allocator", while the Allocator c= oncept allocates objects. `pmr::memory_resource` has no interfaces f= or any particular `value_type`, nor is it required or even expected to do s= o. So it allocates memory and that's all.

Whet= her `pmr::memory_resource` is itself polymorphic is essentially orthogonal = to how it allocates memory. There's no reason you can't have a &quo= t;polymorphic allocator for polymorphic types", or with better termino= logy a "polymorphic raw memory allocator".
=C2=A0
I did not deny that "polymorphic allocator for= polymorphic types" is=C2=A0a reasonable demand, and that is the reaso= n why I suggest to turn "std::pmr::memory_resource" from a "= virtual base class" into a "polymorphic wrapper".
=
The Allocator concept defines a "static object allocator&= quot; concept. `pmr::memory_resource` is a "polymorphic raw memory all= ocator" type. Sure, we could have a "static raw memory allocator&= quot; concept, but we wouldn't actually use it anywhere. And certainly = not in the PMR system.

How did = you conclude that "we wouldn't actually use 'static raw memory= allocator' anywhere"? I think the motivation for this was illustr= ated clear enough.
=C2=A0
`pmr::memory_resource` exists s= o that the PMR system can have a distinction between the allocation of raw = memory and the Allocator interface to the container. It is a polymorphic ba= se class because the entire purpose of the PMR system is to allow th= e allocator used by a container to not be a part of its type. That requires= substituting static polymorphism for dynamic polymorphism.
=

At the beginning, I thought it would be be= tter to define it as a standalone system (just as Jonathan M=C3=BCller did)= .. After some research, I found that it has exactly the same semantics as th= e PMR system does, and it occurs to me that this shall be a part of the PMR= system, as this will not reduce neither usability nor performance comparin= g to the PMR system we have now. Thus, I think the PMR should do more than = just "allow the allocator used by a container to not be a part of its = type".
=C2=A0
The PMR Allocator type could in theory be imple= mented by type erasing the `memory_resource`, but that wouldn't actuall= y improve anything. Each call into the allocation would still be an indirec= t call, whether it's through virtual functions or the type-erasure mech= anisms.

Right. I am not trying = to improve performance in runtime polymorphism, but "compile-time poly= morphism".
=C2=A0
And of course `is_equal` would be impossib= le to implement.

How did yo= u conclude that? As a=C2=A0theoretical solution, `memory_resource` may also= have member functions=C2=A0 like`target_type` and `target` as `std::functi= on` does.

=
You seem to have a reflexive assumption that type-era= sed polymorphism is superior to inheritance-based polymorphism. The reason = to use type-erasure is if you're dealing with a case where it would be = inconvenient or impossible to modify types to use inheritance.
<= /blockquote>

Sometimes, it is not because "inconven= ient or impossible to modify types to use inheritance", but because so= me types are not always necessary to be polymorphic at all.
=C2= =A0
`function` needs to be able to take arbitrary callables, including fundame= ntal types like function pointers; that's the whole point of the type. = `any` needs to be able to take anything which is copyable, including= fundamental types; that's the whole point of the type. Inheritance pol= ymorphism is not even an option in those cases, since fundamental types are= not inherited.

This is not the case when dealing = with PMR. Raw memory allocators are not common types, so requiring you to u= se a virtual interface is not exactly a heavy burden. So, what exactly is t= he problem with using a virtual interface?
How did you conclude that "raw memory allocators are not c= ommon types"? Why do you think "Callable" types are "co= mmon", while "MemoryResource" types are not?

<= /div>
Mingxin 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/fee0a310-5dc5-4421-bf49-bc8fa164fe29= %40isocpp.org.
------=_Part_12748_2135675636.1508087137706-- ------=_Part_12747_138489169.1508087137706-- .