220 17896 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:41:18 -0700 (PDT) Lines: 156 Approved: news@gmane.org Message-ID: 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> <01129576-7ef2-4ac3-b7b7-3ea38e33e127@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1041_539864701.1431715278235" X-Trace: ger.gmane.org 1431715284 24293 80.91.229.3 (15 May 2015 18:41:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 18:41:24 +0000 (UTC) Cc: mash.boyko2014@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTX33CVAKGQESJPZXTI@isocpp.org Fri May 15 20:41:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f198.google.com ([209.85.216.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtKXw-0005yR-IQ for gclcip-std-proposals@m.gmane.org; Fri, 15 May 2015 20:41:20 +0200 Original-Received: by qcbmu5 with SMTP id mu5sf96425511qcb.0 for ; Fri, 15 May 2015 11:41:19 -0700 (PDT) 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:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=4fkYNm8G7w6k5gyYJ3gHK6f9VICJpdLVjfVZBsc60VM=; b=IRSICtG1YS9BbsUp7AQOD+hLK6zPmRJfYBdU1CxTmSw4ij1cWFtTq/Q0sAtV+WBrJw NSzaa0Kvo4CF7o1frpBQSbZUnolUhfkBxEPuLQzUEx1shyrRxN47L51EyveRQV5NifKG aaXtu5cJzHCxJsXwn9+UvqRBLapgWZYucY9w6tkqxTn883NFnilJN8d5zDzgASp2xEGq CuCxSxBbFfid6FaYNEWUPKE1l63P35IOyyYU0iZ0KSRfVO+gj7ZGfAU8Ds05fX9PE6xB V0fvdbGwzHUZlFxJhw0ZiI+SGtuuhUMrKACqRa26Q+MV9Hx5uHyLARS8Ibj6Cr6Dr8bA uLfQ== 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:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=4fkYNm8G7w6k5gyYJ3gHK6f9VICJpdLVjfVZBsc60VM=; b=ge4TB7AcfNPfqhYWTx115b6KXmDHa0cycZeB1XcxS2JZzn3nbnKZnt/djwYehaz9Ju LyD6Zjs9GAIwzeMImO14LO1vZtqUEQIBrq7CpvUIQXGTlVVhULRbjvpioyEwLrCzyzDd I+GVGiqzkw81Lfgtb5Fx2EphjACN2pW0bfoU0MSYfwV9ttbvjoqhrEev4vKqTfZKjsJw SApcGkhrXm0+jgdI1PyaEMV2oMtAMp0QKW9I62p0+GldYCULLz4MrsrAJHnFaHSeqj3D S/rjrSfKRKPx/4IojZ+ZL6S8ptE4AucopFihNcvObObo8wyC1kbeOAHAu3q5IEv0Z5wQ eG0Q== X-Gm-Message-State: ALoCoQmxIdUDInQL7q3dIfRGU1qxVTNjLH+UJ5kFl9XUxUM+Wtn2XyyUX0c+4tbqL0qOBFjFj7RS X-Received: by 10.236.216.52 with SMTP id f50mr15434570yhp.13.1431715279429; Fri, 15 May 2015 11:41:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.2 with SMTP id a2ls269165qge.46.gmail; Fri, 15 May 2015 11:41:18 -0700 (PDT) X-Received: by 10.140.41.40 with SMTP id y37mr190142qgy.1.1431715278809; Fri, 15 May 2015 11:41:18 -0700 (PDT) In-Reply-To: <01129576-7ef2-4ac3-b7b7-3ea38e33e127@isocpp.org> 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:17896 Archived-At: ------=_Part_1041_539864701.1431715278235 Content-Type: multipart/alternative; boundary="----=_Part_1042_387621132.1431715278235" ------=_Part_1042_387621132.1431715278235 Content-Type: text/plain; charset=UTF-8 On Friday, May 15, 2015 at 2:18:29 PM UTC-4, Michael Boyko wrote: > > I didn't say the event was a member of A and I'll disagree with you and > say object B has every right to attach A to some event. Its a valid design. > Let's say that object B has the right to attach object A to an event. OK, fine. But rights come with *responsibilities*. If you design a system such that object B has the right to attach some other object A to events, then object B must take on the responsibility to manage that attachment. It needs to make sure that A is not destroyed before the connection is broken, for example. Because B has done this without A's knowledge, this responsibility must rest on B's shoulders, since it got A involved. There are several ways to handle this. Maybe B stored a shared_ptr in the event. Maybe B tells A that it has been connected, so its destructor can disconnect it (which also requires that it be able to detect if the event E is destroyed). Maybe there's some higher-level construct that is informed by B that a connection between A and E has been formed, so it will destroy them when A is being destroyed. Or maybe you have an a priori assumption that A will always outlive whatever event objects it gets attached to. That last one? I don't see how that is "valid design" in most cases. It's certainly not something that should be *encouraged* or made the default case. Ignoring one's responsibilities and pretending they don't exist is not an effective solution to most problems. Oh, and here's an interesting way to handle it. Instead of registering a member pointer + shared_ptr (assuming your `fun_ptr` can even handle that), you instead register a lambda that looks like this: [ptr = weak_ptr{smart_ptr}](...) { shared_ptr p = ptr.lock(); if(p) { return p->MemberFunction(...);} return {}; } Oh but that's right; you can't register a lambda with your `fun_ptr` type. Too bad; either your event system handles weak relationships manually (which is admittedly reasonable... though you wouldn't be able to use your `fun_ptr` type to do it), or you're SOL. -- --- 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_1042_387621132.1431715278235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, May 15, 2015 at 2:18:29 PM UTC-4, Michael Boyko= wrote:
<= /div>
I didn't say the event was a member of A and I'll disagree with y= ou and say object B has every right to attach A to some= event. Its a valid design.

