220 29147 <6d03522b-39f0-4d96-8384-ef9210122168@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: joseph.thomson@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [propagate_const] Implicit conversion to T Date: Wed, 26 Oct 2016 21:52:35 -0700 (PDT) Lines: 282 Approved: news@gmane.org Message-ID: <6d03522b-39f0-4d96-8384-ef9210122168@isocpp.org> References: <1f43ffe8-b267-4c8c-8834-f3e60035f18d@isocpp.org> <5c682d18-9cf2-4a80-9e58-6b8fae2cf7e8@isocpp.org> <20161023161002.4911185.19138.19005@gmail.com> <08231f25-9d2b-40be-a79e-92225a0b0336@isocpp.org> <20161023175710.4911185.4764.19015@gmail.com> <8EE69808-0C9A-4825-B834-375CDBA8FAC5@gmail.com> <0921ce76-4294-460d-9bd4-ad2816741b10@isocpp.org> <80EB0663-B834-488C-85A7-2767F6196BCF@gmail.com> <754c5bb6-b821-4565-8dd0-76c1fb2b5a7a@isocpp.org> <01eb6560-8902-40e3-af54-c395f3d3d33d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_278_933223176.1477543956105" X-Trace: blaine.gmane.org 1477543964 11605 195.159.176.226 (27 Oct 2016 04:52:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2016 04:52:44 +0000 (UTC) Cc: joseph.thomson@gmail.com, mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDQM7AFVVUERBFMQY3AAKGQEFNR4K4A@isocpp.org Thu Oct 27 06:52:39 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzcg8-0002Dj-NH for gclcip-std-proposals@m.gmane.org; Thu, 27 Oct 2016 06:52:37 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id e12sf42882851oib.5 for ; Wed, 26 Oct 2016 21:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=jh54j3cMCtzkFzG2Fq5hCI8dp5g8iLmtqT/0IZJuxXY=; b=lqinNPI94p3C6zRlAt5ZEixBU+HbTXH2WJWEPJUbMfC0lhLN6rnXoAqtujBBHAtFLb oOT0RqIOlwqDXq6WREqePEHAPbqBSJMaicJF7Mdg5pGWlK9JV13BqPoQ5EgkYgo1Ujjn m0Z1YsQrq7dx2DoZIhCXN7pt3QDo8DYDr4Yi+MP8tsE/keppqLGRR6hUVIBLpKCxiMXw tKA2OEZ+5o2cqd2GTwEIQLleaDb/fyKt+tf+C5h0rexbwy2sqI5DNwFCQGYZ3T6hDf67 yXrv5eLevoF4lSaM9e3Xy36dQeDkjgu1hTip9j6GMMouunAo+UBAJ3jJaK1iqT2WJdMh aHAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=jh54j3cMCtzkFzG2Fq5hCI8dp5g8iLmtqT/0IZJuxXY=; b=BT3LtVYHl72gN6YGQi1fjI/DKueBRH4xul51aIWJwAeE62c0U1MnYdoPxPkjN7TLAp RQ/SqJhzjpgiWbttzdh6jEan7dc2KizHFkZfJT8oQDxilGveVC63irVno/AGv2QpIvvH G2okQGtU1yaoRqvXADEYkvtXZfQQuzrJHtloYbCS84tAKR8vkpSufPRPjePxCY9ZuwXu oAhYmwdReddfir1NuVJuj/dzzVy1H2JWe1mn6u6W74kxsHDNV/hTuxzJcN3XcSjKx5ny /itBR9VFbRHUp+oXNuqZozL4dL/JYZp9MbcfnPY+N5SS3jq4M8uyhXfa+fJJxI0jIxXr sEeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc: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=jh54j3cMCtzkFzG2Fq5hCI8dp5g8iLmtqT/0IZJuxXY=; b=UhDxt8MUC0XcvDt995bQ2M2/A9DHrZRh8EWGuUktvjzkbJdMQHUKsoRrN4zNJx93y5 qM/OgmCGS8wEMpf/NKFAf9Ku/UUw/muCSw9yno2Nobt9MQgSAlAsFJTn3qyuZPaxAruU 76Gdh83mFKRRUajrYK9MaUCZ1O2l53wbunMG3rQiw9mSh3tDWYPByOy7Gc/qUjn2iB4J QsOBIdiBDbldm4dKvUNKKIamX55mdeN0ivn8Ax5vN4/lKp2l9+lDJsqk6U+GRF+JYcCZ pbJIQm9p+6tqQh05wl/g7d81TxPPTFdcvP70A0eqQfP6Udwu3Ei+ef8ZCXqmPUOpMRUT 0s4A== X-Gm-Message-State: ABUngvcJ1OauQsVkJYTIQ9uRtRA+f1JCMe6bPnz5k77JiwmEUWXGonTM6VWYYdiVRQeATA== X-Received: by 10.157.60.6 with SMTP id q6mr2063313otc.141.1477543958844; Wed, 26 Oct 2016 21:52:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.11.162 with SMTP id 34ls909323iol.13.gmail; Wed, 26 Oct 2016 21:52:37 -0700 (PDT) X-Received: by 10.36.196.194 with SMTP id v185mr807953itf.4.1477543957281; Wed, 26 Oct 2016 21:52:37 -0700 (PDT) In-Reply-To: <01eb6560-8902-40e3-af54-c395f3d3d33d@isocpp.org> X-Original-Sender: joseph.thomson@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:29147 Archived-At: ------=_Part_278_933223176.1477543956105 Content-Type: multipart/alternative; boundary="----=_Part_279_582691260.1477543956106" ------=_Part_279_582691260.1477543956106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, 27 October 2016 04:28:17 UTC+8, mihailn...@gmail.com wrote: > > ... >> >> T t; // t default constructed (value-like) >> polymorphic p; // *p default constructed (value-like) >> indirect i; // i is empty (pointer-like) >> >> T t =3D tt; // t copy constructed (value-like) >> polymorphic p =3D tt; // *p copy constructed (value-like) >> indirect i =3D tt; // error: cannot assign from T (pointer-like) >> >> T t =3D std::move(tt); // t move constructed; tt moved from (value-like) >> polymorphic p =3D std::move(pp); // *p move constructed; *pp moved fr= om=20 >> (value-like) >> indirect i =3D std::move(ii); // ownership transferred from ii to i; = ii=20 >> now empty (pointer-like) >> >> T t{1, 2, 3}; // t constructed in-place with arguments (value-like) >> polymorphic p{in_place, 1, 2, 3}; // *p constructed in-place with=20 >> arguments (value-like) >> indirect i{new T{1, 2, 3}}; // i constructed from pointer that it=20 >> takes ownership of (pointer-like) >> >> // note: operator bool not defined for T >> if (t) { =E2=80=A6 } // error: t cannot convert to bool (value-like) >> if (p) { =E2=80=A6 } // error: p cannot convert to bool (value-like) >> if (i) { =E2=80=A6 } // i checked for empty status (pointer-like) >> > > I agree it is more close to pointer then to a value, but that's a good=20 > thing. It should feel, you are managing a remote recourse. =20 > =20 I have no problem with a cloned_ptr proposal (essentially unique_ptr + deep= =20 copy (+ const-propagation, maybe). I just think the aims of the current=20 proposal are confused. If it wants to be a polymorphic value-like type, I= =20 suggest something similar to what I presented. If it wants to be a=20 deep-copying pointer-like type, then the chosen name should suggest that (I= =20 like deep_copy_ptr), and it should probably support the appropriate=20 pointer-like operations (e.g. p =3D nullptr, p.get(), p.reset(x)). Also, note that indirect<>, is intended to be constructed with=20 > make_indirect NOT with the ctor with a pointer.=20 > =20 This doesn't fix the fact that the only way to directly construct indirect,= =20 a supposedly value-like type, is by passing it ownership of a raw pointer. About polymorphic=20 > The way it is right now, you do many allocations, just to pretend it is a= =20 > real variable on the stack - allocating default ctor, not empty after mov= e,=20 > etc.=20 > All these I don't think are of benefit compared to the cost. > =20 That's the idea. It behaves just like a stack-allocated object, but with=20 polymorphism. If you can't afford the copies, then maybe you need a=20 deep_copy_ptr instead. Assignment from raw value however might be useful, especially move=20 > assignment.=20 > =20 Assignment from T is only really possible when you ditch the deleter and=20 copier (it is only safe when using default_delete and default_copy). Lastly, I find custom copier and deleter to be essential for the class to= =20 > be useful.=20 > Copier and deleter do not make sense for a value-like type. The only way=20 you *might* be able to crowbar them in is if you disallow assignment from= =20 T, and also have a "creator" and "mover". However, I still think if you are= =20 going to support generic resource-management, a pointer-like type is what= =20 you need. --=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/6d03522b-39f0-4d96-8384-ef9210122168%40isocpp.or= g. ------=_Part_279_582691260.1477543956106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, 27 October 2016 04:28:17 UTC+8, mihailn...@gm= ail.com wrote:
...

