220 17837 <1EF9D498-146D-4424-845B-D2C0B448D3B7@mac.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: smart function pointer proposal Date: Thu, 14 May 2015 14:27:35 +0800 Lines: 92 Approved: news@gmane.org Message-ID: <1EF9D498-146D-4424-845B-D2C0B448D3B7@mac.com> References: <736df6af-cd5e-4625-a4bb-be3cfd49a67e@isocpp.org> <2A6D8713-02D7-420A-A3D9-17F7C1D2C7F6@mac.com> <662b2b76-f8b2-4189-8eac-4b1d3a64e319@isocpp.org> <04e8b03f-5f43-41b2-8039-19ca11d31dfc@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C7472D1-F2C2-452F-B4D0-FB07D170676A" X-Trace: ger.gmane.org 1431584883 15035 80.91.229.3 (14 May 2015 06:28:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 06:28:03 +0000 (UTC) Cc: std-proposals@isocpp.org To: Arthur O'Dwyer Original-X-From: std-proposals+bncBAABBZMA2GVAKGQEU4R7VMQ@isocpp.org Thu May 14 08:27:52 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YsmcZ-0006OQ-B4 for gclcip-std-proposals@m.gmane.org; Thu, 14 May 2015 08:27:51 +0200 Original-Received: by obcus9 with SMTP id us9sf89631357obc.3 for ; Wed, 13 May 2015 23:27:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=2nRiELaK/Rc2cz6J+f7iU5DPL8BifPma+ZcbrFyA0aw=; b=GMMsI1rA04iuh2vlf8arltpaLDWBa2brSKPe6B5JJ9BsI5EtYa2jjx+zARr18Tb4qX ORAKF3s6ycx0ikHDKTKDoJf9VRIVWswL+Df6x86xqmBlZbHJ5SMxO4fOu6ggO5TNtDmS M7Im9yYPczJPC0FH6QrlibrF731ovGguWCZB5HdbGDT0Ce6gI6CXu+hKJcsPvlrpasIG 6VrrBFefzBeenMFR1GKqj8kIVxgtvD2RZ6jfYpecZqxxn7X7awEb6uLMoraWr7N74jDB oaHqz6j+0OtOP9RrdJ3F2PsXCkXD/jIbdYRsjIZkeKEDIytsvIk98l6Q/ZRgOc5EHe2G /jRg== X-Gm-Message-State: ALoCoQnMYwnfv/PVGDr084dSiRoQM8LN0hdQi7V2ChTEZ+RUKJ920YIQNgmdWeBmfRhvyo0WeC05 X-Received: by 10.42.186.15 with SMTP id cq15mr17336978icb.34.1431584870375; Wed, 13 May 2015 23:27:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.230 with SMTP id z6ls742677igl.7.gmail; Wed, 13 May 2015 23:27:49 -0700 (PDT) X-Received: by 10.68.65.1 with SMTP id t1mr5010483pbs.63.1431584869829; Wed, 13 May 2015 23:27:49 -0700 (PDT) Original-Received: from nk11p04mm-asmtp002.mac.com (nk11p04mm-asmtp002.mac.com. [17.158.236.237]) by mx.google.com with ESMTPS id vx6si1341714pab.220.2015.05.13.23.27.49 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 23:27:49 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@mac.com designates 17.158.236.237 as permitted sender) client-ip=17.158.236.237; Original-Received: from [172.20.10.2] (unknown [121.54.44.94]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NOB006VBTXZMZ20@nk11p04mm-asmtp002.mac.com> for std-proposals@isocpp.org; Thu, 14 May 2015 06:27:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-14_03:2015-05-13,2015-05-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1505140087 In-reply-to: <04e8b03f-5f43-41b2-8039-19ca11d31dfc@isocpp.org> X-Mailer: Apple Mail (2.2098) X-Original-Sender: potswa@mac.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@mac.com designates 17.158.236.237 as permitted sender) smtp.mail=potswa@mac.com; dmarc=pass (p=NONE dis=NONE) header.from=mac.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:17837 Archived-At: --Apple-Mail=_0C7472D1-F2C2-452F-B4D0-FB07D170676A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9305=E2=80=9314, at 2:03 PM, Arthur O'Dwyer wrote: >=20 > http://melpon.org/wandbox/permlink/MdGMF2NFqO5bIYtT > Ooh, more online compilers is better. As the Boost FAQ says, the only viable operator=3D=3D behavior for std::fun= ction is to form an equality expression on-demand (impossible) from two era= sed types (impossible). > OTOH, if we ignore these "difficult" cases, then what you describe in the= paper can be implemented as a (very thin wrapper around a) std::shared_ptr= >. Your make_fun is equivalent to make_shared = and can be implemented in terms of it. The final result needs to be a std::function for polymorphism to work. You = could put the thin wrapper inside a std::function, but then you=E2=80=99d b= e arriving at my solutions which need to access the target without its exac= t type, e.g. target(). --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --Apple-Mail=_0C7472D1-F2C2-452F-B4D0-FB07D170676A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2=80=9305= =E2=80=9314, at 2:03 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

http://melpon.org/wandbox/permlink/MdGMF2NFqO5bIYtT

Ooh, more online compilers is better.

As the Boost FAQ says, the only viable operator=3D=3D behavior for std::function is to form an equality expres= sion on-demand (impossible) from two erased types (impossible).

OTOH, if we ignore these "difficult" cases, = then what you describe in the paper can be implemented as a (very thin wrap= per around a) std::shared_= ptr<std::function<SignatureType>>. Your make_fun is equivalent to make_shared and can be implemented in terms of it.

The final = result needs to be a std::function= for polymorphism to work. You could put the thin wrapper inside a std::function, but then you=E2=80=99d be a= rriving at my solutions which need to access the target without its exact t= ype, e.g. target<void>().

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--Apple-Mail=_0C7472D1-F2C2-452F-B4D0-FB07D170676A-- .