220 27407 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 16:25:44 +0200 Lines: 191 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/alternative; boundary=001a11443c786687530538ef4216 X-Trace: blaine.gmane.org 1469975177 27586 80.91.229.8 (31 Jul 2016 14:26:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 14:26:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD27VEPGSEGBB3EU7C6AKGQEH3ABMHI@isocpp.org Sun Jul 31 16:25:56 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTrgf-00073Z-NI for gclcip-std-proposals@m.gmane.org; Sun, 31 Jul 2016 16:25:53 +0200 Original-Received: by mail-lf0-f72.google.com with SMTP id 33sf60935180lfw.1 for ; Sun, 31 Jul 2016 07:25:53 -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=fmZTHQgKM/pclqScCNQBRVF9ZHyI4yMEQl5l+41Phjo=; b=LawafLge3BWqw9Pl5NmX0t3XZArZ6x9l02zPBOYV7MWv0b3C0EcKSfJJJhXVXzyYai d3uhsNoNc1p9KqBMYpvg3av5URt1dAis70ZX9OQ7hbJdjCTkFZtDiZP6MVq8/JSDoDtJ n1QOhVHNbpX12oz4oQsCYL+1/qa9TBZJjGz90mJ+lGeCkTSut82Kq2scZ+UQcfP1EkYJ DL/t9b9BooGtkgzLYxHC3MuG4vkZJ4ehzrojKBXCZk8GDrsImK9Mk+ydbG6AIog7Vn0C yoMk2r4HVcIjgVYyJgEM8kq2dEBeplalbDn1cd7rS9UOCxgHbpuikMRTSJBAlJfdJt8m g00Q== 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=fmZTHQgKM/pclqScCNQBRVF9ZHyI4yMEQl5l+41Phjo=; b=N5KaLSKSqHeqi5BsJa1XndabPPUYDzRVeE0GRZKzPQpcwJ6ZZclmTOLyt3RG4fk0KM K32nzrnPvAJLImBMy4tX6PU7WHyuphs26HqjDeu1eljYX+LfAR4hVoojyzrrqHoRUkJu K6Ib17N3ukrmMI5sGnSFDlJDfDorpLYEP4KeGzHkO4xawP4LaVJnNkEzTYVLELO+FYCC ef9P/gR6xIbJ98Lpd1CeB6ieXwR72mg2TUhXSVNejO6/KXyx2qpqDxBhtI1Tli3bRB/7 oMkqywvNgVJ/DmHWXAxcKyTmDnYq0DJZGOTHF1orFd7Se/3W7xiQHEo3rj1TmlTh4Q1T /RiQ== X-Gm-Message-State: AEkoouuvMItYHt+rgqOU7VJkezOehSUaqqz9Xyi/h7/vBmeRe7xQ6NRf6DFKsjd5vQJRWw== X-Received: by 10.46.1.25 with SMTP id 25mr7262554ljb.10.1469975153378; Sun, 31 Jul 2016 07:25:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.70.130 with SMTP id t124ls1342895wma.16.gmail; Sun, 31 Jul 2016 07:25:47 -0700 (PDT) X-Received: by 10.195.12.111 with SMTP id ep15mr45636985wjd.124.1469975146311; Sun, 31 Jul 2016 07:25:46 -0700 (PDT) Original-Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com. [2a00:1450:400c:c09::22e]) by mx.google.com with ESMTPS id z13si27426315wjr.64.2016.07.31.07.25.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jul 2016 07:25:46 -0700 (PDT) Received-SPF: pass (google.com: domain of carl.cook@gmail.com designates 2a00:1450:400c:c09::22e as permitted sender) client-ip=2a00:1450:400c:c09::22e; Original-Received: by mail-wm0-x22e.google.com with SMTP id o80so210741660wme.1 for ; Sun, 31 Jul 2016 07:25:46 -0700 (PDT) X-Received: by 10.28.51.21 with SMTP id z21mr53974534wmz.24.1469975145906; Sun, 31 Jul 2016 07:25:45 -0700 (PDT) Original-Received: by 10.194.178.99 with HTTP; Sun, 31 Jul 2016 07:25:44 -0700 (PDT) Original-Received: by 10.194.178.99 with HTTP; Sun, 31 Jul 2016 07:25:44 -0700 (PDT) In-Reply-To: X-Original-Sender: carl.cook@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of carl.cook@gmail.com designates 2a00:1450:400c:c09::22e as permitted sender) smtp.mailfrom=carl.cook@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:27407 Archived-At: --001a11443c786687530538ef4216 Content-Type: text/plain; charset=UTF-8 Understood, thanks. Hence llvm::function_ref really is what it says. I.e. don't use it beyond references to functions. On 31 Jul 2016 16:15, "Casey Carter" wrote: On Sunday, July 31, 2016 at 6:29:30 AM UTC-7, 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). > > 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. >> > [&]() { return non_const_var;}; is an expression whose value is a temporary object. That temporary object is destroyed at the end of the full expression function_ref f_ref = [&]() { return non_const_var;}; Using the reference stored in f_ref to access that object after the end of its lifetime results in undefined behavior. -- You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8/unsubscribe .. To unsubscribe from this group and all its topics, 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/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%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/CAGa0LWtm1z9Ysynmfa8L2G%3D7_aFn7YcSbpBHSYPDkuuR1qh4OA%40mail.gmail.com. --001a11443c786687530538ef4216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Understood, thanks. Hence llvm::function_ref really is what = it says. I.e. don't use it beyond references to functions.


On 31 Jul 2016 16= :15, "Casey Carter" <car= tec69@gmail.com> wrote:
On Sunday, July 31, 2016 a= t 6:29:30 AM UTC-7, 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 funct= ion_ref, which I'd assumed would be safe (i.e. return an integer).
=
However, it is the invocation that has failed, because the c= ompiler 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 d= on't think it's useful for any lambda, unless that lambda is just u= sed 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 <c= arl...@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-owning* handle to a callable that out= lives the handle. (llvm::function_ref is to std::function as std::string_vi= ew is to std::string.) This is a feature and a design goal of llvm::functio= n_ref, but I think it means it's addressing a fundamentally different p= roblem 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 usa= ge:

i= nt non_const_var =3D 0xf;
function_ref<int()> f_ref =3D [&a= mp;]() { return non_const_var;};
return f_ref();

Right, it's exactl= y as broken as this:

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

In both cases, you've bound = an object with reference semantics to a (non-lifetime-extended) temporary o= bject.
[&]() { return= non_const_var;}; is an expression whose value is a temporary object= .. That temporary object is destroyed at the end of the full expression
function_ref<int()> f_ref =3D = [&]() { return non_const= _var;};
<= /div>
Using the reference stored= in f_ref to access that object after the end of its lifetime results in un= defined behavior.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/ee95d8af-e8e9-= 47bc-9d61-d95551aac4f3%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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWtm1z9Ysy= nmfa8L2G%3D7_aFn7YcSbpBHSYPDkuuR1qh4OA%40mail.gmail.com.
--001a11443c786687530538ef4216-- .