220 26958 <28284ab7-1046-4631-bb4c-f755ce96c2e3@isocpp.org> article Path: news.gmane.org!not-for-mail From: "T. C." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Wed, 13 Jul 2016 22:58:32 -0700 (PDT) Lines: 122 Approved: news@gmane.org Message-ID: <28284ab7-1046-4631-bb4c-f755ce96c2e3@isocpp.org> References: <871t2xqbb5.fsf@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23_1223753247.1468475912469" X-Trace: ger.gmane.org 1468475922 30300 80.91.229.3 (14 Jul 2016 05:58:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 05:58:42 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQ43G7NQIIRBCOUTS6AKGQETBWWSLA@isocpp.org Thu Jul 14 07:58:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNZfV-0001z2-CI for gclcip-std-proposals@m.gmane.org; Thu, 14 Jul 2016 07:58:41 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id j65sf54387246vkb.2 for ; Wed, 13 Jul 2016 22:58:35 -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:in-reply-to:references: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=HcgM0RObxLFsfc8cX5JSWERCgWYvq9koQlajVLSyciU=; b=dPg1zLccHmAivJ8Eo5UhuofXvYg2oz0ZcKO1Iwsbe6hIUO+EUOFzfqD2GrkDRm0PtI 8yxNz7h0H65Lp823FLlBon3/HQsU8/9+nXbkOPFZx2j4pCeJVw3civpxgDDrst02KYDr H2PnAeeJs++QHbH+hTaL7sy/ZYkZdCVfSfa/spday3zA2KrDiy6w0WsXNOuLngqg7/IO nKMBfV8V097QVbO3sG5v9SNvmwZqT80PgRCNmwaJIMQF+lXl36oapPHA/pRqbWO4/FCG l9/zjS0n26kso5Sbbms/RetZRE4XpOTFFngdYZaROKM+lVRtEX8xPeaiVfdr3OktuCFc pdRQ== 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 :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=HcgM0RObxLFsfc8cX5JSWERCgWYvq9koQlajVLSyciU=; b=vxo8jwFLV928nVV1EqN2amV+H5UO6MvYsTUpf4oq3jo5atBJYeEdL8jWbbIwCUbZj/ el87cc3ZF83oXXwG/Fort9cHoeI3c5QM2c8T0YImJweqzTZ2sWmcf7sIX+uClmNCu8P1 TUPFgiQbgblI8Dy1SXsFBu5+n3TEUqAV5QjYrzqk7iJNDJIXuvswWfB36dllFONUCzfa iSIjROzo5DkhXKzwIVL30jYk6E7a6egyaQP7vaXPakDXH344LE/C18c16zakjPBQktJ5 nWnmZlV1KZ0Qec7KC/SFHDus0Kbv9Qf7Zmfpo413XPasHsuDl09YBQbPAlds9HqoGNy2 dQWw== 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: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=HcgM0RObxLFsfc8cX5JSWERCgWYvq9koQlajVLSyciU=; b=BGDlTmwW8WXKDIUnIB+ae1FH+9mz+PzqgiiDxIbpat61eJfSeogvKorfUkz9KGFpTB Z6ydYW+YwvVKV/h1vYp4DUDjVBkX7w3vTKXTrnRWCyLOQGkrEInNctAMmzrbI8Ihe16y NjHYSYGl64QWWbRgFzhuwz7k+tddngKDyEiNDqQI9lNhmxbN7Tueceb2t2eAlbPHFd7y VD3+YRo0fJZ/IuWNQFBnqstTRHLu/aNkSMbY8nJAut1eZTaaV35Jp085tKM8oZ2ZDH45 LorSz6I+gMKsJs64gTBPMvIlulaPfn2hisdOpEa8LiP5Sdvqrho8DfAZ+IfWtQBJkguN 3Iog== X-Gm-Message-State: ALyK8tLI907ilF9ozSHOyFs2+jhVoKj9OWG/W+ADYxQT/ypcw4yutUW4GjRnR15NlMs75w== X-Received: by 10.129.109.150 with SMTP id i144mr6807854ywc.38.1468475915275; Wed, 13 Jul 2016 22:58:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.46.150 with SMTP id u22ls328301iou.42.gmail; Wed, 13 Jul 2016 22:58:33 -0700 (PDT) X-Received: by 10.36.210.213 with SMTP id z204mr854828itf.0.1468475913451; Wed, 13 Jul 2016 22:58:33 -0700 (PDT) In-Reply-To: <871t2xqbb5.fsf@gmail.com> X-Original-Sender: rs2740@gmail.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:26958 Archived-At: ------=_Part_23_1223753247.1468475912469 Content-Type: multipart/alternative; boundary="----=_Part_24_856620174.1468475912469" ------=_Part_24_856620174.1468475912469 Content-Type: text/plain; charset=UTF-8 On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, Moritz Klammler wrote: > > > Very briefly, some of us are interested in having a standardized > > function which does not incur an upfront memory allocation to store > > the callable target, instead opting for a compile time specified > > buffer (stack allocated). This has been quite useful in several low > > latency domains such as gaming and electronic trading. In other words, > > a drop-in replacement for std::function, where all data is on the > > stack. > > Isn't this already possible by using today's `std::function` with a > custom allocator backed by a stack-based array? The only thing this > solution cannot easily do for you is checking statically that the buffer > is large enough but since the size of an object is a constant, a single > unit test that passes control flow through the creation of the > type-erased function object would give that assurance to you. > > `std::function` type-erases the allocator as well but I'd be very > disappointed if this would mean a heap allocation for a simple stack > allocator with a state as small as two pointers. I'm not able to point > to a source that confirms this, though. > > It's likely that if you care about `std::function` not calling `malloc`, > you probably care about small (but still too large for SSO) and > short-lived strings and similar stuff, too. Custom allocators provide a > uniform interface to this without having to re-implement each type as a > stack-based alternative. > > Am I missing something essential that your proposed > `std::inplace_function` can do in addition? > The allocator support in std::function has been zapped as of three weeks ago. Also, passing such a thing around is trickier since the array's lifetime is independent of the std::function. -- 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/28284ab7-1046-4631-bb4c-f755ce96c2e3%40isocpp.org. ------=_Part_24_856620174.1468475912469 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, M= oritz Klammler wrote:
> Very= briefly, some of us are interested in having a standardized
> function which does not incur an upfront memory allocation to stor= e
> the callable target, instead opting for a compile time specified
> buffer (stack allocated). This has been quite useful in several lo= w
> latency domains such as gaming and electronic trading. In other wo= rds,
> a drop-in replacement for std::function, where all data is on the
> stack.

Isn't this already possible by using today's `std::function` wi= th a
custom allocator backed by a stack-based array? =C2=A0The only thing th= is
solution cannot easily do for you is checking statically that the buffe= r
is large enough but since the size of an object is a constant, a single
unit test that passes control flow through the creation of the
type-erased function object would give that assurance to you.

`std::function` type-erases the allocator as well but I'd be very
disappointed if this would mean a heap allocation for a simple stack
allocator with a state as small as two pointers. =C2=A0I'm not able= to point
to a source that confirms this, though.

It's likely that if you care about `std::function` not calling `mal= loc`,
you probably care about small (but still too large for SSO) and
short-lived strings and similar stuff, too. =C2=A0Custom allocators pro= vide a
uniform interface to this without having to re-implement each type as a
stack-based alternative.

Am I missing something essential that your proposed
`std::inplace_function` can do in addition?

The allocator support in std::function= has been zapped as of three weeks ago.=C2=A0

Also= , passing such a thing around is trickier since the array's lifetime is= independent of the std::function.

--
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/28284ab7-1046-4631-bb4c-f755ce96c2e3= %40isocpp.org.
------=_Part_24_856620174.1468475912469-- ------=_Part_23_1223753247.1468475912469-- .