220 34884 <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Idea about "std::pmr::memory_resource" Date: Sat, 14 Oct 2017 01:14:56 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: <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_1577_1966491701.1507968896664" X-Trace: blaine.gmane.org 1507968910 18130 195.159.176.226 (14 Oct 2017 08:15:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 08:15:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBAMPQ7HQKGQEVMAKSWQ@isocpp.org Sat Oct 14 10:15:02 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 1e3Has-0002Lk-Ra for gclcip-std-proposals@m.gmane.org; Sat, 14 Oct 2017 10:14:50 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id q13sf4039915vkb.16 for ; Sat, 14 Oct 2017 01:14:58 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=n6zC6gVNh8K70GQqZDHusPUKeLcU53zH9Iwr1Ahon88=; b=rty9dmNzK6Pn8UsgT4a7oSIOF+SBqXRVuBIwuEDG9dL7wDNPohW3unVXTyA+h3y8xt syOfTZ9q/AHsHKTAnvdxF1n9ublZUcFJs0v2fqKFUiORQeJSuYWu42Mcqsa4LB5W2LN0 w+KVis0y4zmsAK+tXc7aXD4kM5WO0zNXfLGa7ZxzpKFJVQntGg4uFwzihP2t/GPA1G83 6oeL2eIjGwBtYitghfM5nX4b0f4PVnnWT4LdDHEe85/Sr111xf3r5yGr9quHpriD58jx vTuFySldOigfseuJmY2nb4IlCx8rrKaUD4rpz9mzJc07hs6WKXh7X1JmZawCv685mNVb GDWQ== 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: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=n6zC6gVNh8K70GQqZDHusPUKeLcU53zH9Iwr1Ahon88=; b=CECX2HQOR514/GaMbUNefN5LcAQAGg1xkAr7U3hssiDdp3tSr1wYQ45TP64sGQZQzY ItTHC5TybdBiNzwk/jqszev/vs3ERdoGAEl4BvAGLxfyOZOq7P+53LFkbSb/VuttyHEH IoizgEyhPW+TnCZ90vKVffaPDA4mXotz1VMfJVzFuca3DL8lVTe+XfsxdPG6F8zlPaeK t0v+q4dz9PEXSoNnnGNAs6Hmjw8dn6nKyeH6ssZG3ExQNnil915gR3HIFjPp74ybVIwl LsoVCytd+7nl6gV0UMAeoNJRllJ0kx3UioHN7d93bssOG2ris8HAz0XeDtLTMUrOFwbz HiQQ== X-Gm-Message-State: AMCzsaVC7e+b9KR1D/BPzrcc4Z6iid1YD2c7hUvyN6m5/OUgo70e0AqZ lgj8szxIgMf4vKfDWZWoOggvNQ== X-Google-Smtp-Source: AOwi7QCGL+SlhsHb5nvZb96lQuy/H6yvKd87QwC7w0p2UTj3An04sULe7cXBTTFukCcGKQnmmD4gfA== X-Received: by 10.31.64.131 with SMTP id n125mr1885458vka.12.1507968898283; Sat, 14 Oct 2017 01:14:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.157.23 with SMTP id g23ls2182047vke.4.gmail; Sat, 14 Oct 2017 01:14:57 -0700 (PDT) X-Received: by 10.31.7.137 with SMTP id 131mr247454vkh.5.1507968897044; Sat, 14 Oct 2017 01:14:57 -0700 (PDT) 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:34884 Archived-At: ------=_Part_1577_1966491701.1507968896664 Content-Type: multipart/alternative; boundary="----=_Part_1578_259871522.1507968896664" ------=_Part_1578_259871522.1507968896664 Content-Type: text/plain; charset="UTF-8" I think `std::pmr::memory_resource` is very useful in polymorphic programming. However, the design of `std::pmr::memory_resource` seems not to be reasonable enough, because: 1. it could not be efficient enough in 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 constructible from any concrete memory resource, like `std::function` could be constructible from callable types, so that the issues above could be handled. Specifically, in order to define a "concrete memory resource", I suggest to add the following concept: A type MR meets the MemoryResource requirements if the following expressions are well-formed and have the specified semantics (mr denotes a value of type MR). mr.allocate(bytes, alignment) Requires: The types of `bytes` and `alignment` are both `std::size_t`. Returns: A pointer to allocated storage with a size of at least `bytes`. The returned storage is aligned to the specified `alignment`, if such alignment is supported; otherwise it is aligned to `max_align`. Throws: Appropriate exception if it is unable to allocate memory with the requested size and alignment. mr.deallocate(p, bytes, alignment) Requires: The type of `p` is `void*`, the type of `bytes` and `alignment` are both `std::size_t`; `p` shall have been returned from a prior call to `allocate(bytes, alignment)` on a memory resource equal to `*this`, and the storage at `p` shall not yet have been deallocated. Effects: Dispose of allocated storage. Throws: Nothing. Together with corresponding type traits: template struct is_memory_resource; template inline constexpr bool is_memory_resource_v = is_memory_resource::value; I am looking forward to your comments and suggestions! 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/0a8293b4-3246-47a5-9881-bc1ca4b91772%40isocpp.org. ------=_Part_1578_259871522.1507968896664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think `std::pmr::memory_resource` is very useful in= polymorphic programming. However, the design of `std::pmr::memory_resource= ` seems not to be reasonable enough, because:
1. it could not be = efficient enough in 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 implement= able without RTTI.

I think it is more reasonable t= o make `std::pmr::memory_resource` a "polymorphic wrapper" that c= ould be constructible from any concrete memory resource, like `std::functio= n` could be constructible from callable types, so that the issues above cou= ld be handled.

Specifically, in order to define a = "concrete memory resource", I suggest to add the following concep= t:

A type MR meets the MemoryResource requirements= if the following expressions are well-formed and have the specified semant= ics (mr denotes a value of type MR).

mr.allocate(b= ytes, alignment)
=C2=A0 Requires: The types of `bytes` and `align= ment` are both `std::size_t`.
=C2=A0 Returns: A pointer to alloca= ted storage with a size of at least `bytes`. The returned storage is aligne= d to the specified `alignment`, if such alignment is supported; otherwise i= t is aligned to `max_align`.
=C2=A0 Throws: Appropriate exception= if it is unable to allocate memory with the requested size and alignment.<= /div>

mr.deallocate(p, bytes, alignment)
=C2= =A0 Requires: The type of `p` is `void*`, the type of `bytes` and `alignmen= t` are both `std::size_t`; `p` shall have been returned from a prior call t= o `allocate(bytes, alignment)` on a memory resource equal to `*this`, and t= he storage at `p` shall not yet have been deallocated.
=C2=A0 Eff= ects: Dispose of allocated storage.
=C2=A0 Throws: Nothing.
=

Together with corresponding type traits:

=
templ= ate <class T>
struct is_memory_res= ource;

template <class T>
inline c= onstexpr bool is_memory_resource_v =3D is_memory_resource<T>::value;<= /div>

I am looking forward to your = comments and suggestions!

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/0a8293b4-3246-47a5-9881-bc1ca4b91772= %40isocpp.org.
------=_Part_1578_259871522.1507968896664-- ------=_Part_1577_1966491701.1507968896664-- .