220 34959 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: Mon, 16 Oct 2017 03:26:09 -0700 (PDT) Lines: 621 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> <784ffce8-ace7-449d-a13d-a99d7336117a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3579_2082079305.1508149569339" X-Trace: blaine.gmane.org 1508149580 11650 195.159.176.226 (16 Oct 2017 10:26:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Oct 2017 10:26:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBQUSSLHQKGQECDP2MMQ@isocpp.org Mon Oct 16 12:26:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e42az-0001HF-D6 for gclcip-std-proposals@m.gmane.org; Mon, 16 Oct 2017 12:26:05 +0200 Original-Received: by mail-vk0-f70.google.com with SMTP id 126sf5947097vkj.0 for ; Mon, 16 Oct 2017 03:26:13 -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=Wo7D5rbbCYI3iSg91mLl4R9R7XEnmsAIQhs+eE0QkBY=; b=MquT7R8Zrf4tl/SEmPR3P/ygUExyddlqHDqqPElcXGu1SVMFy/UgrhZ0L2rQX+zoqy /WlQCGs2Ilj5EM+y5gXVhPiTczasSu8gYKHWv1faJ4o+cRlQaaJXr8Yk36pEuo4/ea3r GOV83/M5/sp7zvKrq7FjmrlpEyQQEoSpsNLbNdf3INwExs88YiLB3Vt7wMzmDEPpfcV8 lBIgCn8P+ccgsHigi1i1mOGz/mvcYh/2aQeP73ubULorCur4pcD2eWzV2tiQdB1OT+Cd yY+5Dq678KblZphF9VluJtw3WNCQ5VtNK+mLdjurnaM1PliHaigibs8DQ1R3pOHEXSfW eWMg== 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=Wo7D5rbbCYI3iSg91mLl4R9R7XEnmsAIQhs+eE0QkBY=; b=LrdTcZA9ilLKxuAyp8sHwkm1ibV515YP/Voeai/GJoe1FidtJj03D7mKnisZD+kSTa 2cbs1LbkzbmzxbZTs2i4QRmMv2wWE+yPduhWWjvMNakJpotMx/jWh5V9+Ua9z6Wz3eIm hksXarG7pYFHrOOt1ZaxZ6fXCwJDbffs1mQkx6341HtT7+XADkXMzy3ppJuFqkt8zRVC 33SlH1ebVF1HM9Y7nv0nJRbyZaQ5pbzsmukbRo6ZxR2pLJeHUzoq+l8bBi1gKciWd5yd BBo8x7V+MYHpktp5J7OVeRvfoHRWIolvJ80zC4gF2v8mXWl+OWhXEAyyvxYmHFXDvy2O oSRg== X-Gm-Message-State: AMCzsaXhaQ16tCzJ/Bp5qH50gkuxoCghZWLqeAyifYVoPPgnwfJuYjkB tZLaYMDt4+y4xaoRRkoWZrmY1g== X-Google-Smtp-Source: AOwi7QDbm4I4HQVxoQ2B2gd2o4cJbvPRaUVk2vMwye9tX34exC88o+8CfqaWHU3k7QBFzBABLunYBQ== X-Received: by 10.31.82.195 with SMTP id g186mr4813740vkb.43.1508149571422; Mon, 16 Oct 2017 03:26:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.22.18 with SMTP id k18ls3230878uae.15.gmail; Mon, 16 Oct 2017 03:26:10 -0700 (PDT) X-Received: by 10.31.201.3 with SMTP id z3mr698700vkf.0.1508149569947; Mon, 16 Oct 2017 03:26:09 -0700 (PDT) In-Reply-To: <784ffce8-ace7-449d-a13d-a99d7336117a@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:34959 Archived-At: ------=_Part_3579_2082079305.1508149569339 Content-Type: multipart/alternative; boundary="----=_Part_3580_1561502000.1508149569339" ------=_Part_3580_1561502000.1508149569339 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, October 16, 2017 at 6:37:17 AM UTC+8, Nicol Bolas wrote: > > On Sunday, October 15, 2017 at 1:05:37 PM UTC-4, Mingxin Wang wrote: >> >> On Sunday, October 15, 2017 at 11:12:03 PM UTC+8, Nicol Bolas wrote: >> > 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 t= he=20 >> class template, e.g., >> >> template >> class function; // undefined >> >> template >> class function { ... }; >> >> > Why would we want this? This creates interoperation difficulty, since=20 > `function` is a different type from=20 > `function`. Passing them around becomes problemati= c. > > I don't disagree with the idea of having allocation control over=20 > type-erased objects like `function`. But making it a template parameter i= s=20 > just not a good solution to this problem. `function` and `any` are=20 > polymorphic types; invoking any of their common operations like copying o= r=20 > function calling or value extraction requires the equivalent of virtual= =20 > overhead. Considering that they already have such overhead, what's wrong= =20 > with having their allocator have such overhead? > Adding a "MemoryResource" type to the template of a polymorphic facility is= =20 positive for performance in large-scale programming. Providing there is a= =20 class template `my_any` that has the same functionality as `std::any` does,= =20 except that users are allowed to specify a "MemoryResource" type to=20 `my_any`: template class my_any; Users are able to configure the class to optimize performance. For example,= =20 in a high-concurrency environment, users may choose pooled memory as the=20 memory resource to avoid contention: using pooled_any =3D my_any; If there is no particular consideration in performance, it is also allowed= =20 to use the default memory resource, e.g. `my_any<>`. =20 > 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? >> > > Because the C++ standards committee removed it. If it were workable, then= =20 > they probably would have just made it work. > It is true that the committee removed it from the template of the=20 constructor, but it was never added to the template of the class, not to=20 mention removing it. =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 t= he=20 >>> PMR system. That is, replacing type erased polymorphism with inheritanc= e=20 >>> polymorphism (sort of). >>> >>> So the only form of polymorphism that can work here is inheritance-base= d=20 >>>>> polymorphism. >>>>> >>>>> If you have some type `allocator` that can allocate bytes, and you=20 >>>>>>> don't mind the fact that `vector` will be different f= rom=20 >>>>>>> other `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 wit= h 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=20 >>>>>> std::any and other polymorphic facilities. Maybe we could have somet= hing=20 >>>>>> like `template class any` defined in the standard= in the=20 >>>>>> future, and users are free to specify any memory management strategi= es.=20 >>>>>> Although this will require more effort to design and review, I think= the=20 >>>>>> motivation to define MemoryResouece as a concept is relatively enoug= h. >>>>>> >>>>> >>>>> Adding static polymorphism to a type whose *whole purpose* is built= =20 >>>>> around dynamic polymorphism (through type-erasure) makes no sense. Ev= en if=20 >>>>> we were going to do this, we'd just use the already existing Allocato= r=20 >>>>> concept. >>>>> >>>> >>>> I think "polymorphic allocator" and "allocator for polymorphic types"= =20 >>>> are 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 = for=20 >>>> polymorphic types" is the type that could be used to allocate memory f= or=20 >>>> any type, but may not have polymorphic allocation behaviour. I think t= he=20 >>>> semantics of "std::pmr::memory_resource" should be "allocator for=20 >>>> polymorphic types" instead of "polymorphic allocator", and therefore i= t=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".= Or=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 terminolo= gy 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 "polymorp= hic=20 >> wrapper". >> > > As a base class, it's *already* a "polymorphic allocator for polymorphic= =20 > types", by your terminology. So turning it into some type-erased wrapper= =20 > accomplishes nothing. > We could use it in allocators and polymorphic facilities, and we are able= =20 to configure whether the memory resource should be polymorphic. If there is no particular demand in "std::pmr::memory_resource", I have no= =20 objection to removing it, because it is easily implementable with "the prox= y=20 "=20 (I am still working on that proposal). =20 > The Allocator concept defines a "static object allocator" concept.=20 >>> `pmr::memory_resource` is a "polymorphic raw memory allocator" type. Su= re,=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 cl= ear=20 >> enough. >> > > Where would we use it? It's not an Allocator, so it can't be used in any= =20 > containers. It's not polymorphic, so we can't use it in `function` or `an= y`=20 > without suffering the problems of providing the type as a template=20 > parameter. And using it in PMR makes no sense, since we already have a=20 > perfectly functional PMR system that works polymorphically; it just uses = a=20 > base class rather than type-erasure. > > So where exactly would we use it? > We could use it in allocators and polymorphic facilities. =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 = *entire=20 >>> purpose* of the PMR system is to allow the allocator used by a=20 >>> container to not be a part of its type. That requires substituting stat= ic=20 >>> polymorphism for dynamic polymorphism. >>> >> >> At the beginning, I thought it would be better to define it as a=20 >> standalone system (just as Jonathan M=C3=BCller did). After some researc= h, I=20 >> found that it has exactly the same semantics as the PMR system does, and= it=20 >> occurs to me that this shall be a part of the PMR system, as this will n= ot=20 >> reduce neither usability nor performance comparing to the PMR system we= =20 >> have now. Thus, I think the PMR should do more than just "allow the=20 >> allocator used by a container to not be a part of its type". >> > > But that's all we want from PMR. > > The PMR Allocator type could in theory be implemented by type erasing the= =20 >>> `memory_resource`, but that wouldn't actually improve anything. Each ca= ll=20 >>> into the allocation would still be an indirect call, whether it's throu= gh=20 >>> virtual functions or the type-erasure mechanisms. >>> >> >> Right. I am not trying to improve performance in runtime polymorphism,= =20 >> but "compile-time polymorphism". >> > And of course `is_equal` would be *impossible* to implement. >>> >> >> How did you conclude that? As a theoretical solution, `memory_resource`= =20 >> may also have member functions like`target_type` and `target` as=20 >> `std::function` does. >> > > `function::target_type` returns a `std::type_info`. The only way to get= =20 > such a thing is via `typeid`. Which uses RTTI. Which is *exactly* what=20 > you castigate `is_equal` for using. Same goes for `function::target`; the= y=20 > both rely on RTTI. > > So again, you have gained nothing over the base class interface. > > You seem to have a reflexive assumption that type-erased polymorphism is= =20 >>> superior to inheritance-based polymorphism. The reason to use type-eras= ure=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= =20 >> to 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= =20 >>> not common types, so requiring you to use a virtual interface is not=20 >>> exactly a heavy burden. So, what exactly is the problem with using a=20 >>> virtual interface? >>> >> >> How did you conclude that "raw memory allocators are not common types"?= =20 >> Why do you think "Callable" types are "common", while "MemoryResource"= =20 >> types are not? >> > > Well, which does the average program have more of: different types of=20 > memory allocators, or different types of *function signatures*? Clearly,= =20 > one is more common than the other. And you certainly have more copyable= =20 > types than you do allocators. > It just provides some significative options. If there is little particular= =20 considerations, using default configurations is the same as befure. =20 > Allocators are special-case tools. That doesn't make them unimportant. Bu= t=20 > having to write a wrapper or whatever to translate its interface is not a= =20 > significant burden. Compare that to having to write one for every functio= n=20 > pointer or copyable fundamental type. > --=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/d029c18a-12ee-4a7d-828c-ab1bd07b58c6%40isocpp.or= g. ------=_Part_3580_1561502000.1508149569339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, October 16, 2017 at 6:37:17 AM UTC+8, Nicol Bol= as wrote:
On S= unday, October 15, 2017 at 1:05:37 PM UTC-4, Mingxin Wang wrote:
On Sunday, October 15, 2017 a= t 11:12:03 PM UTC+8, Nicol Bolas wrote:
I a= lso oppose "MemoryResource" to be added to the constructor of a t= ype erased facility; instead, I think it would be a good idea to add it to = the class template, e.g.,

