220 27451 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Mon, 1 Aug 2016 09:23:36 -0700 Lines: 183 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114a6e3ac4e232053905057e X-Trace: blaine.gmane.org 1470068624 30326 195.159.176.226 (1 Aug 2016 16:23:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2016 16:23:44 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBC7P7W6AKGQEMA5CYKQ@isocpp.org Mon Aug 01 18:23:40 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUG0B-0007cn-Od for gclcip-std-proposals@m.gmane.org; Mon, 01 Aug 2016 18:23:39 +0200 Original-Received: by mail-wm0-f70.google.com with SMTP id p129sf85518754wmp.3 for ; Mon, 01 Aug 2016 09:23:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender: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=mPWf7J2H/8MKqRgR+dv6wOIFVUrGhW7QJOafgc68ASM=; b=GFS0q9cKYYtb/cwtz5tuZrI1Qspf+447EbXE9o4z8/KO0A5w9mbPq2mFo0XbsKDpcW ZPFufmniGUtqYbZDMsbRJfmrwz42xKpWKCZF/iIPD+YEox0H2VuCj2JDJU6cYhe0FeyZ JvrItNwv/e5/rMwVMDzQXVBJuYhsLToEZNDaE9QrADYCswnFOkusPy5E71f6H0f8hxmv 9gL2Vl/m8ZcIAntDxj3pENLW78cNtuhICGYNu7lGpQfQMG69sFAyYBDb4erudb1OrZrR LWH8Slhr7IRBUAAOgClPqUDMo+3M/N6yXwnyKGNsvQd0YBmnJSrpe64DE8j/+R4jGWgF ODPQ== X-Gm-Message-State: AEkoouuuBNg6OYgVTR0WQm4gayrX1MT1h2RBRl9oqdyWCcNVYBAi2o8KCZY4Q6JzK1H5kQ== X-Received: by 10.25.152.204 with SMTP id a195mr8031743lfe.9.1470068619869; Mon, 01 Aug 2016 09:23:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.27.77 with SMTP id b74ls386524lfb.7.gmail; Mon, 01 Aug 2016 09:23:38 -0700 (PDT) X-Received: by 10.25.42.207 with SMTP id q198mr15494609lfq.181.1470068618593; Mon, 01 Aug 2016 09:23:38 -0700 (PDT) Original-Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com. [2a00:1450:4010:c07::22c]) by mx.google.com with ESMTPS id 203si14799603lfk.33.2016.08.01.09.23.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 09:23:38 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2a00:1450:4010:c07::22c as permitted sender) client-ip=2a00:1450:4010:c07::22c; Original-Received: by mail-lf0-x22c.google.com with SMTP id f93so119398625lfi.2 for ; Mon, 01 Aug 2016 09:23:38 -0700 (PDT) X-Received: by 10.46.5.201 with SMTP id 192mr17872218ljf.10.1470068617960; Mon, 01 Aug 2016 09:23:37 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.25.142.137 with HTTP; Mon, 1 Aug 2016 09:23:36 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2a00:1450:4010:c07::22c as permitted sender) smtp.mailfrom=metafoo@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:27451 Archived-At: --001a114a6e3ac4e232053905057e Content-Type: text/plain; charset=UTF-8 On Sun, Jul 31, 2016 at 6:29 AM, Carl Cook wrote: > 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). > Actually, the above is exactly analogous to what happens in the string_view case. Note that I'm returning a string, not a string_view. In both cases, the problem happens in the construction of the string_view/function_ref object: we're constructing an object that represents a handle to another object, and the other object is a temporary object that goes away at the end of the full-expression. And then on the second line, we do something that tries to access the now-destroyed object through the handle (in the string_view case, we construct a string from the string_view, and in the function_ref case, we attempt to call the destroyed closure object). This is just how handle-like objects behave when bound to temporaries, and not specific to string_view or function_ref. > 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 > > . > -- 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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com. --001a114a6e3ac4e232053905057e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 31, 2016 at 6:29 AM, Carl Cook <carl.cook@gmail.com> wrote:
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 w= ould be safe (i.e. return an integer).

However, it is th= e invocation that has failed, because the compiler has decided that the lam= bda can already be cleaned up (from what I can tell, looking at the disasse= mbly).

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

Ac= tually, the above is exactly analogous to what happens in the string_view c= ase. Note that I'm returning a string, not a string_view.
In both cases, the problem happens in the construction of the s= tring_view/function_ref object: we're constructing an object that repre= sents a handle to another object, and the other object is a temporary objec= t that goes away at the end of the full-expression. And then on the second = line, we do something that tries to access the now-destroyed object through= the handle (in the string_view case, we construct a string from the string= _view, and in the function_ref case, we attempt to call the destroyed closu= re object).

This is just how handle-like objects b= ehave when bound to temporaries, and not specific to string_view or functio= n_ref.
=C2=A0
On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> 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-own= ing* 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 addr= essing a fundamentally different problem than the one you're tackling h= ere (which seems to be essentially, "let me control the size and align= ment in std::function's small function optimization"

Understood. What caught me out = is that compilers can aggressively limit the scope of lambdas. Hence I beli= eve the following is not legal usage:

int non_const_var =3D 0xf;
fun= ction_ref<int()> f_ref =3D [&]() { return non_const_var;};
<= div>return f_ref();
<= br>
Right, it's exactly as broken as this:

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

<= div>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 &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail 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.

--
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/CAOfiQq%3DK= %2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com.
--001a114a6e3ac4e232053905057e-- .