220 34953 <16a45cfa-8016-4f9d-8d6c-48d1e73c4874@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea about "std::pmr::memory_resource" Date: Sun, 15 Oct 2017 15:04:26 -0700 (PDT) Lines: 110 Approved: news@gmane.org Message-ID: <16a45cfa-8016-4f9d-8d6c-48d1e73c4874@isocpp.org> References: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5080_1650084094.1508105066370" X-Trace: blaine.gmane.org 1508105071 17706 195.159.176.226 (15 Oct 2017 22:04:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 22:04:31 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIOXNUPZ4CRUBHO67OZU@isocpp.org Mon Oct 16 00:04:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3r1B-0003Tm-89 for gclcip-std-proposals@m.gmane.org; Mon, 16 Oct 2017 00:04:21 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id u13sf6992100uaf.9 for ; Sun, 15 Oct 2017 15:04:28 -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=wQvwb2tjRxHkO9PM4CZjMr6hj8z0ZxRPCrHjgUsYIfk=; b=MMWkWeOmdIqS2TNtE8VYzE+H4ZvlFZgTMajo8d+SZIh16Gy/YcDvzOpJjBK8ncMNoA u+ln/LsiXQXmmW+GjqaKy+YJr5vexPSXuwQvQ6R3Nc3nYH4br/ckNyMmy+3owRd/r97F OjFs0ipCetOkIL2xCV3nU9y+1i90D3nnF0iT04g1lB50g+bs9ZyBi2687JVBWkpibjWF V93N5ed3V+0UeWsttu93ZhjgCLVSapXSjwlgb+4EHjH3PGVy/tpyf7eCVYCCWFZAXLzQ 9i4m0K2eIBuSuzV6HkjrlwjsKJG0uInU11YtqcWl7ui76sTqtnoTqwHdZarT5eIFq1HY QuWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=wQvwb2tjRxHkO9PM4CZjMr6hj8z0ZxRPCrHjgUsYIfk=; b=hLwUHb1EISZAhHSPGA7vIzR/MkZhR9lAg1OMdxAMiv570LHEl1NH9Ib4WSWgtSQ0c3 J6Ys6WMMMwPJDwe0MLi0YNOkLTMIAfO2VHoWg8S3IwTuZwHrZ7dbBWzpnppDlGCXZkfu pelpI5ktVdfIKASFbGu3ql/i2h/5EA+Z45XqQfZEQjn1TCdH54iTw8aqWtirygBjg8z2 mIXAvJjtdDdFeFNTpKBTaX/+mIHRJJWja5nZNQOAF8Z9ajPC8uYPjimA+OXAQb1UsfP1 OzB6GEDuH+HqEmeEnFcOSJI6vxjLHtOHQ0Jrcn0NG7buTzv/09Wt186DZqOT5oSn+Ys/ qWUg== 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=wQvwb2tjRxHkO9PM4CZjMr6hj8z0ZxRPCrHjgUsYIfk=; b=JadHoZlSFo/rX5Lwljo1h33EOsaymjWxq4e7VTPQ1JUHJKKYzLdzxS3P0TCeBNbvk5 0T+1XajfweHarYqk4InV6OGQpI8xAnnsTdrBeW34fsju25z0dBBk7Y97VU4aC+WWK64g 3pZ8J+C45fRWiSTNC9OZvyN0t0IbhVYtM6Y4fvr95DGNAI47slCxSDu4yYKSwY4Hn7z2 g383Ll9IYv/jhRx06SHjBu+50C9F/qmHGVcE9i+30LUm9FJjLZ7GRB7H7CzksMgDLmG2 qU+z0DlqoNccFD7OURqutySQAm8zhXKkEzUt4GaoF6fIBOA6FBvSWy7UL2t6XywmTuAw TY/A== X-Gm-Message-State: AMCzsaVXPHKuxpCAu4/O9rY38jWmtgalbLMdg6KIOMs/FTr7OLsv9KHV JUN6xKWxxGMs8cFdSXzt9Ndaig== X-Google-Smtp-Source: AOwi7QBBNczSE8/rWTvQ5bz2tJLGDYrifLSlRlNgqscIRsG7gRGepDtYpXrQpdO8TWrrLlHCpTVtkg== X-Received: by 10.176.4.196 with SMTP id 62mr4444687uaw.28.1508105068324; Sun, 15 Oct 2017 15:04:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.138.69 with SMTP id m66ls2923007vkd.15.gmail; Sun, 15 Oct 2017 15:04:26 -0700 (PDT) X-Received: by 10.31.189.202 with SMTP id n193mr172981vkf.5.1508105066812; Sun, 15 Oct 2017 15:04:26 -0700 (PDT) In-Reply-To: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.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:34953 Archived-At: ------=_Part_5080_1650084094.1508105066370 Content-Type: multipart/alternative; boundary="----=_Part_5081_991707903.1508105066370" ------=_Part_5081_991707903.1508105066370 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, October 14, 2017 at 1:14:56 AM UTC-7, Mingxin Wang wrote: > > I think `std::pmr::memory_resource` is very useful in polymorphic=20 > programming. However, the design of `std::pmr::memory_resource` seems not= =20 > to be reasonable enough, because: > 1. it could not be efficient enough in some cases where there is no deman= d=20 > for polymorphism in memory allocation, and > 2. it could not be efficient enough when calling the member function=20 > `is_equal`, as the function seems not implementable without RTTI. > > I think it is more reasonable to make `std::pmr::memory_resource` a=20 > "polymorphic wrapper" that could be constructible from any concrete memor= y=20 > resource, like `std::function` could be constructible from callable types= ,=20 > so that the issues above could be handled. > What you are describing has already been implemented (and proposed, AFAIK).= =20 It is an excellent idea. I don't know why it didn't get into C++17 along=20 with all the other pieces of PMR that did. http://en.cppreference.com/w/cpp/experimental/resource_adaptor However, PMR will never be all things to all people. You should certainly= =20 read my paper P0773R0 "Towards Meaningful Fancy Pointers"=20 in the upcoming=20 pre-Albuquerque mailing; it will clarify your thinking about "what is an=20 allocator" and especially "what does allocator equality mean"; and it will= =20 make you much more pessimistic about the chances of shoehorning the full=20 C++11 allocator model (including fancy pointer types) into type-erased=20 things like polymorphic_allocator, function, and any. =E2=80=93Arthur --=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/16a45cfa-8016-4f9d-8d6c-48d1e73c4874%40isocpp.or= g. ------=_Part_5081_991707903.1508105066370 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, October 14, 2017 at 1:14:56 AM UTC-7, Mingxin= Wang wrote:
<= div>I think `std::pmr::memory_resource` is very useful in polymorphic progr= amming. However, the design of `std::pmr::memory_resource` seems not to be = reasonable enough, because:
1. it could not be efficient enough i= n some cases where there is no demand for polymorphism in memory allocation= , and
2. it could not be efficient enough when calling the member= function `is_equal`, as the function seems not implementable without RTTI.=

I think it is more reasonable to make `std::pmr::= memory_resource` a "polymorphic wrapper" that could be constructi= ble from any concrete memory resource, like `std::function` could be constr= uctible from callable types, so that the issues above could be handled.

What you are describing has alread= y been implemented (and proposed, AFAIK). It is an excellent idea. I don= 9;t know why it didn't get into C++17 along with all the other pieces o= f PMR that did.

However, PMR will never be all t= hings to all people. You should certainly read my paper P0773R0 "Towards Meani= ngful Fancy Pointers" in the upcoming pre-Albuquerque mailing; it = will clarify your thinking about "what is an allocator" and espec= ially "what does allocator equality mean"; and it will make you m= uch more pessimistic about the chances of shoehorning the full C++11 alloca= tor model (including fancy pointer types) into type-erased things like poly= morphic_allocator, function, and any.

=E2=80=93Art= hur

--
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/16a45cfa-8016-4f9d-8d6c-48d1e73c4874= %40isocpp.org.
------=_Part_5081_991707903.1508105066370-- ------=_Part_5080_1650084094.1508105066370-- .