220 32773 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: Wed, 14 Jun 2017 01:11:55 -0700 (PDT) Lines: 506 Approved: news@gmane.org Message-ID: References: <8d79a013-fe0e-4fb6-8278-d438ae9b4c64@isocpp.org> <6416578b-a1b5-4124-8334-f735460038b5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4458_399239291.1497427915749" X-Trace: blaine.gmane.org 1497427919 8110 195.159.176.226 (14 Jun 2017 08:11:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Jun 2017 08:11:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBTG7QPFAKGQEPEH7AMY@isocpp.org Wed Jun 14 10:11:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dL3P6-0001ey-N9 for gclcip-std-proposals@m.gmane.org; Wed, 14 Jun 2017 10:11:53 +0200 Original-Received: by mail-pg0-f72.google.com with SMTP id m19sf98916186pgd.14 for ; Wed, 14 Jun 2017 01:11: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: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=/GAmYiqiQg4z8+Mf/aUWJBaM6BoCPyyn/bVSuhfaRWw=; b=I+OGIE0efLSaYFL486hLfLYlKABrbsIJ+gGtxsWTHWA6/hiV0TFvB+zGYghQ11xQ3N 17NAFzSPR6fl/fGiHEJX8Zz+xmqhRPz7YK+1W0vql9NGdgEgaAaAE27jFh/MpcbbgJoS VzkKtQ5PMlGD25XyToezsNCMjYM0mNKNdxZ2rglQbpYgDbzMLCVshd5q4p1koJGPwWta JaRKHEhkItrZPetGQrczh0jTgbuXKF5HVf6p8ixWZJrzJ5C6ZXOtoDf0QBbA/r3QBidU bprsIip3/k8CfO2/4Wmcer4qKup7rJ+H3iVITjtxFUj/8bmbKpp5mYS68UQAPg422d3W REdg== 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=/GAmYiqiQg4z8+Mf/aUWJBaM6BoCPyyn/bVSuhfaRWw=; b=fBjtGsDWrvfMK+kiqukfMJVZgz5OZl8q2KSVFxU27J01LIe5FyeX4Z4c/G0v/xN9am dp76dPi1Pzd0KPIeasXvmqsraedJDZwgeeenRCRyQt7tVnnWi+YQZcoIcaUQdMBG/xz8 okn178IONCob6yt86/OwRTKOloZI43f+2orbqBmriAnqrdn9T+j8UFCdnIoRbljQkevP nA8NqY06ytCEigL4UZT2EQCQsOYAx4BYX259BJIgJ1pHnZ4+0Kt+j4shbuhM7OzijmlB 8wzxQbQo/ntMoP8BeadkvFnhkeOJoWMyZIY4JZNLOnMueV0x/3gL+3dCD/KvKQt48knm eGsA== X-Gm-Message-State: AKS2vOyEqiIvVY0gKmClCN96F2L1wkhn0QF6WgcN1UnI1lyw6lVLTZso 3cQotAs3mibWTb7C X-Received: by 10.99.53.195 with SMTP id c186mr5031943pga.66.1497427917534; Wed, 14 Jun 2017 01:11:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.14.242 with SMTP id 105ls1057171otj.0.gmail; Wed, 14 Jun 2017 01:11:56 -0700 (PDT) X-Received: by 10.157.83.41 with SMTP id g41mr265219oth.13.1497427916360; Wed, 14 Jun 2017 01:11:56 -0700 (PDT) In-Reply-To: <6416578b-a1b5-4124-8334-f735460038b5@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:32773 Archived-At: ------=_Part_4458_399239291.1497427915749 Content-Type: multipart/alternative; boundary="----=_Part_4459_1857707340.1497427915750" ------=_Part_4459_1857707340.1497427915750 Content-Type: text/plain; charset="UTF-8" On Tuesday, June 13, 2017 at 11:20:26 PM UTC+8, Nicol Bolas wrote: > > On Tuesday, June 13, 2017 at 9:49:43 AM UTC-4, Mingxin Wang wrote: >> >> *Technical Specifications* >> >> *Wrapper requirements* >> >> A type W meets the Wrapper requirements if the following expressions are >> well-formed and have the specific semantics (w denotes a value of type W). >> >> w.get() >> Requires: w is initialized with an object. >> Effects: acquires the pointer of the wrapped object if there is one. >> Return type: void*. >> Returns: a pointer of the wrapped object. >> >> > This seems decidedly thin on details. > > As I understand your design, the "wrapper" provides both the storage for > the object/pointer as well as determining the semantics relative to that > object/pointer. This is not entirely clear from your technical > specifications, but everything else I'm going to say is based on this > assumption. > > A "Wrapper" is only required to support semantics for addressing (at minimum). > First, "wrapper" is a *terrible* name for this concept. It isn't > "wrapping" anything; it's providing storage and specifying the semantics of > the proxy (which also isn't a particularly good name). That isn't > "wrapping". It's simply providing the semantics of the type. So "Semantics" > seems a much more descriptive name. > > I think "Semantics" is not as good as "Wrapper". As this is a relatively subjective issue, maybe we need more feedback and discuss about it later. > Second, the `get` interface is entirely insufficient to fully define this > concept. The "wrapper" needs to be able to be initialized from any object > that matches `I`, so that has to be part of its interface. Your example > code shows this, but these "Wrapper requirements" don't mention it. > Furthermore: > > There is no particular requirements on "what type can be used to construct a wrapper". Actually, a type that meets the Wrapper requirements may carry such constraints on its constructors. > Third, it's not clear who is actually responsible for the *type erasure* > part of this. The type `T` provided to a "proxy" seems to be erased by the > code generated data. But since the "wrapper" holds the storage for said > `T`, it must also have enough information to *destroy* that object. After > all, the "wrapper" may copy/move from the given `T` into new storage for > that `T`. Which means that the "wrapper" implementation has to know what > that `T` was when it goes to destroy it. > > A Wrapper may be responsible to destroy an object just as std::any does, and a Proxy is responsible for ACCESSING the object without RTTI. > This means that any "wrapper" that actually owns a `T` must *itself* > perform type-erasure, for the purpose of destroying the `T`. We discussed > this in your last thread. Double-type-erasure is less efficient than > single-type-erasure, thus violating one of your design goals. > > Not exactly. Double-type-erasure only requires a little more memory (one-pointer size) and is more compatible. That is why we usually use "combination instead of inheritance" in architecture designing. Besides, I have ran a performance test for DeepWrapper, 16u> and std::function which have the same SOO size on my compiler (Windows 7 x64, gcc version 6.3.0 x86_64-posix-seh-rev2, Built by MinGW-W64 project, Command: g++.exe -march=corei7-avx -O2 -m64 -fconcepts -std=c++17), and the result turns out to be positive that DeepWrapper, 16u> is more efficient than the implementation of std::function most of the time because there is an extra addressing operation for the virtual table for std::function, as is shown below (x: the size of the object for type erasure; y: the time elapsed): > Now, you might be able to work around this problem. You could design it so > that the "wrapper" explicitly advertises in its interface that it is an > "owning" wrapper, such that it needs to be provided with the un-erased `T` > when the "proxy" is being destroyed. But that's a much more complex > interface than you have outlined here. > This is not always necessary, especially when W is a trivial type. > *Class template proxy* >> >> Expression "proxy" is a well-formed type if I is a pure virtual >> class (without a virtual destructor) and W is a type meets the Wrapper >> requirements defined above. >> >> "proxy" is MoveConstructible if W is MoveConstructible, while >> "proxy" is CopyConstructible if W is CopyConstructible. >> >> Providing p is a value of "proxy" and i is a pointer of I, >> "p.f(args...)" shall be a valid expression if "(*i).f(args...)" is a valid >> expression, where f is any valid function name (including operator >> overloads) and "args..." is any valid combination of values of any type. >> > > As previously mentioned, the "proxy" ought to provide `any_cast`-like > functionality. That is, the ability to extract an object/reference to the > exact `T` which was provided. Since the "proxy" type's semantics are part > of its type declaration (defined by `W`), it would be easy to specialize > the interface for reference proxies vs. value proxies. > > Alternatively, you could use the `std::function::target` interface for a > lighter-weight version. But the overall point is the same: a type-erased > type ought to be able to extract what it was given. > > Yes, This is a question worth considering. Luckily, this does not require reconstructing, we can simply "add" the feature to this solution. Maybe we can have something like "std::any_cast": template ValueType proxy_cast(const proxy& operand); template ValueType proxy_cast(proxy& operand); template ValueType proxy_cast(proxy&& operand); template const ValueType* proxy_cast(const proxy* operand) noexcept; template ValueType* proxy_cast(proxy* operand) noexcept; Implementations may use dynamic_cast for RTTI. To clarify this issue, we may as well assume there is an invisible "helper" member function in the class template proxy for the function templates defined above, as is shown below: template requires Wrapper() class proxy { public: // ... template T* __cast() { Abstraction* ptr = dynamic_cast*>(reinterpret_cast(data_.get())); return ptr == nullptr ? nullptr : reinterpret_cast(ptr->wrapper_.get()); } // ... private: class Abstraction : public I { public: /* ... */ W wrapper_; }; class Uninitialized : public Abstraction { /* ... */ }; template class Implementation : public Abstraction { /* ... */ }; MemoryBlock data_; }; *Prototypes for Wrappers* >> >> Class "SharedWrapper" (with shared semantics), class template >> "DeepWrapper" (with value semantics and SOO feature) and class >> "DefferedWrapper" (with reference semantics) are designed to meet the >> Wrapper requirements. Possible implementation is included in the >> attachments. >> > > "DeepWrapper" is the wrong name. It provides "value semantics". Calling it > "deep" suggests "deep copying", which is *not* what this provides. It > should simply be "ValueWrapper". And there should also be a > "MoveValueWrapper", for use in cases where you want to allow users to > provide move-only types. > > "DefferedWrapper" is similarly misnamed (though also misspelled). It > provides "reference semantics", so it is a "ReferenceWrapper". Admittedly, > we already have a type with that name, but that's another reason not to > call them "wrappers" at all. > > I am sorry about the misspelling. It should be "DeferredWrapper" rather than "DefferedWrapper". Still, I suggest we need more feedback and discuss the naming issue later. > Also, it's not clear what "SharedWrapper" means. Does it copy/move into > memory owned by the proxy, ala `make_shared`? Can you pass it a > `shared_ptr` instead of a `T`, so that you can share ownership of the > object with the proxy? If not, why not? If you're going to allow shared > ownership of the value, then it is just as reasonable to allow shared > ownership of the value with objects that *aren't* the proxy. > > Like class template std::shared_ptr, "SharedWrapper" is also based on reference-counting.The differences between the two are: - std::shared_ptr is based on pointer semantics, whose general layout requires two unrelated memory block (that is why we prefer to use "std::make_shared" to avoid "twice memory allocation", and why some people dislike std::shared_ptr), while SharedWrapper only requires one memory block maintaining both the reference-count and the value of the concrete object (rather than a pointer of the concrete object). Thus there is no conversion between std::shared_ptr and SharedWrapper as they have different structures. - std::shared_ptr is type-specific, while SharedWrapper is type-erased. See the implementation (shared_wrapper.hpp) included in src.zip for more details. This is one of the problems of going to a generic mechanism for handling > semantics: the rabbit hole of possibilities is infinite. > > That being said, since the "wrapper" is part of the proxy's template > declaration, it is possible to have the "wrapper" actually influence the > proxy's interface. So the "wrapper" could affect the definition of the > proxy's template constructor from `T`, as well as the template function > which extracts a pointer/reference to the proxied type. A `SharedWrapper` > could therefore allow you to pass a `shared_ptr`, as well as allow you > to extract a `shared_ptr`. > -- 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/b61a514a-3a2b-4ce5-8bd3-984d547657a0%40isocpp.org. ------=_Part_4459_1857707340.1497427915750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, June 13, 2017 at 11:20:26 PM UTC+8, Nicol Bola= s wrote:
On Tu= esday, June 13, 2017 at 9:49:43 AM UTC-4, Mingxin Wang wrote:
Technical Specifications

