220 32791 <1edb48fd-0d4c-478b-816b-6cd9b21b4f0c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: The Proxies - A Language Feature Decoupling Implementations from Requirements of Polymorphism Date: Fri, 16 Jun 2017 18:55:15 -0700 (PDT) Lines: 216 Approved: news@gmane.org Message-ID: <1edb48fd-0d4c-478b-816b-6cd9b21b4f0c@isocpp.org> References: <8d79a013-fe0e-4fb6-8278-d438ae9b4c64@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1833_161804354.1497664515735" X-Trace: blaine.gmane.org 1497664519 10492 195.159.176.226 (17 Jun 2017 01:55:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Jun 2017 01:55:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBBEYSLFAKGQEJ5KTLVA@isocpp.org Sat Jun 17 03:55:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f200.google.com ([74.125.82.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dM2xE-0002ML-Lz for gclcip-std-proposals@m.gmane.org; Sat, 17 Jun 2017 03:55:12 +0200 Original-Received: by mail-ot0-f200.google.com with SMTP id 37sf19059486otu.13 for ; Fri, 16 Jun 2017 18:55:18 -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=nVF3NRuLQiYe9GFoXoStWoyxWH1EgYuKy7k772i8XB4=; b=pUrVdfvswXLimL4b7I4/6CobExx8vOArV7FEBDJ97c+tS9nV+sjXL4m72wjR8X7XYY 1NtN7sK+FTJkLgO1onk1N5OuGbF5foof0AFRT4gd1OwePmc/kEg0yMV4qGvuanuHDHvo X8ykvdalGT9XobuJ1Qu6bIIvAGI5m5//cXZXTVpES72/ZN4fP6pmcFEwEBQ83ROd0N5g KMrmhzI/3bDqMt+Jo7gkg6LZRGghGd1uzjLxEb3lm/5gEFlAK6A87Q0qV3EziRyuUF3l ulNYlzJ34JqS7KuDvM+N33eboJ+6HqKaTVNVe6LlYWHGozWOIUJwIwggWb6rmN35X5++ v9DQ== 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=nVF3NRuLQiYe9GFoXoStWoyxWH1EgYuKy7k772i8XB4=; b=cLWISdHXummkWkawzNi6MwVrvAjvsQYD5qKHGN0s7wHKObHm//P5KRGo+NBFISP/CX maDzVIP12zyXoyRZWTNPwIRr6Qs6I4oFCHLbtr7qDWi0vQ1KbwJN5yDEe2zxg2ia5Nnv 7plRIygJWMwq+znLuxE0YBO613CJppMdQSbBuc0h2wAaaWzI9vG6rVewToJDxDXCPKNs 3KihuFNU60e61EGOMSNALe20prrKgP4yqTSKX4LwOBOqhYrZCdI+uMDS3kgc6BrIMka6 iqVrpSu99j9BU8W0WtJbenRndWsaqTCaNegaG8YB+Ve9l1FhN9kfQXDrQ6D4LsEFKYkU 4Jcw== X-Gm-Message-State: AKS2vOzoccqrM+xWRHmewJd43+IsQwPJbZYsPylR4sk0myBsOk/3PqEw sUJ2u2tKM/EL8mUQ X-Received: by 10.157.4.117 with SMTP id 108mr7038275otc.44.1497664517578; Fri, 16 Jun 2017 18:55:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.45.110 with SMTP id v101ls2594493ota.15.gmail; Fri, 16 Jun 2017 18:55:16 -0700 (PDT) X-Received: by 10.157.47.207 with SMTP id b15mr428967otd.20.1497664516406; Fri, 16 Jun 2017 18:55:16 -0700 (PDT) In-Reply-To: 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:32791 Archived-At: ------=_Part_1833_161804354.1497664515735 Content-Type: multipart/alternative; boundary="----=_Part_1834_1629482302.1497664515736" ------=_Part_1834_1629482302.1497664515736 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, June 17, 2017 at 12:16:24 AM UTC+8, Klaim - Jo=C3=ABl Lamotte = wrote: > > > On 13 June 2017 at 15:49, Mingxin Wang >= =20 > wrote: > >> *Class template proxy* >> >> Expression "proxy" is a well-formed type if I is a pure virtual=20 >> class (without a virtual destructor) and W is a type meets the Wrapper= =20 >> requirements defined above. >> >> "proxy" is MoveConstructible if W is MoveConstructible, while=20 >> "proxy" is CopyConstructible if W is CopyConstructible. >> >> Providing p is a value of "proxy" and i is a pointer of I,=20 >> "p.f(args...)" shall be a valid expression if "(*i).f(args...)" is a val= id=20 >> expression, where f is any valid function name (including operator=20 >> overloads) and "args..." is any valid combination of values of any type. >> > > > Could you clarify: if a system want to take anything that have the=20 > interface described by I, how should it=20 > > some_system.take_it_and_do_something( ??? object ); > > I believe this would be really too restrictive: > > some_system.take_it_and_do_something( proxy object ); > > Because it would force the user code to use only one ownership strategy= =20 > for anything passed to this function. > In my experience, I want the system to ignore if it will own or not the= =20 > object, let the user decide, as long as > the proxy is usable as a normal object. > In my opinion, the fact that the real object is shared or not should not= =20 > be imposed by the system consuming the proxy. > Any type that has the required expressions specified by I and can be used= =20 to construct the wrapper specified by W, can be implicitly convertible to= =20 proxy. It is true that users are responsible to specify ownership=20 strategies in type declarations, but this only happens in a certain=20 context. When there is no need for polymorphism, I prefer to declare a=20 function as a template. Here is an example use case for proxies and=20 templates: template >> class CompositTask { public: template void emplace(Args&&... args) { data_.emplace_back(std::forward(args)...); } void operator()() { for (auto& t : data_) t(); } private: std::vector data_; }; Proxy usually works well with templates. The code above is a class template= =20 with a default type, which satisfies the requirements specified by=20 Callable. Providing there is another function declared as follows: void submit_a_task(DeepProxy> task); The following code is well-formed for client code: CompositTask<> c; c.emplace([] { puts("Lambda Expression"); }); c.emplace(std::bind([](const char* x) { puts(x); }, "Bind Expression")); c.emplace(c); submit_a_task(c); Every conversion is done implicitly. =20 > > Jo=C3=ABl Lamotte > > 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/1edb48fd-0d4c-478b-816b-6cd9b21b4f0c%40isocpp.or= g. ------=_Part_1834_1629482302.1497664515736 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, June 17, 2017 at 12:16:24 AM UTC+8, Klaim - J= o=C3=ABl Lamotte wrote:

On 13 June 2017 at 15:49, Min= gxin Wang <wmx16...@163.com> wrote:
Class = template proxy

Expression "proxy&l= t;I, W>" is a well-formed type if I is a pure virtual class (withou= t a virtual destructor) and W is a type meets the Wrapper requirements defi= ned above.

"proxy<I, W>" is MoveCo= nstructible if W is MoveConstructible, while "proxy<I, W>" = is CopyConstructible if W is CopyConstructible.

Pr= oviding p is a value of "proxy<I, W>" and i is a pointer of= I, "p.f(args...)" shall be a valid expression if "(*i).f(ar= gs...)" is a valid expression, where f is any valid function name (inc= luding operator overloads) and "args..." is any valid combination= of values of any type.


Could you clarify: if a system want to take anything that have the inter= face described by I, how should it=C2=A0

=C2=A0 = =C2=A0 some_system.take_it_and_do_something( ??? object );
<= br>
I believe this would be really too restrictive:
=C2=A0 =C2=A0 some_system.take_it_and_do_something( proxy&= lt;I,W> object );

Because it would force the us= er code to use only one ownership strategy for anything passed to this func= tion.
In my experience, I want the system to ignore if it will ow= n or not the object, let the user decide, as long as
the proxy is= usable as a normal object.
In my opinion, the fact that the real= object is shared or not should not be imposed by the system consuming the = proxy.

Any type that has the re= quired expressions specified by I and can be used to construct the wrapper = specified by W, can be implicitly convertible to proxy<I, W>. It is t= rue that users are responsible to specify ownership strategies in type decl= arations, but this only happens in a certain context. When there is no need= for polymorphism, I prefer to declare a function as a template. Here is an= example use case for proxies and templates:

template <class Task =3D SharedProxy<Callable<= void()>>>
class CompositTask {<= /div>
=C2=A0public:
=C2=A0 template <class... Args>
=C2=A0 void emplace(Args&&... args) {
=C2=A0 =C2=A0 data_.emplace_back(std::forward<Args>(args= )...);
=C2=A0 }

=C2=A0 void operator()()= {
=C2=A0 =C2=A0 for (auto& t : data= _) t();
=C2=A0 }

=C2=A0private:
=C2=A0 std::vector<Task> data_;
};

Proxy usuall= y works well with templates. The code above is a class template with a defa= ult type, which satisfies the requirements specified by Callable<void()&= gt;. Providing there is another function declared as follows:
void submit_a_task(DeepProxy<Callable<void()>> task);

The following code is well-formed for client c= ode:

<= div class=3D"subprettyprint">CompositTask<> c;
c.emplace([] { puts("Lambda Expression"); });
<= div class=3D"subprettyprint">c.emplace(std::bind([](const char* x) { puts(x= ); }, "Bind Expression"));
c.e= mplace(c);
submit_a_task(c);
=
Every conversion is done implicitly.
=C2=A0

Jo=C3=ABl Lamotte


<= /div>
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/1edb48fd-0d4c-478b-816b-6cd9b21b4f0c= %40isocpp.org.
------=_Part_1834_1629482302.1497664515736-- ------=_Part_1833_161804354.1497664515735-- .