220 34977 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: Tue, 17 Oct 2017 00:16:09 -0700 (PDT) Lines: 136 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> <6d0ad98b-87d5-43dd-ac54-2b7d3e03e31b@isocpp.org> <4af80cf7-244c-4137-9133-1a36a209e4ca@isocpp.org> <7f22751b-91d1-4de4-81d2-421046ceb963@isocpp.org> <68690e5c-f466-4fbe-ab41-80be58257259@isocpp.org> <664105b3-ea68-4565-8017-a4893f4b38bf@isocpp.org> <551eb493-f49d-412d-98d2-9a5d96f68104@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_17202_1913463855.1508224569949" X-Trace: blaine.gmane.org 1508224571 2769 195.159.176.226 (17 Oct 2017 07:16:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 07:16:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBOW4S3HQKGQE5ZSWYFY@isocpp.org Tue Oct 17 09:16:06 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 1e4M6f-00007Y-0v for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 09:16:05 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id d45sf433182uag.21 for ; Tue, 17 Oct 2017 00:16:12 -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=mx5QTXLiD+DCl/LYExF/5OsJ2Fezq21im2rp8gkc5Qo=; b=A0F9ymWJ7Cj5wcYoQi/jScFaAmCzFfq73u+VsoS6Ldu6iQZKVjKmQ6JeJ7sfJIODk4 ZGZpecHXVkifdXp7s5i1fbOx3cu+52y/Sd9cE+3S9B1NFztHsX2rLIBxJvL8LCf6DTpy jWDV/u93gkQUr1OCXLpQQheu6Lbe0abAEj12+40BkWeu5epp6OboXx1PK/zlQ5ErjC4s N1k2uomSNH3OUFWszwB2xbmBGck0aVp2joXt+o79IU2+tUk7L450zHYiBqoc/UvNdijb FNNwpUqvTYNkW7LjdbayiIkxCK8K0qh0CHTkToPNxSmXd/6lQnvSrZmUGtzwCRKAb1oG Zobw== 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=mx5QTXLiD+DCl/LYExF/5OsJ2Fezq21im2rp8gkc5Qo=; b=d0XggSnz57qdxlMjgkv5fxASZrDP7SCsW+TfHGFyrAaIlViFzRcmvJA00/OGMMTAQ7 DUw3XsWteAkW5vjp0qE4Zkij6Z1YU4CU9P7PnlvIshOb6qIO+qFGix6e9mY43bdiWJgw WV6EuIbxEZeTy1p8kSi98PD05N12kbylOoW+56elobcDaxeQPUZlffHnhXw4jHD2CUDl 15y72BjMpWArYQzk3054j/TJHc53/utL2ylGpl9xhNTwe/w6Tz5DBOwKWm55Nze59npZ 4YV82OWA4v/A4jyqGojAVgw6+HY990voaeu7ltOlBPA9Aason4Q0epzf7fTVLdr9ULsm fxgQ== X-Gm-Message-State: AMCzsaVtajrmUgMv2jklNgwjHQt8n1KVNh4nlkDRfFtoMC9qfwwg3jwf tFAsPqupefn/yEXFx2k24u5MLQ== X-Google-Smtp-Source: AOwi7QDfdWP0L17PjD4RJsZQTATQCpzvvkIm6zmZLFj91rYSs1Tqj9xYgkvakaC6fRWLNeK+Njul+A== X-Received: by 10.176.74.144 with SMTP id s16mr6361476uae.16.1508224571972; Tue, 17 Oct 2017 00:16:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.73.174 with SMTP id e43ls172206uad.21.gmail; Tue, 17 Oct 2017 00:16:10 -0700 (PDT) X-Received: by 10.31.153.21 with SMTP id b21mr925026vke.13.1508224570564; Tue, 17 Oct 2017 00:16:10 -0700 (PDT) In-Reply-To: <551eb493-f49d-412d-98d2-9a5d96f68104@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:34977 Archived-At: ------=_Part_17202_1913463855.1508224569949 Content-Type: multipart/alternative; boundary="----=_Part_17203_341371608.1508224569949" ------=_Part_17203_341371608.1508224569949 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, October 17, 2017 at 2:22:07 PM UTC+8, Aleksey Loginov wrote: > > =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 17 =D0=BE=D0=BA=D1=82=D1=8F= =D0=B1=D1=80=D1=8F 2017 =D0=B3., 4:29:15 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 Tuesday, October 17, 2017 at 1:39:33 AM UTC+8, Aleksey Loginov wrote: >>> >>> In other words, by hand-made RTTI, and only for fixed allocation=20 >>> starategies (for example, data_ can not be a shared_ptr or cow_ptr) >>> >> >> There is NO RTTI in the implementation of "operator=3D". This operation = is=20 >> done via indirect function calls, and it is as efficient as most=20 >> implementations of `std::any` from various vendors. >> >> `data_` is actually implementation detail, I don't know about your=20 >> motivation that it should be shared_ptr or cow_ptr. >> >> Mingxin Wang >> > > You are just simulate RTTI via function pointers and meta-type pointer (c= onst=20 > manager_t*). > > Motivation is simple: do not copy big data, when it's not needed. Passing= =20 > policy in constructor like in_place_type_t can do the job. > =20 You are right about the demand in different lifetime management strategies.= =20 Unfortunately, `std::any` and `std::function` do no support customization= =20 in this aspect. For this reason, I designed things like `SharedWrapper`,=20 `DeepWrapper` and `DefferedWrapper` in my polymorphism support system ("The= =20 Proxies - A Language Feature Decoupling Implementations from Requirements= =20 of Polymorphism", proposal is still in process). However, I do not agree with the idea that we should "pass different=20 policies to the constructors" to choose proper lifetime management=20 strategy, because such strategy should be a property that associated with= =20 each wrapper, and therefore I tend to define polymorphic wrappers=20 associating with different lifetime management strategies as different=20 types. 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/e96fb60b-e69a-4ae6-a2c4-f3d33e88166b%40isocpp.or= g. ------=_Part_17203_341371608.1508224569949 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, October 17, 2017 at 2:22:07 PM UTC+8, Aleksey = Loginov wrote:
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 17 =D0=BE=D0=BA=D1=82=D1=8F=D0= =B1=D1=80=D1=8F 2017 =D0=B3., 4:29:15 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 Tuesday, October 17, 2017 at 1:39:33 AM UTC+8, Aleksey Loginov = wrote:
In othe= r words, by hand-made RTTI, and only for fixed allocation starategies (for = example, data_ can not be a shared_ptr<T> or cow_ptr<T>)
<= /div>