template <class T, class MR>
class function; // unde= fined

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

=
Why would we want this? This creates interoperation difficul= ty, since `function<Prototype, Allocator1>` is a different type from = `function<Prototype, Allocator2>`. Passing them around becomes proble= matic.

I don't disagree with the idea of havin= g allocation control over type-erased objects like `function`. But making i= t a template parameter is just not a good solution to this problem. `functi= on` and `any` are polymorphic types; invoking any of their common operation= s like copying or function calling or value extraction requires the equival= ent of virtual overhead. Considering that they already have such overhead, = what's wrong with having their allocator have such overhead?

Adding a "MemoryResource" type = to the template of a polymorphic facility is positive for performance in la= rge-scale programming. Providing there is a class template `my_any` that ha= s the same=C2=A0functionality as `std::any` does, except that users are all= owed to specify a "MemoryResource" type to `my_any`:
template <class MR =3D default_memory_resource>
class my_any;

Users a= re able to configure the class to optimize performance. For example, in a h= igh-concurrency environment, users may choose pooled memory as the memory r= esource to avoid contention:

using pooled_any =3D my_any<synchronized_memory_resource>;

If there is no particular consideration in p= erformance, it is also allowed to use the default memory resource, e.g. `my= _any<>`.
=C2=A0
If there are requirements in runtime= polymorphism of "MemoryResource", users are able to use a polymo= rphic wrapper instead of a concrete implementation.

