220 27399 article Path: news.gmane.org!.POSTED!not-for-mail From: Carl Cook Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Sun, 31 Jul 2016 06:29:29 -0700 (PDT) Lines: 128 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_55_691771595.1469971769382" X-Trace: blaine.gmane.org 1469971793 16904 80.91.229.8 (31 Jul 2016 13:29:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 13:29:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD27VEPGSEGBBO72666AKGQEEKKRK5Y@isocpp.org Sun Jul 31 15:29:39 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTqoE-0004Lc-Ns for gclcip-std-proposals@m.gmane.org; Sun, 31 Jul 2016 15:29:39 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id f123sf190213284ywd.2 for ; Sun, 31 Jul 2016 06:29:38 -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=g4DmyFPhQaNi/N132e80UdiRvBzJmG+FCXq9YX05ZHA=; b=M0t7vXfOQcGANRxBocwIey732EPbgAeYJS6VV8wWj4FeHtT9SYa053E2WIhbHzLa/c HlxpgDFWOLjkqB58AlN/77GiuE6rz+rShJaWLMClrAHMjYe0DzQd3i+A9UHzw831aS54 s5Y+S+Bj2KU64HQtVrW7s1BwFSHsvzqGcEQGLS/iCtMuf9cp0cIAnd8Bu2sEfqtsyGoT YLBsTesj8k4EHKhjQCIsHb2vUeJHdBg4fieqvPQp97TMoCPrHwwwy82kmFVis36ymYxr JESENhE+0UEVlL7q3GpWrBZtrzyZPaOrXLZ/F1HrTp/k6ThQQRy4kPF7m92EmY0MfSMu 59uA== 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=g4DmyFPhQaNi/N132e80UdiRvBzJmG+FCXq9YX05ZHA=; b=OsyX0tR5AyCuJvTp+KRZBwkYqSUnXQ/T3sdKPmhSmrO1JlrI2XFjqKzzzU0LH7NW8C 0+bYmlWoIaErs3ZaVsV/m/Eb68dLzaErqdhV+SKZKtTeH+51ZZiyhKiCGgk5glUnJGQ7 xHEEtZNLYRsxs7mU3jRKUQhco5Oqa7HApwDVKK3h2pOsjiRC+aAHYcS3uFKADo4B/Yg1 P479uE9Rjn8sLS2rABIu4aG+kbhXwEbq0EeNlLPbtc9NJaTe38c0ROMlbOG5NvXKY4U1 0dMvehIFSiRMiAzZ5Q9hHsAr1hTL7RaA0KFulX5tIyuIuLe1YsbiEXr7G316Op9CKW01 ezeA== 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=g4DmyFPhQaNi/N132e80UdiRvBzJmG+FCXq9YX05ZHA=; b=CEsgFEqYpHOdwu10mb6Dktgd8EYJMjtvHXaY1vA6s28VJbQtv5mGE//LuxK7PYMPt8 t1Qn6Rs9lFtLLmPktVT8o4cx3WyQUG8bErnavrOyGjG7sojDFJIV0hVBGNVZwwNq50jZ aRvP2S70zi0o4b7HYtRzJnSh8sr4KGqrRB9d4sN1zFXt6Ve4Ez20qVjhm4BDOsf4OdKt eJ+Ajo4ZBNDGzOmY1a7r5B2M2rsY79+arHeHy4mBBC6aULAhvhCnFQdaM2PEagsvqEp8 HKSJIJJEYhXyryZTv4Ullj5Oqm0M3h8/edIekLt2Q8o+ehDK+3t4iT5wb82O+2u4Ngn8 YPLw== X-Gm-Message-State: AEkoouu2RcAcIWsKsaMcvBsm4MwZE2IA/LB/boH9ryQsSXMneOhhuaS4sV2xG2iRFR611w== X-Received: by 10.13.204.198 with SMTP id o189mr43288122ywd.35.1469971777630; Sun, 31 Jul 2016 06:29:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.20.68 with SMTP id 65ls3334553iou.16.gmail; Sun, 31 Jul 2016 06:29:30 -0700 (PDT) X-Received: by 10.36.108.66 with SMTP id w63mr369379itb.7.1469971770935; Sun, 31 Jul 2016 06:29:30 -0700 (PDT) In-Reply-To: X-Original-Sender: carl.cook@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:27399 Archived-At: ------=_Part_55_691771595.1469971769382 Content-Type: multipart/alternative; boundary="----=_Part_56_44143503.1469971769382" ------=_Part_56_44143503.1469971769382 Content-Type: text/plain; charset=UTF-8 In the example below, I am not passing a function_ref as the return value, I am returning the result of the invocation of that function_ref, which I'd assumed would be safe (i.e. return an integer). However, it is the invocation that has failed, because the compiler has decided that the lambda can already be cleaned up (from what I can tell, looking at the disassembly). So, granted that the function_ref certainly doesn't copy callable objects, but I don't think it's useful for any lambda, unless that lambda is just used to invoke a function (as in the llvm example usage). On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote: > > On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook > wrote: > >> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote: >>> >>> llvm::function_ref doesn't capture anything, and is not supposed to -- >>> it's a *non-owning* handle to a callable that outlives the handle. >>> (llvm::function_ref is to std::function as std::string_view is to >>> std::string.) This is a feature and a design goal of llvm::function_ref, >>> but I think it means it's addressing a fundamentally different problem than >>> the one you're tackling here (which seems to be essentially, "let me >>> control the size and alignment in std::function's small function >>> optimization" >>> >> >> Understood. What caught me out is that compilers can aggressively limit >> the scope of lambdas. Hence I believe the following is not legal usage: >> >> int non_const_var = 0xf; >> function_ref f_ref = [&]() { return non_const_var;}; >> return f_ref(); >> > > Right, it's exactly as broken as this: > > string g() { > string_view s_v = string("blah blah"); > return s_v; > } > > In both cases, you've bound an object with reference semantics to a > (non-lifetime-extended) temporary object. > -- 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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org. ------=_Part_56_44143503.1469971769382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the example below, I am not passing a function_ref as t= he return value, I am returning the result of the invocation of that functi= on_ref, which I'd assumed would be safe (i.e. return an integer).
<= br>
However, it is the invocation that has failed, because the co= mpiler has decided that the lambda can already be cleaned up (from what I c= an tell, looking at the disassembly).

