220 17853 <0ada2ccf-38af-4b9d-b8af-4029048bb478@isocpp.org> article Path: news.gmane.org!not-for-mail From: Michael Boyko Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: smart function pointer proposal Date: Thu, 14 May 2015 14:22:58 -0700 (PDT) Lines: 125 Approved: news@gmane.org Message-ID: <0ada2ccf-38af-4b9d-b8af-4029048bb478@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10_1747197703.1431638578594" X-Trace: ger.gmane.org 1431638582 28302 80.91.229.3 (14 May 2015 21:23:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 21:23:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS7L3MTUIDRBM5E2SVAKGQETECZPNQ@isocpp.org Thu May 14 23:23:02 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yt0aq-0002c2-UZ for gclcip-std-proposals@m.gmane.org; Thu, 14 May 2015 23:23:01 +0200 Original-Received: by iepj10 with SMTP id j10sf324073iep.0 for ; Thu, 14 May 2015 14:23:00 -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=ouvHnluMwWyUC2ODggrLJp6VtdqJvOJcL9hjAGrvNeU=; b=LGGY6iuhxvhbSJZx5oseEt5y/AnPZVuhlQyUfhhyl4EPRm2p4OiK/1Q8jBiYNJsaxL 3vh6mbHtCz+tex1MZTowM1RYjVgPehTsUEpYtY+ORV42S6uyrOCZ+D+U4xmVLEnl6spC Fh9F8jgwZ+mDJKL1nPwxZyVtAPMtL5nPLFIGMq1KSspcH9mLeMo2kJr3lKYIDCpT+S7F F+Rq/w/ClzamIOvfXEQ63c3gJi3l94NXcD1DHlbsvk6BCLPhbEOetJWvo8oyJiCFZEag LhucPRCMAwC7jn4oME6t26W9t7H9aVP3SvGKUpW6T8TKGocE31Df5siGdlLwqUu1a7H2 88TQ== 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=ouvHnluMwWyUC2ODggrLJp6VtdqJvOJcL9hjAGrvNeU=; b=kYSBkrEE+IPjQnZhNcNJO+/Qmwh015/unIotluS/EKGJ0FpHRMuM4LYalBMxrUXJGC tRvMKDAxwg2cEpMsswDwZe3HU4J1prtrw4bO6D8F6Zkc8SSceOzdTfF8LeZu4AC+RM5A XbsMHyTKlNFpEEMtn0iwarySWnbvrEV+sbTmgkOVOAqcnlqzmYn55OqFP9Z8xzaC7OTD JyiocKLHO7ChPo1kA35zpv/b08qwR8ZNzgUre2ucWWqBqz9YDipHfiij4q0Ud1qbdOgJ 4HLgQzOrAZVMyZhXHi0yz0wZm4LTxGhPoNoRZHQzOhrMzibyRDPNK7MQ96CFv0TESTXh 39vw== X-Gm-Message-State: ALoCoQlaHgzMaTG/GjWqbNaz2UVjuMUo+wkMTIuLvYYfxINVCkEp0XbYoxze6JY37us8VNwX09mv X-Received: by 10.182.200.197 with SMTP id ju5mr8757839obc.28.1431638579965; Thu, 14 May 2015 14:22:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.221.233 with SMTP id qh9ls613945obc.33.gmail; Thu, 14 May 2015 14:22:59 -0700 (PDT) X-Received: by 10.182.232.165 with SMTP id tp5mr66540obc.4.1431638579303; Thu, 14 May 2015 14:22:59 -0700 (PDT) In-Reply-To: <7e9a7010-cc2c-432f-980d-dc17e7d478fa@isocpp.org> X-Original-Sender: mboyko2000@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:17853 Archived-At: ------=_Part_10_1747197703.1431638578594 Content-Type: multipart/alternative; boundary="----=_Part_11_460405243.1431638578594" ------=_Part_11_460405243.1431638578594 Content-Type: text/plain; charset=UTF-8 Herb Sutter a while back wrote a article called Generalizing Observer . Under this article is a section called "An Important Limitation of function". Sutter says at one point "This lack of comparison operations is one limitation of function, and it is significant." In fact he suggested equality comparison for std::function in this article. Comparison of callback functions is a common operation that is quite pervasive in code. Yes, there are work-arounds to not having direct comparison support and RAII handles are nice. We could remove function pointer comparison for standalone and member functions and people would survive but they are useful tools. C# has delegates and events which have proved extremely useful. On Thursday, May 14, 2015 at 4:05:46 PM UTC-5, Nicol Bolas wrote: > > I guess the fundamental issue I have with comparing arbitrary function > objects of this type is the answer to this question: > > What exactly are the use cases where you're asking two function objects if > they're the same? > > We're talking about opaque callables here. You have two functions, who's > implementations could come from anything. So what is the point of testing > if one is equal to another? What are you trying to achieve by doing so. > > I have never been in a situation where I had some need to know if one > std::function I had received was equivalent by some measure to another. > Your proposal also doesn't seem to explain the need for such a feature. It > simply declares, "Equality comparison is a fundamental operation a smart > function pointer needs to support," as though it were an undeniable fact > that people obviously have need to compare two arbitrary callables. > > When you said "Equality comparison is the key feature...", you go on to > show an example of its use. But this doesn't explain the *need* for it. > > The closest your proposal gets is an example of an event handling > interface. The function you pass in to attach it to the container is also > used as the handle to unregistering the function. But personally, I prefer > to use a handle returned from the registration function. That way, I can > keep around a small handle object rather than this big, bulky > std::function. It also makes the interface more clear, if you're allowed to > do things like swap which function is registered, or add other attributes > to a specific registration (like a priority or whatever). > > So why do you need to compare two arbitrary callables that have been given > to your piece of code? > -- --- 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_11_460405243.1431638578594 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Herb Sutter a while back wrote a article called Gener= alizing Observer. Under this article is a section called "An Important = Limitation of function". Sutter says at one point "This lack of comparison = operations is one limitation of function, and it is significant." In fact h= e suggested equality comparison for std::function in this article. Comparis= on of callback functions is a common operation that is quite pervasive in c= ode. Yes, there are work-arounds to not having direct comparison support an= d RAII handles are nice. We could remove function pointer comparison for st= andalone and member functions and people would survive but they are useful = tools. C# has delegates and events which have proved extremely useful.
<= br>On Thursday, May 14, 2015 at 4:05:46 PM UTC-5, Nicol Bolas wrote:
I guess the fundamental issue I have= with comparing arbitrary function objects of this type is the answer to th= is question:

What exactly are the use cases where you're asking two = function objects if they're the same?

We're talking about opaque cal= lables here. You have two functions, who's implementations could come from = anything. So what is the point of testing if one is equal to another? What = are you trying to achieve by doing so.

I have never been in a situat= ion where I had some need to know if one std::function I had received was e= quivalent by some measure to another. Your proposal also doesn't seem to ex= plain the need for such a feature. It simply declares, "Equality comparison= is a fundamental operation a smart function pointer needs to support," as = though it were an undeniable fact that people obviously have need to compar= e two arbitrary callables.

When you said "Equality comparison is the= key feature...", you go on to show an example of its use. But this doesn't= explain the need for it.

The closest your proposal gets is a= n example of an event handling interface. The function you pass in to attac= h it to the container is also used as the handle to unregistering the funct= ion. But personally, I prefer to use a handle returned from the registratio= n function. That way, I can keep around a small handle object rather than t= his big, bulky std::function. It also makes the interface more clear, if yo= u're allowed to do things like swap which function is registered, or add ot= her attributes to a specific registration (like a priority or whatever).
So why do you need to compare two arbitrary callables that have been g= iven to your piece of code?

--

---
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_11_460405243.1431638578594-- ------=_Part_10_1747197703.1431638578594-- .