Let's say that= object B has the right to attach object A to an event. OK, fine.

Bu= t rights come with responsibilities. If you design a system such tha= t object B has the right to attach some other object A to events, then obje= ct B must take on the responsibility to manage that attachment. It needs to= make sure that A is not destroyed before the connection is broken, for exa= mple. Because B has done this without A's knowledge, this responsibility mu= st rest on B's shoulders, since it got A involved.

There are several= ways to handle this. Maybe B stored a shared_ptr<A> in the event. Ma= ybe B tells A that it has been connected, so its destructor can disconnect = it (which also requires that it be able to detect if the event E is destroy= ed). Maybe there's some higher-level construct that is informed by B that a= connection between A and E has been formed, so it will destroy them when A= is being destroyed. Or maybe you have an a priori assumption that A will a= lways outlive whatever event objects it gets attached to.

That last = one? I don't see how that is "valid design" in most cases. It's certainly n= ot something that should be encouraged or made the default case. Ign= oring one's responsibilities and pretending they don't exist is not an effe= ctive solution to most problems.

Oh, and here's an interesting way t= o handle it. Instead of registering a member pointer + shared_ptr<A> = (assuming your `fun_ptr` can even handle that), you instead register a lamb= da that looks like this:

[ptr =3D w= eak_ptr<= ;A<= span style=3D"color: #660;" class=3D"styled-by-prettify">>{smart_ptr}](...)
{
  shared_ptr<A> p =3D ptr.lock<= /span>();<= span style=3D"color: #000;" class=3D"styled-by-prettify">
  = if(p) { ret= urn p->MemberFunction(...);}
  <= span style=3D"color: #008;" class=3D"styled-by-prettify">return {};
}

Oh but that's= right; you can't register a lambda with your `fun_ptr` type. Too bad; eith= er your event system handles weak relationships manually (which is admitted= ly reasonable... though you wouldn't be able to use your `fun_ptr` type to = do it), or you're SOL.

--

---
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_1042_387621132.1431715278235-- ------=_Part_1041_539864701.1431715278235-- .