Type-erased allocators don't work with `function`.

How did you conclude that?

Because the C++ standards committee removed it. If= it were workable, then they probably would have just made it work.

It is true that the committee removed = it from the template of the constructor, but it was never added to the temp= late of the class,=C2=A0not to mention removing it.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
And there= 9;s no reason to expect that they'll work any better with `any`. Librar= y fundamentals v2 tries to give `function` an allocator through the PMR sys= tem. That is, replacing type erased polymorphism with inheritance polymorph= ism (sort of).

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

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

I wil= l only use `pmr::vector<T>` if I have requirements on the polymorphis= m of allocators, and this seems to have nothing to do with what I'm say= ing here.

But... you wer= e the one who brought up the whole PMR system.
=C2=A0
Actually, I thi= nk this idea will help improve the usability of std::any and other polymorp= hic facilities. 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 requi= re more effort to design and review, I think the motivation to define Memor= yResouece as a concept is relatively enough.
<= br>
Adding static polymorphism to a type whose whole purpose is built around dynamic polymorphism (through type-erasure) makes no sen= se. Even if we were going to do this, we'd just use the already existin= g Allocator concept.

I think &q= uot;polymorphic allocator" and "allocator for polymorphic types&q= uot; are not same concepts. On the one hand, "polymorphic allocator&qu= ot; is the type that could have polymorphic allocation behaviour, but could= also be type-specific (Allocator::value_type), like the class template `st= d::pmr::polymorphic_allocator` does. On the other hand, "allocato= r for polymorphic types" is the type that could be used to allocate me= mory for any type, but may not have polymorphic allocation behaviour. I thi= nk the semantics of=C2=A0"std::pmr::memory_resource" should be &q= uot;allocator for polymorphic types" instead of "polymorphic allo= cator", and therefore it shall not be polymorphic.