Wrapper requirements

A type W= meets the Wrapper requirements if the following expressions are well-forme= d and have the specific semantics (w denotes a value of type W).
=
w.get()
Re= quires: w is initialized with an object.
Effects: acquires the pointer of the wrapped object if ther= e is one.
Return type: vo= id*.
Returns: a pointer o= f the wrapped object.


This = seems decidedly thin on details.

As I understand your design, the &q= uot;wrapper" provides both the storage for the object/pointer as well = as determining the semantics relative to that object/pointer. This is not e= ntirely clear from your technical specifications, but everything else I'= ;m going to say is based on this assumption.

A "Wrapper" is only required to support semantics for addr= essing (at minimum).
=C2=A0
First, "wrapper" is a terri= ble name for this concept. It isn't "wrapping" anything; = it's providing storage and specifying the semantics of the proxy (which= also isn't a particularly good name). That isn't "wrapping&qu= ot;. It's simply providing the semantics of the type. So "Semantic= s" seems a much more descriptive name.

I think "Semantics" is not as good as "Wrapper". = As this is a relatively subjective issue, maybe we need more feedback and d= iscuss about it later.
=C2=A0
Second, the `get` interface is entirel= y insufficient to fully define this concept. The "wrapper" needs = to be able to be initialized from any object that matches `I`, so that has = to be part of its interface. Your example code shows this, but these "= Wrapper requirements" don't mention it. Furthermore:

=
There is no particular requirements on "what t= ype can be used to construct a wrapper". Actually, a type that meets t= he Wrapper requirements may carry such constraints on its constructors.
=C2=A0=C2=A0
Third, it's not clear who is actually responsible for = the type erasure part of this. The type `T` provided to a "prox= y" seems to be erased by the code generated data. But since the "= wrapper" holds the storage for said `T`, it must also have enough info= rmation to destroy that object. After all, the "wrapper" m= ay copy/move from the given `T` into new storage for that `T`. Which means = that the "wrapper" implementation has to know what that `T` was w= hen it goes to destroy it.

A Wrapper m= ay be responsible to destroy an object just as std::any does, and a Proxy i= s responsible for ACCESSING the object without RTTI.
=C2=A0
=
This mea= ns that any "wrapper" that actually owns a `T` must itself= perform type-erasure, for the purpose of destroying the `T`. We discussed = this in your last thread. Double-type-erasure is less efficient than single= -type-erasure, thus violating one of your design goals.

=
Not exactly. Double-type-erasure only requires a little m= ore memory (one-pointer size) and is more compatible. That is why we usuall= y use "combination instead of inheritance" in architecture design= ing. Besides, I have ran a performance test for DeepWrapper<Callable<= void()>, 16u> and std::function<void()> which have the same SOO= size on my compiler (Windows 7 x64, gcc version 6.3.0 x86_64-posix-seh-rev= 2, Built by MinGW-W64 project, Command: g++.exe -march=3Dcorei7-avx -O2 -m6= 4 -fconcepts -std=3Dc++17), and the result turns out to be positive that De= epWrapper<Callable<void()>, 16u> is more efficient than the imp= lementation of std::function<void()> most of the time because there i= s an extra addressing operation for the virtual table for std::function<= void()>, as is shown below (x: the size of the object for type erasure; = y: the time elapsed):

=


Now, you might be able to work around this problem. You = could design it so that the "wrapper" explicitly advertises in it= s interface that it is an "owning" wrapper, such that it needs to= be provided with the un-erased `T` when the "proxy" is being des= troyed. But that's a much more complex interface than you have outlined= here.

Class template proxy

Expression &= quot;proxy<I, W>" is a well-formed type if I is a pure virtual c= lass (without a virtual destructor) and W is a type meets the Wrapper requi= rements defined above.

"proxy<I, W>&quo= t; is MoveConstructible if W is MoveConstructible, while "proxy<I, = W>" is CopyConstructible if W is CopyConstructible.

<= /div>
Providing p is a value of "proxy<I, W>" and i is = a pointer of I, "p.f(args...)" shall be a valid expression if &qu= ot;(*i).f(args...)" is a valid expression, where f is any valid functi= on name (including operator overloads) and "args..." is any valid= combination of values of any type.

As pre= viously mentioned, the "proxy" ought to provide `any_cast`-like f= unctionality. That is, the ability to extract an object/reference to the ex= act `T` which was provided. Since the "proxy" type's semantic= s are part of its type declaration (defined by `W`), it would be easy to sp= ecialize the interface for reference proxies vs. value proxies.

Alte= rnatively, you could use the `std::function::target` interface for a lighte= r-weight version. But the overall point is the same: a type-erased type oug= ht to be able to extract what it was given.

Yes, This is a question worth considering. Luckily, this does not req= uire reconstructing, we can simply "add" the feature to this solu= tion. Maybe we can have something like "std::any_cast":

template<class ValueType, class I= , class W>
ValueType proxy_cast(const= proxy<I, W>& operand);

template<class ValueType, class I, cla= ss W>
ValueType proxy_cast(proxy<I= , W>& operand);

template<class ValueType, class I, class W>
ValueType proxy_cast(proxy<I, W>&= ;& operand);

template<class ValueType, class I, class W>
const ValueType* proxy_cast(const proxy<I, W&= gt;* operand) noexcept;

template<class ValueType, class I, class W>
ValueType* proxy_cast(proxy<I, W>* = operand) noexcept;

Implementations may u= se dynamic_cast for RTTI. To clarify this issue, we may as well assume ther= e is an invisible "helper" member function in the class template = proxy for the function templates defined above, as is shown below:



--
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/b61a514a-3a2b-4ce5-8bd3-984d547657a0= %40isocpp.org.
------=_Part_4459_1857707340.1497427915750-- ------=_Part_4458_399239291.1497427915749-- .