220 17887 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: Fri, 15 May 2015 07:10:35 -0700 (PDT) Lines: 137 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> <55d9352f-5bbc-487d-8d46-1aa68c4d6152@isocpp.org> <30d26342-65f1-4d7f-a7b8-287cfefee3da@isocpp.org> <4e73f342-66a5-4c73-989b-7a699a8ec512@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_349_1516250000.1431699035262" X-Trace: ger.gmane.org 1431699039 32004 80.91.229.3 (15 May 2015 14:10:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 14:10:39 +0000 (UTC) Cc: mash.boyko2014@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS7L3MTUIDRBXH426VAKGQEITO6HZY@isocpp.org Fri May 15 16:10:38 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtGJx-0004SX-QG for gclcip-std-proposals@m.gmane.org; Fri, 15 May 2015 16:10:37 +0200 Original-Received: by obcus9 with SMTP id us9sf152534703obc.3 for ; Fri, 15 May 2015 07:10:36 -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=5yjuZnyth6cQzcpCeJImZRocU4tQyAVOqD5aLSs9iZA=; b=p+j23iedmExv3vobnlr5p5oebZNmkfytSFB34VxozWo54ObIpMNVVy8VfgiXxZKpIX chQBXYj+yh+6LACrcqL/EWEKWzVvKBuCJSpj8Tle1HDMs3bwFEuL+PQrd3yheg0wrier H68lY1TUkamdC6VBMHGivhtdASECtICr4hyqXi67PXRxW+/SxSgyoe0hHDJBmO4UDbe5 TxOJnQFuHZZ73sKm7Vi7h7COOL6RAuW0Tc4sfdVXTfkI3ZNUMx7lNyOoNW5mDT/5LKjT CDTqDBqF4Lc0rSfXB1/tlJaTa0NiF/k8UuhioRGZbcG8Bf/wExjPmjGzZ6wZYq2v91Go stbg== 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=5yjuZnyth6cQzcpCeJImZRocU4tQyAVOqD5aLSs9iZA=; b=eR+hv1kdQbuCXe8mStZzApokKpSxR2aTbjuldVVtSl0bOL5ygTbB1vfuzPoJZuN0+1 524E4lwmjx9JOC2qpRjhuaaHnbODbwEYcjJeGk8hnF4klbAA70286wXJrOGJPeBmrTW5 AAinJ0kSVg4tFfjVe95uLUhpETHN84toyc5DJuMMUwggNnDVL6vFtRfkcr3jc1moYRoH K/sBxsYlZr6tN4BlXzQZW+QqxDwhrgPz8okHUALTEV20WsyDdB0M7aSd4bCOD95dc21j 58cYeCUNj8Y3/ucsQ5fWNY6yOiBu2ruOrb0DWevU1y5iYNq7nwhBy5FPHkdZPUrBGHy+ eAdQ== X-Gm-Message-State: ALoCoQkJ6D8noENNusoCU9cxDZ47Ttrk0P45lWsVwvzrHVuBpO5JVAHUbqyUcfVY34wwKjNabUF+ X-Received: by 10.182.28.99 with SMTP id a3mr13835037obh.18.1431699036602; Fri, 15 May 2015 07:10:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.43.226 with SMTP id z2ls701484obl.37.gmail; Fri, 15 May 2015 07:10:35 -0700 (PDT) X-Received: by 10.182.28.227 with SMTP id e3mr89621obh.33.1431699035865; Fri, 15 May 2015 07:10:35 -0700 (PDT) In-Reply-To: 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:17887 Archived-At: ------=_Part_349_1516250000.1431699035262 Content-Type: multipart/alternative; boundary="----=_Part_350_1572794698.1431699035262" ------=_Part_350_1572794698.1431699035262 Content-Type: text/plain; charset=UTF-8 On Friday, May 15, 2015 at 8:52:09 AM UTC-5, Nicol Bolas wrote: > > On Friday, May 15, 2015 at 9:10:53 AM UTC-4, Michael Boyko wrote: >> >> On Friday, May 15, 2015 at 12:08:04 AM UTC-5, Nicol Bolas wrote: >>> >>> Again, I go back to my lambda vs. function pointer version. People would >>> be very surprised that the version with naked functions works but the >>> lambdas don't. >>> >>> I'm of the opinion that there is no single reasonable standard that >>> works for everyone, or even most people. Different people simply have >>> different equality testing needs when it comes to functors. And if you try >>> to define one standard, what you do is break the class for people who need >>> a different standard. >>> >> >> This might be true and I have pointed out that even removing the functor >> targets leaves 95% of the usefulness intact. My last two companies have >> used this type successfully without any lambda targets. >> > > I'm sure they did. Though since lambdas are relatively new, and this > pseudo-polymorphic function is relatively old, people just find ways to > work around it. That doesn't mean that people *should*. > > After all, lots of people refuse to use std::string or other standard > library classes, instead rolling their own solutions that may have more > limited (or at least different) interfaces than the standard library > versions. Sometimes, these are for very good reasons (iostream). Sometimes, > they aren't. But the fact that they do so *by itself* is not an argument > that something is wrong with the standard library classes. > > If you take functors out of the concept... what's left? It certainly isn't > a polymorphic function object. It's just a function object that could store > a non-member function pointer or a member function pointer+object reference. > > Even the "shared" aspect becomes moot. You can't really claim ownership > over a function pointer. And member pointer bindings are given a pointer to > the type to call, it can't really claim ownership over that pointer either, > since the user may not be transferring said ownership to you. It is a naked > pointer, after all. > > Is there a use for such a limited "polymorphic" function object? Sure. Is > it sufficiently general of a use that it should be standardized? > Saying it another way: fun_ptr = std::function + std::bind + equality comparison - probably functor targets. You question is a fair one. Would such a tool be useful enough to standardize? That's why I've posted it here... -- --- 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_350_1572794698.1431699035262 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, May 15, 2015 at 8:52:09 AM UTC-5, Nicol= Bolas wrote:
On Friday, May 1= 5, 2015 at 9:10:53 AM UTC-4, Michael Boyko wrote:
On Friday, May 15, 2015 at 12:08:04 AM UTC-5, Nicol Bol= as wrote:
Again, I = go back to my lambda vs. function pointer version. People would be very sur= prised that the version with naked functions works but the lambdas don't.
I'm of the opinion that there is no single reasonable standard that w= orks for everyone, or even most people. Different people simply have differ= ent equality testing needs when it comes to functors. And if you try to def= ine one standard, what you do is break the class for people who need a diff= erent standard.