It's that last sentence that does not follow f= rom the rest. `pmr::memory_resource` already is an "allocator for poly= morphic types". Or perhaps a better term for it would be "raw mem= ory allocator", while the Allocator concept allocates objects. = `pmr::memory_resource` has no interfaces for any particular `value_type`, n= or is it required or even expected to do so. So it allocates memory and tha= t's all.

Whether `pmr::memory_resource` is its= elf polymorphic is essentially orthogonal to how it allocates memory. There= 's no reason you can't have a "polymorphic allocator for polym= orphic types", or with better terminology a "polymorphic raw memo= ry allocator".
=C2=A0
I did not= deny that "polymorphic allocator for polymorphic types" is=C2=A0= a reasonable demand, and that is the reason why I suggest to turn "std= ::pmr::memory_resource" from a "virtual base class" into a &= quot;polymorphic wrapper".

As a base class, it's already a "polymorphic allocator for= polymorphic types", by your terminology. So turning it into some type= -erased wrapper accomplishes nothing.

We could use it in allocators and polymorphic facilities, and we are= able to configure whether the memory resource should be polymorphic.

If there is no particular demand in "std::pmr:= :memory_resource", I have no objection to removing it, because it is e= asily implementable with "the proxy" (I am st= ill working on that proposal).
=C2=A0
The Allocator concept defines a &= quot;static object allocator" concept. `pmr::memory_resource` is a &qu= ot;polymorphic raw memory allocator" type. Sure, we could have a "= ;static raw memory allocator" concept, but we wouldn't actually us= e it anywhere. And certainly not in the PMR system.