So, granted = that the function_ref certainly doesn't copy callable objects, but I do= n't think it's useful for any lambda, unless that lambda is just us= ed to invoke a function (as in the llvm example usage).

On Friday, 1= 5 July 2016 20:27:56 UTC+2, Richard Smith wrote:
On Fri,= Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com&= gt; wrote:
= On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
= llvm::function_ref doesn't capture anything, and is not supposed to -- = it's a *non-owning* handle to a callable that outlives the handle. (llv= m::function_ref is to std::function as std::string_view is to std::string.)= This is a feature and a design goal of llvm::function_ref, but I think it = means it's addressing a fundamentally different problem than the one yo= u're tackling here (which seems to be essentially, "let me control= the size and alignment in std::function's small function optimization&= quot;

Understood. = What caught me out is that compilers can aggressively limit the scope of la= mbdas. Hence I believe the following is not legal usage:

int non_const_var =3D 0= xf;
function_ref<int()> f_ref =3D [&]() { return non_co= nst_var;};
return f_ref();

Right, it's exactly as broken as this:

string g() {
=C2=A0 string_view s_v =3D s= tring("blah blah");
=C2=A0 return s_v;
}

In both cases, you've bound an object with referen= ce semantics to a (non-lifetime-extended) temporary object.

--
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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad= %40isocpp.org.
------=_Part_56_44143503.1469971769382-- ------=_Part_55_691771595.1469971769382-- .