T t; // t default constructed (value-like)
polymorphic<T><= span style=3D"color:#000"> p; // *p default cons= tructed (value-like)
indirect<T> i; // i is empty (pointer-like)

T t =3D tt; // t copy constructed (value-li= ke)
polymorphic<T> p =3D tt; // *p copy constructed (value-like)indirect<T> i =3D tt;= // error: cannot assign from T (pointer-= like)

T t =3D std::move(tt); // t move constructed; tt moved from (value-like)
polymorphic<T> p =3D std::move(pp); // *p move constructed; *pp= moved from (value-like)
indirect<T= > i = =3D std= ::move<= span style=3D"color:#660">(ii); // ownership transferred from ii to i; ii now empty (poin= ter-like)

T t{1, 2, <= /span>3}; // t constr= ucted in-place with arguments (value-like)
polymorphic<T> p{in_place, 1, 2= , 3}; // *p construct= ed in-place with arguments (value-like)indirect<T> i{new T{= 1, 2, 3}}; // i constructed from po= inter that it takes ownership of (pointer-like)

// note: operator bool not = defined for T
if (t) { =E2=80=A6= } // error: t= cannot convert to bool (value-like)
<= /span>if (p) { =E2=80=A6 } // error: p cannot convert to bool (value-like)
if (i) { =E2=80=A6 } // i checked for empty status (point= er-like)