How did you conclude that "we wouldn't actual= ly use 'static raw memory allocator' anywhere"? I think the mo= tivation for this was illustrated clear enough.

Where would we use it? It's not an Allocator, so it ca= n't be used in any containers. It's not polymorphic, so we can'= t use it in `function` or `any` without suffering the problems of providing= the type as a template parameter. And using it in PMR makes no sense, sinc= e we already have a perfectly functional PMR system that works polymorphica= lly; it just uses a base class rather than type-erasure.

=
So where exactly would we use it?
<= br>
We could use it in allocators and polymorphic facilities.
=C2=A0
<= div>
`pmr::memory_resource` exists so that the PMR system can have a dis= tinction between the allocation of raw memory and the Allocator interface t= o the container. It is a polymorphic base class because the entire purpo= se of the PMR system is to allow the allocator used by a container to n= ot be a part of its type. That requires substituting static polymorphism fo= r dynamic polymorphism.

At = the beginning, I thought it would be better to define it as a standalone sy= stem (just as Jonathan M=C3=BCller did). After some research, I found that = it has exactly the same semantics as the PMR system does, and it occurs to = me that this shall be a part of the PMR system, as this will not reduce nei= ther usability nor performance comparing to the PMR system we have now. Thu= s, I think the PMR should do more than just "allow the allocator used = by a container to not be a part of its type".
=

But that's all we want from PMR.

=
<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
The PMR Alloca= tor type could in theory be implemented by type erasing the `memory_resourc= e`, but that wouldn't actually improve anything. Each call into the all= ocation would still be an indirect call, whether it's through virtual f= unctions or the type-erasure mechanisms.

<= /div>
Right. I am not trying to improve performance in runtime polymorp= hism, but "compile-time polymorphism".
And of cour= se `is_equal` would be impossible to implement.

How did you conclude that? As a=C2=A0theoretical so= lution, `memory_resource` may also have member functions=C2=A0 like`target_= type` and `target` as `std::function` does.
`function::target_type` returns a `std::type_info`. The only w= ay to get such a thing is via `typeid`. Which uses RTTI. Which is exactl= y what you castigate `is_equal` for using. Same goes for `function::tar= get`; they both rely on RTTI.

So again, you ha= ve gained nothing over the base class interface.

You seem to have a ref= lexive assumption that type-erased 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 t= o use inheritance.

Sometimes, i= t is not because "inconvenient or impossible to modify types to use in= heritance", but because some types are not always necessary to be poly= morphic at all.
=C2=A0
`function` needs to be able to take arbitrary call= ables, including fundamental types like function pointers; that's the w= hole point of the type. `any` needs to be able to take anything whic= h is copyable, including fundamental types; that's the whole point of t= he type. Inheritance polymorphism is not even an option in those cases, sin= ce fundamental types are not inherited.

This is no= t the case when dealing with PMR. Raw memory allocators are not common type= s, so requiring you to use a virtual interface is not exactly a heavy burde= n. So, what exactly is the problem with using a virtual interface?

How did you conclude that "raw mem= ory allocators are not common types"? Why do you think "Callable&= quot; types are "common", while "MemoryResource" types = are not?

Well, which does the a= verage program have more of: different types of memory allocators, or diffe= rent types of function signatures? Clearly, one is more common than = the other. And you certainly have more copyable types than you do allocator= s.

It just provides some signif= icative options. If there is little particular considerations, using defaul= t configurations is the same as befure.
=C2=A0
Allocators are specia= l-case tools. That doesn't make them unimportant. But having to write a= wrapper or whatever to translate its interface is not a significant burden= .. Compare that to having to write one for every function pointer or copyabl= e fundamental type.

--
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/d029c18a-12ee-4a7d-828c-ab1bd07b58c6= %40isocpp.org.
------=_Part_3580_1561502000.1508149569339-- ------=_Part_3579_2082079305.1508149569339-- .