220 17894 <2c9d9f85-73d4-44ad-b2c3-fc7d647f8bc1@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: smart function pointer proposal Date: Fri, 15 May 2015 11:07:48 -0700 (PDT) Lines: 110 Approved: news@gmane.org Message-ID: <2c9d9f85-73d4-44ad-b2c3-fc7d647f8bc1@isocpp.org> 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> <8a1bb50e-aa86-4f29-9906-c279b2413914@isocpp.org> <2789e87a-9b41-4f95-ab17-9fe15d015a0f@isocpp.org> <502f2509-6aef-4776-8b40-ce6c8cb72c24@isocpp.org> <7e9a7010-cc2c-432f-980d-dc17e7d478fa@isocpp.org> <0ada2ccf-38af-4b9d-b8af-4029048bb478@isocpp.org> <6b4119ff-e944-48eb-b391-2669dae63bea@isocpp.org> <58faea9e-b2af-460d-80e5-3da2deee7cfb@isocpp.org> <015c0f79-6051-4864-9fc4-acac543ec5bc@isocpp.org> <8d7e946a-32f0-4e30-a35c-24f873373cab@isocpp.org> <371b996d-48a1-4007-a8a7-0bcaa047fd00@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_985_614064085.1431713268727" X-Trace: ger.gmane.org 1431713276 23525 80.91.229.3 (15 May 2015 18:07:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 18:07:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBB5PL3CVAKGQEQ5INGNY@isocpp.org Fri May 15 20:07:51 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtK1X-0005Jm-8B for gclcip-std-proposals@m.gmane.org; Fri, 15 May 2015 20:07:51 +0200 Original-Received: by pdet2 with SMTP id t2sf221938856pde.1 for ; Fri, 15 May 2015 11:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=aXbqlbu71MgxAg8YeX6D84wtL9Ps1sIY2aukQvfhS4M=; b=Ef3BR3xk4mK4973OZLFr5+/PHi293UWPOqNVIb1vL2UqyORuIIiA0rBFIjb3stsJQf RAxDyepzmE33ho+rotnl1l/dd2Wslsixc+iUNii6tktoFMDYoso1EVQRVkfa8P1azSfm cM8nHA8FI4nr3oZH+PIDKaxl65dHeqA8SO47+KE674WBfxxildLQbGpqC9Ik1SmcfyaB ie9q8v3E3Ob9CvcHWk0MdPujac3CEQraDhDwxJaqLC+nVW5S2sKXZF36XHxP+pU3LB+Z DdAVwzmzvqgZIx2LFJX4V6EWJ/gyiyP/CM9uVliVLCCf3D2ovl3XzB7vazSe6ejm75L4 TL+g== 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:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=aXbqlbu71MgxAg8YeX6D84wtL9Ps1sIY2aukQvfhS4M=; b=ApFpttObh5pCUiTcCgZlL4RXA2b+DOviQOmFYNTQsLnYPIZejKkWMMSv6et/EQc+1k 44bCbY3atGbMLyUbvHj6n25V60USQ3xPnWhguL3A0t9cvrdZCuQbhfiC46PH33/s8Avi JR+/IU9R93sy0UMLvLN1av9UeFQVm3nn3/etUkevbXTyK64rFQeYlmly33JzooeNdJev wfSwcSlw0V/4/3KvtJMtGLBJYlV8v0vopvssdMOeMv2240+5/6ee1RyFa28VChO687LC pkcR7B0No+IZgsYkhKqYftbTiFvaqsTL1BGFXF5QwIlR+9A3ZglzVN9g+vSCIoNjkj2C iuug== X-Gm-Message-State: ALoCoQmJTnjvV2YhJPQcGGmtQYpqoydFLtyOwbsedBnhjUqcUmZCNuMECKmB556fq+Orlbm8THPJ X-Received: by 10.66.153.173 with SMTP id vh13mr15077274pab.37.1431713270227; Fri, 15 May 2015 11:07:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.83.208 with SMTP id j74ls962601qgd.89.gmail; Fri, 15 May 2015 11:07:49 -0700 (PDT) X-Received: by 10.140.89.168 with SMTP id v37mr192559qgd.7.1431713269331; Fri, 15 May 2015 11:07:49 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:17894 Archived-At: ------=_Part_985_614064085.1431713268727 Content-Type: multipart/alternative; boundary="----=_Part_986_1916152760.1431713268727" ------=_Part_986_1916152760.1431713268727 Content-Type: text/plain; charset=UTF-8 On Friday, May 15, 2015 at 2:01:24 PM UTC-4, Michael Boyko wrote: > > > > On Friday, May 15, 2015 at 12:33:23 PM UTC-5, Brent Friedman wrote: >> >> Players can detach themselves by taking an antidote or some other player >>> casting a reverse spell. >>> >> >> I do have code with a flavor similar to this. I have a complex object (a >> 3d viewport) which can have callbacks attached to it for various events. >> Many places can register or unregister these callbacks. In that system, >> registering a callback returns a handle (iterator). That handle is used to >> unregister. I've found this to work perfectly well in my case. Your case is >> slightly different in that the antidote probably applies to a class of >> spells rather than applying to a specific instance of a spell. It seems >> like using an id for comparing functions is most correct here. As soon as >> you have a spell which can apply random effects (selects from one of >> several std::functions) the function equality technique could break down or >> become onerous. It also seems wasteful and architecturally onerous to >> require construction of the std::function just so you can do equality >> comparison to unregister. >> >> > I agree my example might be a bit contrived but the main point is > when different objects perform the attach and detach it would be nice to > not have to go searching for the handle to perform the disconnect. Sharing > a connection handle among many objects seems rather ugly. Most likely > similar examples are possible with GUI widget interactions. > What's "rather ugly" about it? It makes more sense than various unrelated GUI widgets assuming which public member functions they're all registering. At least the ownership relationships for connections are clear. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_986_1916152760.1431713268727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, May 15, 2015 at 2:01:24 PM UTC-4, Micha= el Boyko wrote:


On Friday, May 15, 2015 at 12:33:23 PM UTC-5, Brent Friedman wrot= e:
Players can detach themselves by taking an antidote or some othe= r player casting a reverse spell.

I do have code with a flavor similar to this. I have a complex object (a = 3d viewport) which can have callbacks attached to it for various events. Ma= ny places can register or unregister these callbacks. In that system, regis= tering a callback returns a handle (iterator). That handle is used to unreg= ister. I've found this to work perfectly well in my case. Your case is slig= htly different in that the antidote probably applies to a class of spells r= ather than applying to a specific instance of a spell. It seems like using = an id for comparing functions is most correct here. As soon as you have a s= pell which can apply random effects (selects from one of several std::funct= ions) the function equality technique could break down or become onerous. I= t also seems wasteful and architecturally onerous to require construction o= f the std::function just so you can do equality comparison to unregister.

 
I agree my= example might be a bit contrived but the main point is when different= objects perform the attach and detach it would be nice to n= ot have to go searching for the handle to perform the disconnect.= Sharing a connection handle among many objects seems rather ugly= .. Most likely similar examples are possible with GUI widget interactio= ns.

What's "rather ugly" about it? It make= s more sense than various unrelated GUI widgets assuming which public membe= r functions they're all registering. At least the ownership relationships f= or connections are clear.

--

---
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>.
------=_Part_986_1916152760.1431713268727-- ------=_Part_985_614064085.1431713268727-- .