220 37726 article Path: news.gmane.org!.POSTED!not-for-mail From: Hamza Sood Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Generic function-wrapper object Date: Mon, 9 Apr 2018 08:36:14 -0700 (PDT) Lines: 207 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23773_924158111.1523288174475" X-Trace: blaine.gmane.org 1523288051 5112 195.159.176.226 (9 Apr 2018 15:34:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2018 15:34:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCP5NIM2SYKRB34QV3LAKGQEA5FPCCA@isocpp.org Mon Apr 09 17:34:07 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f5Yo2-0001CQ-W9 for gclcip-std-proposals@m.gmane.org; Mon, 09 Apr 2018 17:34:07 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id p10sf2954728vki.23 for ; Mon, 09 Apr 2018 08:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=KKJgZfhdXJprXsD+Iuo7Y0l2yM6oUmafW1sgwSdjQsA=; b=M2aLL0dB+/wAEUGgNtSYbIsy/jxvEn85Ama1TDLJPeQErqoxn0R/ybg2u5caTrnVub oNmhwM98lstLimTLB5PnP6pjZPI1UA4k6ubtXPV/h/oXPVDOduGv4LoZrm4ndCrSGfsR lLM6TA/HNAIbd1KsHUnAdPdCqVl7/CcH8HDUGLnfKNUPOa5hYTaXePhwcFidaC86hhXq XLnco0zw90QtONhFpeu1dN9Vgj/almWvAu1i2IaDyAsavhBgaCCdXtNh8G2lxkMmGUxa jpbRVutFHPfjOzenIC1Q63pluBOT/0UPB0PvyDo45wn+Noxtmjd/ECxSqwoKC0QDJeDj ozKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KKJgZfhdXJprXsD+Iuo7Y0l2yM6oUmafW1sgwSdjQsA=; b=q5pHJpXoZSQRMEGiZCgEs9/nCDp1fVl7BT9vBZLC8YnIREu6vddOwkQCW8raEBySEn OfLxeWydrdpxQOLam9JuuNHdhs8w/6G6X+LiXRvFfe8fOwoABr5YqEkfmFZE9x/b581D htp7AZDQE9nY5B85AEdLuf4RKX9v0uQAEnA01YvZAbrXxuY/2wOs2nRngvQOA2KFKT81 llqjwnXGlMEEj1bq26TqF4OT1FzMteYq/zyab8a4lg5ugKJiaG26upG2DFm9zKrXXaWO ruZLLAxh5x3/tV1RYQLFJCZX4+6Y3TfqITlIer/veA1ppJRHPVeKPXzilPcwHK1nC6m1 z/Wg== X-Gm-Message-State: ALQs6tDky55tR5e52u0rDSFYtu+0zkrRHXut0b0D2c6PuIcYVgtA0ljc ZNu/JRTdo+UEFFn4r17tJe3yrA== X-Google-Smtp-Source: AIpwx4+wK8m1/QG88q11cWvCrVFGJvXcoqvK/9Nx0zZBanQOJ/C0wjbnT7vxWz0Q5g0rYgBL72Sa4A== X-Received: by 10.176.112.34 with SMTP id u2mr16644968ual.9.1523288176376; Mon, 09 Apr 2018 08:36:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.48.81 with SMTP id w78ls2664340vkw.19.gmail; Mon, 09 Apr 2018 08:36:15 -0700 (PDT) X-Received: by 10.31.140.138 with SMTP id o132mr4644168vkd.8.1523288174808; Mon, 09 Apr 2018 08:36:14 -0700 (PDT) X-Original-Sender: hamza_sood@me.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:37726 Archived-At: ------=_Part_23773_924158111.1523288174475 Content-Type: multipart/alternative; boundary="----=_Part_23774_1996392239.1523288174476" ------=_Part_23774_1996392239.1523288174476 Content-Type: text/plain; charset="UTF-8" I propose the inclusion of a function object (somewhat similar to the deprecated ptr_fun) that looks something like: template requires is_pointer_v && is_function_v> struct func_ptr { template decltype(auto) operator()(Args&&... args) noexcept(noexcept(f(forward(args)...))) { return f(forward(args)...); } }; The main difference with ptr_fun being that the function pointer is part of the type. *Motivation* The main motivating example is a unique_ptr that needs to call a custom deleter function. Currently (assuming you don't want to write some per-deleter boilerplate), you'd need to do something like: std::unique_ptr ptr(something, myDeleter); This presents a few issues: 1. You don't get to use the default constructor for unique_ptr. Not a big deal but it can be inconvenient. 2. You aren't actually declaring a unique_ptr that calls the myDeleter function, you're declaring a unique_ptr that calls a function pointer with the same signature as the myDeleter function. If the object gets passed around a bit, the compiler won't be able to inline the deletion and you'll probably be left with an indirect call. 3. For the same reason as issue 2, storing the function pointer doubles the size of the object. I believe that: std::unique_ptr> ptr; solves all of those issues. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e2229872-0c8a-4673-b452-602959fc938f%40isocpp.org. ------=_Part_23774_1996392239.1523288174476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I propose the inclusion of a function object (somewhat sim= ilar to the deprecated ptr_fun) that looks something like:

template<<= span style=3D"color: #008;" class=3D"styled-by-prettify">auto f>
requires is_pointer_v<decltype(f)> &&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is_function_v<remove_pointer_t<decltype(f)>>
struct func_ptr {
=C2=A0 template<typename... Args>
=C2=A0 decltype(auto) operator()(Args= &&... args)<= /span> noexcept(noexcept(f(forward<Args>(args)...))) {=
=C2=A0 =C2=A0 return f(forward<Args>(args)...);
=C2=A0 }
};

The main difference with = ptr_fun being that the function pointer is part of the type.



Motivation

The main motivating example is a unique_ptr that need= s to call a custom deleter function. Currently (assuming you don't want= to write some per-deleter boilerplate), you'd need to do something lik= e:
<= code class=3D"prettyprint">
std:= :unique_pt= r<MyType, decltype(&myDeleter)> ptr(something, myDeleter);

= This presents a few issues:
  1. You don't get to use the = default constructor for unique_ptr. Not a big deal but it can be inconvenie= nt.
  2. You aren't actually declaring a unique_ptr that calls the m= yDeleter function, you're declaring a unique_ptr that calls a function = pointer with the same signature as the myDeleter function. If the object ge= ts passed around a bit, the compiler won't be able to inline the deleti= on and you'll probably be left with an indirect call.
  3. For the s= ame reason as issue 2, storing the function pointer doubles the size of the= object.
I believe that:
std::unique_ptr<MyType, std::func_ptr<myDeleter>> ptr;
solves all of those is= sues.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/e2229872-0c8a-4673-b452-602959fc938f= %40isocpp.org.
------=_Part_23774_1996392239.1523288174476-- ------=_Part_23773_924158111.1523288174475-- .