<= div>I agree it is more close=C2=A0to pointer then to a value, but that'= s a good thing. It should feel, you are managing a remote recourse. =C2=A0 =
=C2=A0
I have no problem with a cloned_ptr proposal (essent= ially unique_ptr= + deep copy (+ const-propagation, maybe). I just think the aims of the cur= rent proposal are confused. If it wants to be a polymorphic value-like type= , I suggest something similar to what I presented. If it wants to be a deep= -copying pointer-like type, then the chosen name should suggest that (I lik= e deep_copy_ptr)= , and it should probably support the appropriate pointer-like operations (e= ..g. p =3D nullptr, p.get(), p.reset(x)).

=
Also, no= te that indirect<>, is intended to be constructed with make_indirect = NOT with the ctor with a pointer.
=C2=A0
This do= esn't fix the fact that the only way to directly construct indirect, a = supposedly value-like type, is by passing it ownership of a raw pointer.
Abo= ut polymorphic=C2=A0
The way it is= right now, you do many allocations, just to pretend it is a real variable = on the stack - allocating default ctor, not empty after move, etc.
All these I don't think are of benefit compared to the cost.
=C2=A0
That's the idea. It behaves just like a stack= -allocated object, but with polymorphism. If you can't afford the copie= s, then maybe you need a
Assignment from raw value however=C2=A0might= be useful, especially move assignment.
=C2=A0
A= ssignment from T= is only really possible when you ditch the deleter and copier (it is only = safe when using default= _delete and defa= ult_copy).

Lastly, I find custom copier and d= eleter to be essential for the class to be useful.

Copier and deleter do not make sense for a value-like type. The = only way you might be able to crowbar them in is if you disallow ass= ignment from T, and also have a "creator" and "mover". = However, I still think if you are going to support generic resource-managem= ent, a pointer-like type is what you need.

--
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/6d03522b-39f0-4d96-8384-ef9210122168= %40isocpp.org.
------=_Part_279_582691260.1477543956106-- ------=_Part_278_933223176.1477543956105-- .