This might be tru= e and I have pointed out that even removing the functor targets leaves 95% = of the usefulness intact. My last two companies have used this type success= fully without any lambda targets.

I'm sure= they did. Though since lambdas are relatively new, and this pseudo-polymor= phic function is relatively old, people just find ways to work around it. T= hat doesn't mean that people should.

After all, lots of peopl= e refuse to use std::string or other standard library classes, instead roll= ing their own solutions that may have more limited (or at least different) = interfaces than the standard library versions. Sometimes, these are for ver= y good reasons (iostream). Sometimes, they aren't. But the fact that they d= o so by itself is not an argument that something is wrong with the s= tandard library classes.

If you take functors out of the concept... = what's left? It certainly isn't a polymorphic function object. It's just a = function object that could store a non-member function pointer or a member = function pointer+object reference.

Even the "shared" aspect becomes = moot. You can't really claim ownership over a function pointer. And member = pointer bindings are given a pointer to the type to call, it can't really c= laim ownership over that pointer either, since the user may not be transfer= ring said ownership to you. It is a naked pointer, after all.

Is the= re a use for such a limited "polymorphic" function object? Sure. Is it suff= iciently general of a use that it should be standardized?

Saying it another way: fun_ptr =3D std::function= + std::bind + equality comparison - probably functor targets.
You question is a fair one. Would such a tool be useful enough= to standardize? That's why I've posted it here...

--

---
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_350_1572794698.1431699035262-- ------=_Part_349_1516250000.1431699035262-- .