220 27453 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: Mon, 1 Aug 2016 18:26:35 +0200 Lines: 231 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=001a1145b52c72ec8e0539051045 X-Trace: blaine.gmane.org 1470068803 30024 195.159.176.226 (1 Aug 2016 16:26:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2016 16:26:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD27VEPGSEGBBPXQ7W6AKGQEQGTCCDI@isocpp.org Mon Aug 01 18:26:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUG34-0007Yu-EX for gclcip-std-proposals@m.gmane.org; Mon, 01 Aug 2016 18:26:38 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id p129sf85564780wmp.3 for ; Mon, 01 Aug 2016 09:26:38 -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=bEsZb0cBdURzc1xMR0P/Kw2s0+gLCsYDIf90C8cfErg=; b=FowvBK52by+b3lsOdudtjzpu5stgBnu+9GfTvG3iWc50Yh5LxF6vyvV8tR3+XPVtBT 1uybU+R0Pzf83sjEp8MZBYgqS45jP0JiWsrzSpsppIQtmcptj6nWGsOCCKIZViIvd8oa i7YRXJfUA7dPjF9snKadX5PNkbR65Oy7aRhfJSNssk7pGIUinRaYmfLxJ3McIsclp1K+ OVqbs/lR0wFjfFpbJ4bqEOYOO6NT8FT+JCLTI25O1t9sSyCcvRr38gCzMTmksgxu3zWx vmJkZy7P0EnN2ZYnYwvRJHw2fb+ydMgtaXEY34Y6wmyFOQN4/Zt7hLLdb7BMuWrIQhQ1 lejw== 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=bEsZb0cBdURzc1xMR0P/Kw2s0+gLCsYDIf90C8cfErg=; b=mLBZqGOMZm4lR3V69vnr8VQJr5rnbuOW4O1HKcZx8olXacmB5YY/bhlvFnF4orXfHV 4/TwuTOlLFPCebBWpeD5N75pxOvtIBJVBHW9pgnVI/uJHvGj43mCmgNDPMqFbyK1Ms3S /uGg0mt5ElpwLHpy4VnAMyN09/NBM1M2JF+haLfHHT1Sn5u9hpGvZAAmK6fI6IuvXepg VMRcrCA2gQj07TFfcjlusrZKQi6Tr1QvUKurhLp4JN06s0KbEvBDBuBTlXdKpqbWA92S aiP5ViGq3VhVFe7AtO5f7AZO131xDxP6S/TpoQFvezLEI/R2hsljOxcuMVPtFj2Hx6Gt oA4A== X-Gm-Message-State: AEkooutsgDCTqxu3OrZP0mQr6SvAVeG8+Zdvcj2cmlEGilaiD2YB49Zb5nN30Fob5Drk2w== X-Received: by 10.28.203.3 with SMTP id b3mr7969016wmg.3.1470068798566; Mon, 01 Aug 2016 09:26:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.196.15 with SMTP id u15ls568324wmf.10.canary; Mon, 01 Aug 2016 09:26:37 -0700 (PDT) X-Received: by 10.194.28.5 with SMTP id x5mr50533209wjg.11.1470068797542; Mon, 01 Aug 2016 09:26:37 -0700 (PDT) Original-Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com. [2a00:1450:400c:c09::230]) by mx.google.com with ESMTPS id mn7si32227113wjc.177.2016.08.01.09.26.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 09:26:37 -0700 (PDT) Received-SPF: pass (google.com: domain of carl.cook@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) client-ip=2a00:1450:400c:c09::230; Original-Received: by mail-wm0-x230.google.com with SMTP id o80so252389129wme.1 for ; Mon, 01 Aug 2016 09:26:37 -0700 (PDT) X-Received: by 10.28.20.139 with SMTP id 133mr15745904wmu.78.1470068797137; Mon, 01 Aug 2016 09:26:37 -0700 (PDT) Original-Received: by 10.194.178.99 with HTTP; Mon, 1 Aug 2016 09:26:35 -0700 (PDT) Original-Received: by 10.194.178.99 with HTTP; Mon, 1 Aug 2016 09:26:35 -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::230 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:27453 Archived-At: --001a1145b52c72ec8e0539051045 Content-Type: text/plain; charset=UTF-8 I didn't spot that you are indeed returning a string. My mistake. Thanks, yes now I see that your example holds perfectly. On 1 Aug 2016 18:23, "Richard Smith" wrote: > 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 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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com > > . > -- 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/CAGa0LWsUjCP5j8ra_F1mZczRXjdwgkhhFdOLDYS7Jm982v4iyQ%40mail.gmail.com. --001a1145b52c72ec8e0539051045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I didn't spot that you are indeed returning a string. My= mistake. Thanks, yes now I see that your example holds perfectly.


On 1 Aug 2016 18:= 23, "Richard Smith" <= richard@metafoo.co.uk> wrote:
On Sun, Jul 31, 2016 at 6:29 AM, Carl Cook &= lt;carl.cook@gmail= ..com> wrote:
In the example below, I am not passing a function_ref as the return valu= e, 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 dec= ided that the lambda can already be cleaned up (from what I can tell, looki= ng at the disassembly).

So, granted that the funct= ion_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_vi= ew.

In both cases, the problem happens in the cons= truction 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 th= en on the second line, we do something that tries to access the now-destroy= ed object through the handle (in the string_view case, we construct a strin= g from the string_view, and in the function_ref case, we attempt to call th= e destroyed closure object).

This is just how hand= le-like objects behave when bound to temporaries, and not specific to strin= g_view or function_ref.
=C2=A0
On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smi= th wrote:
On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> wr= ote:
On Friday, 15= July 2016 02:35:42 UTC+2, Richard Smith wrote:
llvm::functio= n_ref doesn't capture anything, and is not supposed to -- it's a *n= on-owning* handle to a callable that outlives the handle. (llvm::function_r= ef is to std::function as std::string_view is to std::string.) This is a fe= ature 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 tack= ling here (which seems to be essentially, "let me control the size and= alignment in std::function's small function optimization"

Understood. What caught m= e out is that compilers can aggressively limit the scope of lambdas. Hence = I believe the following is not legal usage:

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

Right, it's exactly as broken as this:

=
string g() {
=C2=A0 string_view s_v =3D string("b= lah blah");
=C2=A0 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 &= 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 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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail= ..gmail.com.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWsUjCP5j8ra= _F1mZczRXjdwgkhhFdOLDYS7Jm982v4iyQ%40mail.gmail.com.
--001a1145b52c72ec8e0539051045-- .