220 34960 <6d0ad98b-87d5-43dd-ac54-2b7d3e03e31b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Aleksey Loginov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea about "std::pmr::memory_resource" Date: Mon, 16 Oct 2017 03:55:41 -0700 (PDT) Lines: 240 Approved: news@gmane.org Message-ID: <6d0ad98b-87d5-43dd-ac54-2b7d3e03e31b@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> <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_7060_1982514003.1508151341153" X-Trace: blaine.gmane.org 1508151354 30224 195.159.176.226 (16 Oct 2017 10:55:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Oct 2017 10:55:54 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCGIDMXA5AJRBLNASLHQKGQEAZAZ4NI@isocpp.org Mon Oct 16 12:55:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e433Y-0005g3-4U for gclcip-std-proposals@m.gmane.org; Mon, 16 Oct 2017 12:55:36 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id c76sf5951025vkd.14 for ; Mon, 16 Oct 2017 03:55: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=eI0Bm2Q7AX3EKSp4U4mz2OYXL5eUfILeSm6xVCbCtFA=; b=QyG1Tz6X01vEmcn84psAUfKv7aso/q3jvuGgwNg+ag1Y+ORyofcFWG7TrzG330wx7f bWGwv/i3jUPa7Zy78I33ettyOOCagUY8mfmpWnRI+6QY2zAkn7dIFFofM4+Mth5mXh2R PazF4AjsbrtD/v8y+TsUoQOf9V8beaz3g+D7r4NI9LPqYO4G/4TzqOu9u6nhMEYI5Z6l 0b5TAqcXNjK5O4Ty6RBT6SauVXJYJArdbfnxw0FVF5FuemiwVKgvbRa0mlKOadJzw81Y 0ESqv4jT12wVsmGWbjTU61+kCk0NpfblVeSdViu4kEcQAEWbh62e3O9rlQKt5e2Uihly IHHQ== 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=eI0Bm2Q7AX3EKSp4U4mz2OYXL5eUfILeSm6xVCbCtFA=; b=XLn94NpIOCpbEEbDpDBWYIo8bD8+m+BWVE98SapktQhzuDzpIhNPUbkwj+Jp8dGCte HxFXJ48v2rSldDk7KYVAjCJQ9ks6b5hnPx7xPVzfrrZfbha5CW0gfbrutV5CqBU41Upo CM2SHY/aWx2vHEGUywxlfc6NOAzNh2GYSJ/pxT2HTqj7bkZMVaYjDcX40GBeF7Un9qoQ m61ZeAT3ug7tacEPGDXBipsL+jrVZVNEOwVlj6RBo369zQceUFuEMv7UpkJjDTlW6JaP 3CC2zfxd1k2U46hv9D5St/VOXNPftKV7a5u9V2o0KuoMfQ2S5JoXWCNEnEG8T8/HxCia 3kxA== 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=eI0Bm2Q7AX3EKSp4U4mz2OYXL5eUfILeSm6xVCbCtFA=; b=FFNPq23sWnVCuy8Dncu8+x8d3F5Sqm1yuMrBjGf1IZlRnfB5NcRHVQBkoysXLVp79a 8MbXfMWRfF1uHVG6i6LLoheU9yz1OKuZ0dmJk1wAfzfTFnLkypc1kJ00rSLcJEGmocAJ S4UmwGWYMvB1szkHRHd1tHJPLuAScQ40KIbufDCDMzSlOPaJpJPJiTbmTcb5IUNZjTCh 4sxjLIDCsatMowyeB9RW2oxSrZiDMcW8YvWebvHO6UXNWBVb7qheoPoqvjwmC50rGCrJ 5h+ryNFBEafEZKcuiZg/eH5Jfo74BZ7aN6zYPpCs0mkCiEndddD/OKlOqHMlmq7vfk8k QWhQ== X-Gm-Message-State: AMCzsaUd0SYbZ+9EuRocUt3NLlMuJPQdp7wsG0b/zE6P4oaI8xBVxt/p 6r/KAd9inUjA46ybsuTVq5vHuw== X-Google-Smtp-Source: AOwi7QATUGzzj/jO7rspuRO9coaShVr+NmPRV8sLytNGQ4Tk5zT1b3qQjAABlj7VUKB45mDx8ea6ng== X-Received: by 10.31.10.67 with SMTP id 64mr4836660vkk.17.1508151343370; Mon, 16 Oct 2017 03:55:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.132.145 with SMTP id g139ls1176822vkd.2.gmail; Mon, 16 Oct 2017 03:55:41 -0700 (PDT) X-Received: by 10.31.50.18 with SMTP id y18mr97539vky.6.1508151341711; Mon, 16 Oct 2017 03:55:41 -0700 (PDT) In-Reply-To: X-Original-Sender: Aleksey.Loginov@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:34960 Archived-At: ------=_Part_7060_1982514003.1508151341153 Content-Type: multipart/alternative; boundary="----=_Part_7061_333586511.1508151341153" ------=_Part_7061_333586511.1508151341153 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 16 =D0= =BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2017 =D0=B3., 13:26:09 UTC+3 =D0=BF= =D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Mingxin = Wang=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > 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 = the=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 problemat= ic. >> >> I don't disagree with the idea of having allocation control over=20 >> type-erased objects like `function`. But making it a template parameter = is=20 >> just not a good solution to this problem. `function` and `any` are=20 >> polymorphic types; invoking any of their common operations like copying = or=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= =20 > is positive for performance in large-scale programming. Providing there i= s=20 > a class template `my_any` that has the same functionality as `std::any`= =20 > does, 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=20 > example, in a high-concurrency environment, users may choose pooled memor= y=20 > as the memory resource to avoid contention: > > using pooled_any =3D my_any; > > If there is no particular consideration in performance, it is also allowe= d=20 > to use the default memory resource, e.g. `my_any<>`. > =20 Let's look at a more applied example: template=20 struct static_resource : memory_resource { aligned_storage_t m_data;= =20 }; template struct my_any; my_any x1; my_any> x2; x1 =3D 1; x2 =3D x1; assert(x2 =3D=3D 1); How can you do this without RTTI? --=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/6d0ad98b-87d5-43dd-ac54-2b7d3e03e31b%40isocpp.or= g. ------=_Part_7061_333586511.1508151341153 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C= =D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2017 =D0= =B3., 13:26:09 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82= =D0=B5=D0=BB=D1=8C Mingxin Wang =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:=
On Monday, Oc= tober 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 wr= ote:
I also oppose "MemoryResource&q= uot; to be added to the constructor of a type erased facility; instead, I t= hink it would be a good idea to add it to the class template, e.g.,

