220 29641 <5e1a340a-ba02-4b4e-8ea4-4017f946c443@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Use stateless lambdas without capturing Date: Sat, 3 Dec 2016 16:07:40 -0800 (PST) Lines: 113 Approved: news@gmane.org Message-ID: <5e1a340a-ba02-4b4e-8ea4-4017f946c443@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2802_1009465092.1480810060129" X-Trace: blaine.gmane.org 1480810063 29276 195.159.176.226 (4 Dec 2016 00:07:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Dec 2016 00:07:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIM3PENYICRUBHFQ7R4C@isocpp.org Sun Dec 04 01:07:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDKLB-00073q-VP for gclcip-std-proposals@m.gmane.org; Sun, 04 Dec 2016 01:07:38 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id y68sf454459996pfb.6 for ; Sat, 03 Dec 2016 16:07:42 -0800 (PST) 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=NnosJvJdKj0Z3079q8f0aSV4X8HDZrIhQgA1m//VVsw=; b=y1mnHJLog9hResn7hsoOb9rdzCYh1vDzSZeAFV6XsWPxnb71SS9klz6SOjGljPBJtc JeLUIWaxWkl2hrLLABlYm7Lzpd9rIMj8SI5UxRtSj7N6QZHy7LcQ8GJKE8sfzhpNICVs 4cmIXwXG/5wvIS1nHkGKCgWQrTQxQuCI/5FpdEMPooYRBZt3Gf0+XeibsXrDz30RzEut 1QKAWT0c5wQSt6JXVmW8gAmOKtz7DFy8eiiq4m2bs7x9b4b7G/FaSPgsaURE55qjjl6j dyglI7pUXu6hftIv5+Od0wZPW1Cb26eZ0tlAoRRiwEwza2mgNeDSLjpLptw2RXtsIjOy lDXQ== 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=NnosJvJdKj0Z3079q8f0aSV4X8HDZrIhQgA1m//VVsw=; b=PFXHA+9amiL1jHziOW1+gzaSO9x4ooW2GdcrgxFrnH0eq0ncaZmKKGbhvFvpd4/lXG 1f9Kj51eAVjdH3KmGoUJCyh3BnS2JJm8OnLp3n4E4AoEdZhe0HaUBN+ZhZboQLmgo+fg NIaveVqvLJ1MjKhn7XYHq9BK2KuACAX03+qtOD6iStEXpvSMghB1LnL6d2BPJNcr+hel UAT8V4L+IJLferDS0XofZQPeKIxE91TfQWxhNAJWr0HP+zYhz/jAVAruc3pWEXwgsAfl e8zRBN0eW/8yXrPpuFXoF16HTsvqPvsdFYLg1OH33k0y+2xaz8qHWhOYmZNLcDqx3Wnw C/zA== 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=NnosJvJdKj0Z3079q8f0aSV4X8HDZrIhQgA1m//VVsw=; b=Ad64fyVLLSbSZ7l3ErUcDEmUVZp8gKieyHcrR+gsoObAgQ8VbJqaWeEhRnLOd7g1TO OKXChhVb8BpcHYuwEpjzSHBHLR9CEl3KI1CUCbn/leaD/U54ylO2X0gjwbofsYeD5F6d HhFyf4TX+AQSguT/5gEiIkuowLUAUaIXCwMrWSg/PN0mxlfRutK+j3Ai0FZjDcqqPTnA y2/MdwzpdsPETcq0A5jzcBBa3ztyhsGg/J4daraP2+XtCXrxyvb1q30go7xJ3pLQeYvQ HhqskUww7rCO7mPIaoKjhl3z/DVQcN6Ye0O+Q/0YkN/e/1pYQLTvrcF0orq5Z8UX7pDG FwTw== X-Gm-Message-State: AKaTC01snNt3+Hs5zYwMadFzk2FVqy4xWSyxmIuyubO5vJUHLLDhT17OHmUR4zP7OTMNhQ== X-Received: by 10.99.171.8 with SMTP id p8mr24857347pgf.165.1480810061600; Sat, 03 Dec 2016 16:07:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.137 with SMTP id y9ls22335578otd.39.gmail; Sat, 03 Dec 2016 16:07:40 -0800 (PST) X-Received: by 10.157.37.247 with SMTP id q110mr3446931ota.5.1480810060827; Sat, 03 Dec 2016 16:07:40 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@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:29641 Archived-At: ------=_Part_2802_1009465092.1480810060129 Content-Type: multipart/alternative; boundary="----=_Part_2803_1225758799.1480810060129" ------=_Part_2803_1225758799.1480810060129 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, December 3, 2016 at 11:01:02 AM UTC-8, Klaim - Jo=C3=ABl Lamot= te=20 wrote: > > On 3 December 2016 at 12:47, David Krauss = >=20 > wrote: > >> int main() { >> auto a =3D []{ return 5; }; >> auto b =3D []{ +a; a(); }; // Error, =E2=80=9Ca=E2=80=9D not capture= d. >> } >> > > I tend to just make `a` static const in these cases. Not esoteric and=20 > makes perfect sense and don't need to capture. > Right. In fact, you shouldn't even need "const", since the compiler is=20 perfectly capable of seeing that "a" is unused except for its operator(). GCC 4.9.0+ get it exactly right : it realizes= =20 that "a" and "b" both have trivial constructors, so no code need be=20 generated at all. Clang 3.9 currently does a *terrible* job of optimizing here; it fails to= =20 omit the guard variable even for "static const auto a" =E2=80=94 so not onl= y does=20 Clang generate a non-zero amount of code for this example, the code it=20 *does* generate is full of function calls and atomic memory accesses! Intel ICC 17 performs equivalently to Clang: *terrible* codegen. Anyway, this seems like a Quality of Implementation issue, not a defect in= =20 the language. HTH, =E2=80=93Arthur --=20 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 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/5e1a340a-ba02-4b4e-8ea4-4017f946c443%40isocpp.or= g. ------=_Part_2803_1225758799.1480810060129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, December 3, 2016 at 11:01:02 AM UTC-8, Klaim = - Jo=C3=ABl Lamotte wrote:
On 3 December 2016 at 12:47, David Krauss &l= t;pot= ....@gmail.com> wrote:
int main() {
=C2=A0= =C2=A0 auto a =3D []{ return 5; };
=C2=A0 =C2=A0 auto b =3D []{ +a; a(); }; // Error, =E2=80=9Ca=E2=80=9D not= captured.
}

I tend to just make `a` static const in these = cases. Not esoteric and makes perfect sense and don't need to capture.<= /div>

Right. In fact, you= shouldn't even need "const", since the compiler is perfectly= capable of seeing that "a" is unused except for its operator().<= /div>
GCC 4.9.0+=C2=A0get it e= xactly right: it realizes that "a" and "b" both hav= e trivial constructors, so no code need be generated at all.
Clan= g 3.9 currently does a terrible job of optimizing here; it fa= ils to omit the guard variable even for "static const auto a" =E2= =80=94 so not only does Clang generate a non-zero amount of code for this e= xample, the code it does generate is full of function calls and atom= ic memory accesses!
Intel ICC 17 performs equivalently to Cla= ng: terrible codegen.

Anyway, this s= eems like a Quality of Implementation issue, not a defect in the language.<= /div>

HTH,
=E2=80=93Arthur

--
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/5e1a340a-ba02-4b4e-8ea4-4017f946c443= %40isocpp.org.
------=_Part_2803_1225758799.1480810060129-- ------=_Part_2802_1009465092.1480810060129-- .