220 14306 article Path: news.gmane.org!not-for-mail From: Christopher Kohlhoff Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: comment on n4244 Date: Thu, 30 Oct 2014 00:42:02 +1100 Lines: 223 Approved: news@gmane.org Message-ID: References: <5d78c59b-4d67-45f6-9d99-8c4beeeac055@isocpp.org> <5344687e-e1de-4205-885c-b5c2f9580129@isocpp.org> <187da710-8adc-4516-bf64-263951503bc7@isocpp.org> <42ddf641-27c7-42a5-ab1c-772667797e5b@isocpp.org> <05a08ac6-f9b8-4ebb-9cb8-9a37a6fd4527@isocpp.org> <3ff7fe35-37c6-4f95-8701-1798b0112c10@isocpp.org> <934c6ace-40cc-484a-96ea-b05aff88482d@isocpp.org> <1d0b64d1-ca4b-448a-9589-01fdc0b85d55@isocpp.org> <804b06d1-9c63-4ef2-a3e8-ccfbdae30ebf@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158c09aca0ec305068fed62 X-Trace: ger.gmane.org 1414590133 13989 80.91.229.3 (29 Oct 2014 13:42:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2014 13:42:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7VEH374ORBLG5YORAKGQEPRSW3AI@isocpp.org Wed Oct 29 14:42:07 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f72.google.com ([209.85.215.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XjTVl-0002pI-M4 for gclcip-std-proposals@m.gmane.org; Wed, 29 Oct 2014 14:42:05 +0100 Original-Received: by mail-la0-f72.google.com with SMTP id mc6sf1717760lab.3 for ; Wed, 29 Oct 2014 06:42:05 -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:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=DuL5FgmsOaK8lz6CE4HLZt6T/VOgNQy5U6msQ39RlmA=; b=di3yX8+pqOGUJnPEO3dXVNKaFjmSIbkcte0Lr59W6S9eeHXX9VVawDc5BNUoXuukkj ZyDafzRT0DFBPMgofr87I5xwjuvHayNNaNSaz9u7F4CxUaZLxJNPGk2AiGulqMJovU6M DPWcMqAqJ4/GFrW7lEq2tjM4Us5zYE8evzgKhbYV+mSTqoy3hNvjGmKKO+T6/idlj8lY 2O62tiCQXFBR2dizNZ25y5YXylzRmYSr4ojzspAT3eI2vdXfSjS+Yvo3mGopOSNIpHQW ScrGMCF6/EugPsuzQ62VF1y/y+G8lGZXPLNrUGowgumwAF6aUkpUBd/Xr1eH57OAF3qp oB9w== X-Gm-Message-State: ALoCoQlCqZlZIp/PwRpyZdWGwXMaUkRShNEalVNW8PQpiYV18J613bW08m7WoOuJqFbXIkY/YVuq X-Received: by 10.112.41.228 with SMTP id i4mr1796918lbl.0.1414590125473; Wed, 29 Oct 2014 06:42:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.37.103 with SMTP id x7ls183092laj.37.gmail; Wed, 29 Oct 2014 06:42:03 -0700 (PDT) X-Received: by 10.152.19.133 with SMTP id f5mr11226895lae.87.1414590123709; Wed, 29 Oct 2014 06:42:03 -0700 (PDT) Original-Received: from mail-la0-x233.google.com (mail-la0-x233.google.com. [2a00:1450:4010:c03::233]) by mx.google.com with ESMTPS id wt3si7304803lbb.44.2014.10.29.06.42.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 06:42:03 -0700 (PDT) Received-SPF: pass (google.com: domain of chris.kohlhoff@gmail.com designates 2a00:1450:4010:c03::233 as permitted sender) client-ip=2a00:1450:4010:c03::233; Original-Received: by mail-la0-f51.google.com with SMTP id q1so2515677lam.24 for ; Wed, 29 Oct 2014 06:42:03 -0700 (PDT) X-Received: by 10.152.29.41 with SMTP id g9mr11597834lah.83.1414590123084; Wed, 29 Oct 2014 06:42:03 -0700 (PDT) Original-Sender: chris.kohlhoff@gmail.com Original-Received: by 10.25.33.73 with HTTP; Wed, 29 Oct 2014 06:42:02 -0700 (PDT) In-Reply-To: X-Original-Sender: chris@kohlhoff.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of chris.kohlhoff@gmail.com designates 2a00:1450:4010:c03::233 as permitted sender) smtp.mail=chris.kohlhoff@gmail.com; dkim=pass header.i=@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:14306 Archived-At: --089e0158c09aca0ec305068fed62 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 1:00 AM, Giovanni Piero Deretta wrote: > > > On Tuesday, October 28, 2014 1:24:20 PM UTC, Gor Nishanov wrote: >> >> >> >>> >>> why would they be not safe? They are perfectly safe in N4244 design. As >>> safe as the rest of the c++ at least. >>> >> >> Notice that lambda* transforms the variables form the body of >> operator()() in a member variable of the class. Aliases may appear without >> you noticing; >> >> std::string s = "hello"; >> for(ch: S) yield ch; >> >> > hargh, that's pretty damning. You do not even need the string: > > char s[] = "hello"; > for(ch: S) yield ch; > > for this specific case the compiler *could* fix the iterator, but you can > come up with other cases in which it is unfeasible. I agree that making > generator copyable by default would be terribly error prone. > > There might be a way out that might satisfy everybody's requirements. Let > me think about it. > By way of background let me say that I disagree with Gor's definition of "stackless" as his definition includes N4134 coroutines. The defining characteristic of stackless coroutines is that, as a user, you make no assumptions about the stack: - You make no assumptions that your variables have stable addresses. - You don't do things that alias your local variables. As soon as you stick that little "resumable" keyword on there, you are defining an aggregate where the data members are defined as locals. But yes, range-based for is a problem because it necessarily introduces aliasing and yet also hides it away. It seems to me there's a simple solution: If your resumable lambda contains a ranged-based for, and your range-based for contains a yield, then the resumable lambda's copy and move constructors are inhibited. Nothing of value is lost. In other words, we can still write: std::vector strings; ... auto&& f = [strings] { for (auto s: strings) yield s; ... }; if we are willing to accept that f is noncopyable. Please note that in my implementation I have solved the problem of noncopyable lambdas. You can run the lambda as a stationary object in your preferred location -- heap, stack or data member -- and not just as a lifetime-extended temporary. Inhibiting copyability in the presence of ranged-based for is about maintaining correctness. I don't believe copyable or movable coroutines are particularly error prone in general, and the yield points where one must take care are explicitly documented in the source code. Field experience with macro-based coroutines bears this out. It might appear tempting to make noncopyability the default, though whether or not there is a quantifiable benefit in doing so is questionable. However, to insist that, due to a perception of risk, resumable lambdas must reside on the heap is to throw the baby out with the bath water. To me this approach seems fundamentally at odds with the ethos and existing practice of C++. A compiler vendor knows far far less about the specifics of the applications we develop than we do. I use C++ because I know more about my application, because I care about performance, and because C++ gives me flexibility to apply this knowledge. Lastly, the stated position that having a stationary frame means that we must have heap allocations smells like faulty logic to me. A stationary frame implies only that the object not be copied or moved. C++ programmers write noncopyable classes every day, and they are perfectly able to put them on the stack, embed them as data members in other classes, and so on. Cheers, Chris -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --089e0158c09aca0ec305068fed62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 29, 2014 at 1:00 AM, Giovanni Piero Deretta <gpderetta@g= mail.com> wrote:


On Tuesday, October 28, 2014 1:24:20 PM UTC, Gor Nishan= ov wrote:
=C2=A0
=C2=A0
why would they be not safe? They are perf= ectly safe in N4244 design.=C2=A0 As safe as the rest of the c++ at least.<= /div>

Notice that lambda* transforms = the variables form the body of operator()() in a member variable of the cla= ss. Aliases may appear without you noticing;

std::= string s =3D "hello";
for(ch: S) yield ch;

hargh, that's pretty damning= .. You do not even need the string:
=C2=A0
=C2=A0 char s[] =3D &q= uot;hello";
=C2=A0 for(ch: S) yield ch;

for th= is specific case the compiler *could* fix the iterator, but you can come up= with other cases in which it is unfeasible. I agree that making generator = copyable by default would be terribly error prone.

There= might be a way out that might satisfy everybody's requirements. Let me= think about it.

By way of background let me say that I d= isagree with Gor's definition
of "= stackless" as his definition includes N4134 coroutines. The
defining characteristic of stackless coroutines is th= at, as a user, you
make no assumptions abou= t the stack:

- You make no assumptions that your variables have stable addresses.=

- You= don't do things that alias your local variables.

As soon as you stick that l= ittle "resumable" keyword on there, you are
defining an aggregate where the data members are defined as loca= ls.

Bu= t yes, range-based for is a problem because it necessarily introduces
=
aliasing and yet also hides it away. It seems to= me there's a simple
solution: If your = resumable lambda contains a ranged-based for, and
your range-based for contains a yield, then the resumable lambda'= ;s copy
and move constructors are inhibited= .. Nothing of value is lost. In other
words,= we can still write:

=C2=A0 std::vector<std::string> strings;
=C2=A0 ...
=C2=A0 auto= && f =3D [strings]
=C2=A0 {
=C2=A0 =C2=A0 for (auto s: strings)
=C2=A0 =C2=A0 =C2=A0 yield s;
=C2=A0 =C2=A0 ...
=C2=A0 };

if we are willin= g to accept that f is noncopyable. Please note that in
my implementation I have solved the problem of noncopyable lamb= das. You
can run the lambda as a stationary= object in your preferred location --
heap,= stack or data member -- and not just as a lifetime-extended
temporary.

Inhibiting copyability in the presence of ranged-bas= ed for is about
maintaining correctness. I = don't believe copyable or movable coroutines
are particularly error prone in general, and the yield points where o= ne
must take care are explicitly documented= in the source code. Field
experience with = macro-based coroutines bears this out.

=
It might appear tempting to make noncopyab= ility the default, though
whether or not th= ere is a quantifiable benefit in doing so is
questionable. However, to insist that, due to a perception of risk,
=
resumable lambdas must reside on the heap is to = throw the baby out with
the bath water. To = me this approach seems fundamentally at odds with
the ethos and existing practice of C++. A compiler vendor knows far = far
less about the specifics of the applica= tions we develop than we do. I
use C++ beca= use I know more about my application, because I care about
performance, and because C++ gives me flexibility to apply= this
knowledge.

Lastly, the stated position that= having a stationary frame means that
we mu= st have heap allocations smells like faulty logic to me. A
stationary frame implies only that the object not be copie= d or moved.
C++ programmers write noncopyab= le classes every day, and they are
perfectl= y able to put them on the stack, embed them as data members in
other classes, and so on.

Cheers,
Chris

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--089e0158c09aca0ec305068fed62-- .