There is NO RTTI in the implementatio= n of "operator=3D". This operation is done via indirect function = calls, and it is as efficient as most implementations of `std::any` from va= rious vendors.

`data_` is actually implementation = detail, I don't know about your motivation that it should be shared_ptr= <T> or cow_ptr<T>.

Mingxin Wang
<= /div>

You are just simulate RTTI via functi= on pointers and meta-type pointer (const manager_t*).

Motivation is simple: do not copy big data, wh= en it's not needed. Passing policy in constructor like=C2=A0in_place_type_t=C2=A0can do the job.
=
=C2=A0
You are right about the demand in different lifetime = management strategies. Unfortunately, `std::any` and `std::function` do no = support customization in this aspect. For this reason, I designed things li= ke `SharedWrapper`, `DeepWrapper` and `DefferedWrapper` in my polymorphism = support system ("The Proxies - A Language Feature Decoupling Implement= ations from Requirements of Polymorphism", proposal is still in proces= s).

However, I do not agree with the idea that we = should "pass different policies to the constructors" to choose pr= oper lifetime management strategy, because such strategy should be a proper= ty that associated with each wrapper, and therefore I tend to define polymo= rphic wrappers associating with different lifetime management strategies as= different types.

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/e96fb60b-e69a-4ae6-a2c4-f3d33e88166b= %40isocpp.org.
------=_Part_17203_341371608.1508224569949-- ------=_Part_17202_1913463855.1508224569949-- .