template <class T, clas= s MR>
class function; // undefined

te= mplate <class R, class... Args, class MR>
class function<= ;R(Args...), MR> { ... };


Why would we want = this? This creates interoperation difficulty, since `function<Prototype,= Allocator1>` is a different type from `function<Prototype, Allocator= 2>`. Passing them around becomes problematic.

I= don't disagree with the idea of having allocation control over type-er= ased objects like `function`. But making it a template parameter is just no= t a good solution to this problem. `function` and `any` are polymorphic typ= es; invoking any of their common operations like copying or function callin= g or value extraction requires the equivalent of virtual overhead. Consider= ing that they already have such overhead, what's wrong with having thei= r allocator have such overhead?

Adding a "MemoryResource" type to the template of a polymorphic = facility is positive for performance in large-scale programming. Providing = there is a class template `my_any` that has the same=C2=A0functionality as = `std::any` does, except that users are allowed to specify a "MemoryRes= ource" type to `my_any`:

template <= class MR =3D default_memory_resource>
class my_any;

Users are able to configure the class to optimize p= erformance. For example, in a high-concurrency environment, users may choos= e pooled memory as the memory resource to avoid contention:

<= /div>
using pooled_any =3D my_any<synchronized_= memory_resource>;

If there is no p= articular consideration in performance, it is also allowed to use the defau= lt memory resource, e.g. `my_any<>`.
=C2=A0
Let's look at a more applied example:

template<siz= e_t Size><= span style=3D"color: #000;" class=3D"styled-by-prettify">
struct static_resource : memory_resource {= aligned_storage_t<Size> m_data; };

template<typename MR>
struct=C2=A0my_any;


my_any<default_memory_resource> x= 1;
my_any<static_reso= urce<32>> x2;

x1 =3D 1;
x2 =3D x1;

assert(x2 =3D= =3D 1);


How can you=C2=A0do this without RTTI?

--
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/6d0ad98b-87d5-43dd-ac54-2b7d3e03e31b= %40isocpp.org.
------=_Part_7061_333586511.1508151341153-- ------=_Part_7060_1982514003.1508151341153-- .