220 17886 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 06:52:09 -0700 (PDT) Lines: 118 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_39_1715243439.1431697929104" X-Trace: ger.gmane.org 1431697959 11527 80.91.229.3 (15 May 2015 13:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 13:52:39 +0000 (UTC) Cc: mash.boyko2014@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBCPU26VAKGQEFQ7IIPY@isocpp.org Fri May 15 15:52:24 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtG26-0002te-SX for gclcip-std-proposals@m.gmane.org; Fri, 15 May 2015 15:52:11 +0200 Original-Received: by qkgw4 with SMTP id w4sf50914201qkg.3 for ; Fri, 15 May 2015 06:52:10 -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=2o+8ObaXRaeUiLvFC1/rhSergOY568UJcunJgDbeXDY=; b=ZnYBe2BE+58Xi7QizoKysZqWIU5Egs6KsxbH5WQbEafl3FWnDgAv6F/SHnh3cioUeZ PAjFXZYzfGmr4OkSBUJFDgEkhWo57f+k9GI8qErOyv8529amWGNXUn//7gPDKaTj1PMG zmzDp91ipPo3C0xeAwfTkq0cOQOsvheGrfuWGdAK+8QjNND+Qq6tuJ3anEqrvZ+QMFBn qFF3FFaJj2lwAwC7z65VMczmu9FJCW7AcfE7gUblLd+jOzw/J4f3A1y3Wudr/+xcZtzm LVThujqTAWvk5OB9Kv0o9Bsia1kb19zFg+KHOz0nG45iojVHNZi43aLK2sFG/Wm/TFYm 7y5A== 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=2o+8ObaXRaeUiLvFC1/rhSergOY568UJcunJgDbeXDY=; b=RVPClTIjeIQvQ0RjJ4N2wToWL4hxm+XNsPJR/CmVhXAVqfbJ+LG2k2WjGDCbQaNyGU EYEo857uBNa3/vRbJ4L6mMWY3pGpt9ZleM4EkPuw7qyxVcgJzqJNboRoGvk46alW8wFP KaXCeX8UNjZd10+zEHqmMbWGHNBe3LrAOMsNFjJOq0MI+H8/mBHEP4eksxhKWFAOw3He cOpE+h+AECIZLENss8qMWdw3XNZeryjcGnbbTZpCyLyaQQfKUQ+VMlHlkuXfiNayg/EK 1As+nF1hAJs0vvoS69HThStzkjcIqE5LBrYDOPZaTJHOBJTHpkNOpnHuySkkCvcSZkXx i7vw== X-Gm-Message-State: ALoCoQnp8W8aLAPiFjXLMz067DRuUwCcX/ccFVw9x0tJrrqFVEhgR/hz3tOMnhY++Nz6NChS5xwq X-Received: by 10.52.7.194 with SMTP id l2mr13362466vda.12.1431697930036; Fri, 15 May 2015 06:52:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.48.9 with SMTP id n9ls1771969qga.58.gmail; Fri, 15 May 2015 06:52:09 -0700 (PDT) X-Received: by 10.140.41.164 with SMTP id z33mr165699qgz.21.1431697929478; Fri, 15 May 2015 06:52:09 -0700 (PDT) In-Reply-To: <4e73f342-66a5-4c73-989b-7a699a8ec512@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:17886 Archived-At: ------=_Part_39_1715243439.1431697929104 Content-Type: multipart/alternative; boundary="----=_Part_40_276001945.1431697929104" ------=_Part_40_276001945.1431697929104 Content-Type: text/plain; charset=UTF-8 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? -- --- 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_40_276001945.1431697929104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, May 15, 2015 at 9:10:53 AM UTC-4, Michael Boyko= wrote:
On Fri= day, May 15, 2015 at 12:08:04 AM UTC-5, Nicol Bolas wrote:
=
Again, I go back to my lambda vs. function poin= ter version. People would be very surprised that the version with naked fun= ctions 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 com= es 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 rem= oving 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 re= latively new, and this pseudo-polymorphic function is relatively old, peopl= e 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 s= tandard library classes, instead rolling their own solutions that may have = more limited (or at least different) interfaces than the standard library v= ersions. Sometimes, these are for very good reasons (iostream). Sometimes, = they aren't. But the fact that they do so by itself is not an argume= nt 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 poly= morphic 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 t= o the type to call, it can't really claim ownership over that pointer eithe= r, since the user may not be transferring said ownership to you. It is a na= ked pointer, after all.

Is there a use for such a limited "polymorph= ic" function object? Sure. Is it sufficiently general of a use that it shou= ld be standardized?

--

---
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_40_276001945.1431697929104-- ------=_Part_39_1715243439.1431697929104-- .