220 27009 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Fri, 15 Jul 2016 02:11:06 +0300 Lines: 62 Approved: news@gmane.org Message-ID: References: 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 1468537876 29950 80.91.229.3 (14 Jul 2016 23:11:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 23:11:16 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC5JHI7A7ALRBC5YUC6AKGQEALUFUCY@isocpp.org Fri Jul 15 01:11:15 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNpmk-000085-4E for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 01:11:14 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id u25sf181786718ioi.1 for ; Thu, 14 Jul 2016 16:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=GU+yafYOal1PfTHZQ2751ahkoFDjytkXeW22mcK6mj4=; b=V9Sa1uW9j8/RMZ4/ZUulpFMbhS2OGAi6x7F0ixvczojZMKtQd6WGkM7t9BjutteEa2 8OvAaFZ5kbS6US16eXdvOCgyEJGBRXuXrUs9kUkVXeEyPCCtRK51Wcc2eSHvz2ZsYHcd CaVrQCL/lYBj+ntrcJnTgcTKWJhioSiCzMKYer0khfp+nQ6dWa+DGoSkHVl2ILpydRFC qDXANDCPKDCN7EBuM3gf9EiAxfg+uPvPv3Xhccq0Fjdo0qAQgz0XkNKTSu4AmVVcMWzx yVBkrVhfnkXjhgZZSgU+P6G5fKZmxEkp6k2AL4u+AHxdvgtPiS4ZYWgccmsQMQIYC2Bt +nrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=GU+yafYOal1PfTHZQ2751ahkoFDjytkXeW22mcK6mj4=; b=EGKWKgTwVbyyeCUjxVCOxmbYj2JCoifPL10J1E6c5PeM1qcMqQFl1L/kAH1Cv/u8To K50LW4YJvK5W6fCIt5nWe/dsCzT8NTgy11LRTkptDf0gbR6jQr3J/vE24LIJqsw0oJCb WklbH3VqOVDNCOAideg5zyBQE0GGgzO5AIakxLDzMVbuUvaukZ1tV4dMqrxfK219oVTS wH2W/MRBI4Uvsl8+Y1iRq+Ztas3BRH+rOfKiyRt1G+xI+bMKBpjj9WDecH/K8HHgzMbe 8i/a3nk/RoGxmvb7ERdHMFVVDU9kKY0lQR5NVe5zKu+BnhsDJ4JzUPw2QhVkMSinGorh ByFQ== X-Gm-Message-State: ALyK8tI7N9YmV/Bc85OjZZVW8meq5hVDkSn6LZ7hGfFtGVVzE8GReopp4rJdb8+zb6Xntg== X-Received: by 10.157.43.146 with SMTP id u18mr12769258ota.39.1468537868226; Thu, 14 Jul 2016 16:11:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.37.245 with SMTP id q108ls2576974ota.2.gmail; Thu, 14 Jul 2016 16:11:07 -0700 (PDT) X-Received: by 10.31.151.133 with SMTP id z127mr4588660vkd.138.1468537867468; Thu, 14 Jul 2016 16:11:07 -0700 (PDT) Original-Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com. [2607:f8b0:400c:c05::22b]) by mx.google.com with ESMTPS id d203si1344713vke.76.2016.07.14.16.11.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 16:11:07 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400c:c05::22b as permitted sender) client-ip=2607:f8b0:400c:c05::22b; Original-Received: by mail-vk0-x22b.google.com with SMTP id x130so132932436vkc.0 for ; Thu, 14 Jul 2016 16:11:07 -0700 (PDT) X-Received: by 10.176.69.180 with SMTP id u49mr8372771uau.24.1468537867091; Thu, 14 Jul 2016 16:11:07 -0700 (PDT) Original-Received: by 10.103.76.91 with HTTP; Thu, 14 Jul 2016 16:11:06 -0700 (PDT) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400c:c05::22b as permitted sender) smtp.mailfrom=ville.voutilainen@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:27009 Archived-At: Here's my 2 cents: On 15 July 2016 at 01:56, Carl Cook wrote: > Hi all, > > Thanks very much for the feedback so far, this is exactly what I was looking > for. > > Below are my responses to the questions raised. Please let me know if I > haven't answered concisely enough, or have misunderstood the comments. > > Is this too specialized for the standard library? Should this be in a > TR/boost/extension only? > > This is the most important comment in my opinion, and the driver for this > proposal - to determine the level of support > Possibly it should be kept out of the standard. Here we are talking about > introducting a whole new type, plus optionally specifying buffer > sizes/alignment, just to save an allocation > On the flip side, it's actually more than an allocation. It's cache > locality, potential to prefetch, deterministic performance, etc > This leads on to a bigger question - should low latency/high performance be > a concern of the standard library? > > I would argue yes, as industries such as finance/games/image > processing/aerospace represent a large set of C++ users, and low latency > requirements are a reality It's also not just about latency. There are environments where subsystems have fixed pools, and not being able to exactly control what and how much gets allocated and from where is unacceptable. Controlling it with an in-place buffer works in quite many cases. > > How to determine the correct buffer size, at all times? > > You can't. For that, fall back to std::function > In reality, inplace_function will only be used in specialized cases, and for > that you will have a good idea of the size of the callable object > > If your size is too conservative, the static assert will tell you what size > you should have used > > Also, from experience, the implementation's default size is fine 90% of the > time Fantastic, that solves quite many practical problems I've seen in this area. Fail to compile rather than fail to allocate at run-time. > > Why not consider a custom allocator? Because that's a much more complex solution than a fixed in-place buffer. ;) -- 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/CAFk2RUY%2B8fSwVvw1SJOgvF52AcX9MWZm9RKzgEQN7fmnCNDhaw%40mail.gmail.com. .