220 26936 <871t2xqbb5.fsf@gmail.com> article Path: news.gmane.org!not-for-mail From: Moritz Klammler Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Thu, 14 Jul 2016 03:05:02 +0200 Lines: 35 Approved: news@gmane.org Message-ID: <871t2xqbb5.fsf@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1468458313 29688 80.91.229.3 (14 Jul 2016 01:05:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 01:05:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDHI7IWJYALRBQOKTO6AKGQEZ65ZTDI@isocpp.org Thu Jul 14 03:05:07 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNV5O-00022E-C2 for gclcip-std-proposals@m.gmane.org; Thu, 14 Jul 2016 03:05:06 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id g18sf42918345lfg.2 for ; Wed, 13 Jul 2016 18:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:in-reply-to:message-id:user-agent:mime-version :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=OFHaZoqY2v1Q0ALBqCn2GTrLklylfX3UDgUlt5RaRfs=; b=wepWNdLxftrsnYp2S5TXbIZbJspE0wfBwZ07dPEHwujk/E/cAkwN8OwdscTXmhLl2H WFhxsa/8lTHXL66kQRQw+ttz++/piLgu+FJYL/1fq6pQ0rwHZzDWWjACO5RNf/hjL/t4 wpr35MLqHZNGRXbfY1GXzSkum1XQj3SLG8WdyleAsyhqvDdHH4YUhytXwOkYaoGYMkUh zp0WYeT6dvRpUfZiGmmhhVZlMSvLaKkzn8eYfEkeXEDJ5CcUIL7vVohakNjI8GBZXmSK x75QyjMElURA53aRzxZ1hrGGseo8eJ5fWvqqCK3VoC+rVDeYXo7WYe0wjoGKjuxbzOeE Vdlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:in-reply-to:message-id :user-agent:mime-version:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=OFHaZoqY2v1Q0ALBqCn2GTrLklylfX3UDgUlt5RaRfs=; b=JNGKw8w7y0frwkdiUpX3VYeNWJjFWMTkdnOG52BRMSgdqarVufGaDNfsH8aUUhh65w 2UiU8Vsrxh+6LhZB22OI285GPMY9jSeXbtV9UKRELrJ+axMTwcatN0GVt6MXPln6dmGd K16vCwhxxe4ewKqNzXclP0NBhC3mz30VQhv/IkzfiyA8F/Tqy3OcvAmdmmCkyZqiUM+/ QjkLqfmT2+MvSPGKzKYNjahkzVrYq+S3ZKlDQmlBgJDpjqjZhdv8qDIgcaRffXlp7NQ+ vpiDO3PYkQt+DDVxbv27idkEhIW1BVo1aq8hE1Ns3tZMQ9h5rdC+sa+E+yB3/yrko50O kFTA== X-Gm-Message-State: ALyK8tLJuokP57dEtfmmf3YsDw7zFvtlGNx+fqyCgn3/rKmhuioAX5r3DqRiqqOGucBbFw== X-Received: by 10.46.32.69 with SMTP id g66mr1922518ljg.8.1468458305754; Wed, 13 Jul 2016 18:05:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.130.78 with SMTP id e75ls51102wmd.0.canary; Wed, 13 Jul 2016 18:05:04 -0700 (PDT) X-Received: by 10.28.191.143 with SMTP id o15mr597761wmi.13.1468458304701; Wed, 13 Jul 2016 18:05:04 -0700 (PDT) Original-Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com. [2a00:1450:400c:c09::232]) by mx.google.com with ESMTPS id a73si247933wma.36.2016.07.13.18.05.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 18:05:04 -0700 (PDT) Received-SPF: pass (google.com: domain of moritz.klammler@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) client-ip=2a00:1450:400c:c09::232; Original-Received: by mail-wm0-x232.google.com with SMTP id i5so92500788wmg.0 for ; Wed, 13 Jul 2016 18:05:04 -0700 (PDT) X-Received: by 10.194.235.7 with SMTP id ui7mr3199629wjc.14.1468458303990; Wed, 13 Jul 2016 18:05:03 -0700 (PDT) Original-Received: from moritz-laptop (openvpn-cl-200-65.scc.kit.edu. [141.3.200.65]) by smtp.gmail.com with ESMTPSA id r127sm39853975wmf.21.2016.07.13.18.05.02 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Jul 2016 18:05:02 -0700 (PDT) In-Reply-To: D. B.'s message of "Thu\, 14 Jul 2016 00\:26\:31 +0100 \(12 minutes\, 3 seconds ago\)" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Original-Sender: moritz.klammler@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of moritz.klammler@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) smtp.mailfrom=moritz.klammler@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:26936 Archived-At: > 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? -- 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/871t2xqbb5.fsf%40gmail.com. .