220 5257 <7d8a2d85-0995-4833-ad0c-75577f293b63@isocpp.org> article Path: news.gmane.org!not-for-mail From: asaelr@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Some thoughts about coroutines Date: Thu, 27 Jun 2013 07:34:39 -0700 (PDT) Lines: 1512 Approved: news@gmane.org Message-ID: <7d8a2d85-0995-4833-ad0c-75577f293b63@isocpp.org> References: <291db835-d42d-40cd-8760-47cdf327680d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_482_15419926.1372343679497" X-Trace: ger.gmane.org 1372343683 29191 80.91.229.3 (27 Jun 2013 14:34:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 14:34:43 +0000 (UTC) Cc: asaelr@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB23LHRZUKRBAE3WGHAKGQEQRK7ZGA@isocpp.org Thu Jun 27 16:34:45 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UsDHV-00079q-Qm for gclcip-std-proposals@m.gmane.org; Thu, 27 Jun 2013 16:34:42 +0200 Original-Received: by mail-gh0-f197.google.com with SMTP id r20sf1066157ghr.0 for ; Thu, 27 Jun 2013 07:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:cc:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-google-group-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=/2lCXBMxuzfarRe0lcYynOwJ+X4Ef+naR6a0AjX4Ojs=; b=pO5Q5XsqgHxKKkN1dgt0u4YL8HWipQD/Xp5AeSGguqrmstTAJz5rQq/GJwzgyVtsZr HKr/fdwm+KJ7SxtQgF3ohWRI06oecFCkzY2PvI7CBP3o88XAxIIu/NYhPyp13RaVcw8s CD/KFNkBhwRddq+4voosDFUR8mo0HLh1yRD9Bj/CH9JJVU3FrELO+G10K39aTxJCrC6m fNaK+PIcEZZFQiGb13EP0YR+XH08eMbZvDspk+l6a0K6G1C3t8b4hnkE45S6HdX5eA+/ utAm+zKta+LxjyHtxfk8akLQCqPSyDEXtEyjSJz3eae4xwlbNvQNWMcvAmzULETr5e3a e6AQ== X-Received: by 10.236.120.232 with SMTP id p68mr4947512yhh.43.1372343680878; Thu, 27 Jun 2013 07:34:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.107.66 with SMTP id ha2ls839807qeb.56.gmail; Thu, 27 Jun 2013 07:34:40 -0700 (PDT) X-Received: by 10.49.133.201 with SMTP id pe9mr226098qeb.34.1372343680006; Thu, 27 Jun 2013 07:34:40 -0700 (PDT) In-Reply-To: <291db835-d42d-40cd-8760-47cdf327680d@isocpp.org> X-Original-Sender: asaelr@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:5257 Archived-At: ------=_Part_482_15419926.1372343679497 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1) *begin* and *end* are the common way to iterate over something. I'm=20 agree that sometimes we just want to have *auto coro(args);coro(); 2) You're rig*ht. I had forgotten that class template arguments are not=20 being deducted - even when we just are calling the constructor If I understood you correctly, you mean to transfrom *int : fib(int n)=20 {/*blablabla/*}* to *fib_class fib(int n) {return fib_class(n);}* , when * fib_class* is some unnamed data structure. This seems to solve the=20 deduction problem. If we allow *fib_class::operator()*, it means that the= =20 actual calling is represented by *fib_class*, and not by *fib_class:iterato= r *. That's a good idea, but it should deal with: auto coro=3Dfib(10); auto iter=3Dfib.begin(); int a=3D*iter; //should be 1 int b=3Dcoro(); //should be 2 ++iter; //what does this mean? what is the value of *iter now? I think that since a coroutine have only one currently return value, an=20 existing iterator should be invalidated when the corouting is being=20 incremented by other way (using another iterator, or *operator()* ). In this concept, I suggest that an iterator object will contain only=20 reference to the coroutine object, and the position data. (This also saves the parameters copy in *begin*) Thanks for the feedback. Clearly I may think more about the concept. (My=20 main goals were to discuss some technical details which weren't clear in=20 https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/PPZJVTDd= DVQ=20 , and to suggest a new (and - according to my taste - nice) syntax. =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=97=D7=9E=D7=99= =D7=A9=D7=99, 27 =D7=91=D7=99=D7=95=D7=A0=D7=99 2013 11:53:53 UTC+3, =D7=9E= =D7=90=D7=AA Xeo: > > While I really want to get my hands on native coroutines, I don't think= =20 > your approach works very well. > > 1) Who says we always want to use coroutines as `for(auto r :=20 > coro(args))`? I don't think that's necessarily the main form of use > 2) How would the transformation to a class work for template argument=20 > deduction? > > I think a better course would be to transform the return type of such a= =20 > function, as would be done with async/await-style functions. > The returned type would then simply have an `operator()` and if you wante= d=20 > a range from that, it could be quite easily done with a general=20 > function-adaptor. > > On Thursday, June 27, 2013 3:40:58 AM UTC+2, asa...@gmail.com wrote: >> >> Recently, I=E2=80=99ve thought a lot about coroutines, and how they shou= ld behave=20 >> if became a part of c++. >> >> I found two (main) proposals: >> >> a.=20 >> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/3g6ZI= WedGJ8 >> >> It has the advantage of not requiring to change the syntax, but in force= =20 >> a new model of stack-based calls. It does so in purpose to let nested=20 >> functions to yield value, which I think is not really necessary. (If we = let=20 >> nested functions return value on behalf of their callee, we should start= =20 >> this in regular functions). Also, Its syntax is somehow complex. >> >> b.=20 >> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/PPZJV= TDdDVQ >> >> It is easy to use and doesn=E2=80=99t require a new stack, and I think t= hat this=20 >> is the right direction. However, it ignores some technical details=20 >> (lifetime of locals, etc). Also, adding a keyword may break too many=20 >> working code, and my personal opinion is that it is ugly. Sentences like= =20 >> =E2=80=9Cvoid numbers() yields int=E2=80=9D reminds me too many things I= hate in Java. The=20 >> alternative syntax (described at the end of this proposal) is not so ugl= y,=20 >> but still complex. >> >> There is even a nice implementation of coroutines (using macros):=20 >> http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html >> >> but it has 2 major disadvantages: while using it, we can=E2=80=99t yield= a value=20 >> from within a switch statement, and, much more important, we have to def= ine=20 >> all the local variables at the top of the function - back to C90 days! (= and=20 >> with constructors this is much worst.) >> >> Another thing that was very little talk about, is for-range loops native= =20 >> support. Let=E2=80=99s say we have a Fibonacci number generator (a very = common=20 >> example): >> >> (Using Denis Bredelet=E2=80=99s proposal syntax) >> >> void fib(int n) yields int { >> >> int a=3D0,b=3D1; >> >> while(n--) { >> >> int c=3Da+b; >> >> a=3Db; >> >> b=3Dc; >> >> yield c; >> >> } >> >> } >> >> We want the possibility to write for (int i : fib(10))=20 >> std::cout<> >> So what am I suggest? >> >> First, to the syntax. Since we want it to work natively with for-range= =20 >> loops, and since the language concept is =E2=80=9Cdeclare it the way yo= u will use=20 >> it=E2=80=9D, I would suggest using colon in the function signature. The = nicest idea=20 >> I managed to think so far is int : fib(int n) >> >> Also, there is no reason to add the keyword yield, when we can stick to= =20 >> good old return. >> >> Now, to the real stuff: What does fib(10) mean? What=E2=80=99s the type = of=20 >> fib(10).begin()? >> >> I suggest this meaning: fib will be (auto-generated) class, and an objec= t=20 >> of it will represent calling the =E2=80=9Cfunction=E2=80=9D with specifi= c parameters. The=20 >> member function begin (and end) will return some sort of iterator, which= =20 >> will represent the actual call. >> >> Some details: the fib class should have some members, to contain the=20 >> parameters it called with, but the real fun is in the iterator class: it= =20 >> will have (in addition to the parameters), as (not exactly, I will expl= ain=20 >> below) members, all the local variables of the =E2=80=9Cfunction=E2=80= =9D (including the=20 >> return value), and also the information about where it stopped last time= =20 >> (and should resume from) - let=E2=80=99s call it, from now on, =E2=80=9C= position data=E2=80=9D. >> >> To be more precise: an iterator should contain the memory for the local= =20 >> variables (like every member variable), but their lifetime will be as if= =20 >> they were local variables of the =E2=80=9Cfunction=E2=80=9D. I mean - th= ey will been=20 >> constructed only when the =E2=80=9Cfunction=E2=80=9D will decide so, and= not automatically=20 >> when the iterator is been constructed. >> >> When the =E2=80=9Cfunction=E2=80=9D ends (either by falling through the = ending brace, not=20 >> catching exception, or simply saying return; without a value), the=20 >> position data should contain this information, and (like every function)= ,=20 >> every local variable should be destructed. >> >> Knowing the position data let us easily determine which variables are=20 >> alive, and so I think that the following member functions can be=20 >> automatically created: >> >> copy constructor - should copy the position data, the parameters, and=20 >> every living local variable >> >> move constructor - the same, but move instead of copy >> >> destructor - destroy the parameters, and every living local variable. >> >> (Of course, if some local variable is noncopyable, so is the iterator) >> >> I think that it should not be assignable - If one iterator have a live= =20 >> object, and another one have not, it=E2=80=99s a real mess. >> >> Some example: >> >> Suppose that we want to yield the number 0, and then, the first n=20 >> Fibonacci numbers and the first n even number, alternately. To add more= =20 >> interest (and to demonstrate more rules), I want to create and destroy s= ome=20 >> objects (assume A is a copyable, moveable, and int-constructive class),= =20 >> so I=E2=80=99ve written the following code: >> >> int : fib_even(int n) { >> >> A a(7); >> >> int fib1=3D0,fib2=3D1,even=3D0; >> >> return 0; >> >> while(n--) { >> >> int fib3=3Dfib1+fib2; >> >> fib1=3Dfib2; >> >> fib2=3Dfib3; >> >> return fib3; >> >> A b=3Dn; >> >> return even+=3D2; >> >> } >> >> } >> >> A compiler may expand it to something like: >> >> (Note: I=E2=80=99m using dynamic memory allocation, but It=E2=80=99s not= really how it=20 >> should be implemented - I just don=E2=80=99t want some constructors and = destructors=20 >> to been invoked automatically) >> >> class fib_even { >> >> class iterator { >> >> int n; >> >> int *fib1,*fib2,*fib3,*even; >> >> A *a,*b; >> >> int *ret_value; >> >> enum {p0,p1,p2,p3,p4} pos; //resuming points >> >> void next() { >> >> switch (pos) { >> >> case p0: break; >> >> case p1: goto label1; >> >> case p2: goto label2; >> >> case p3: goto label3; >> >> case p4: return; >> >> } >> >> //construct automatic variables of the function >> >> a=3Dnew A(7); >> >> fib1=3Dnew int(0); >> >> fib2=3Dnew int(1); >> >> even=3Dnew int(0); >> >> //the return process - create the value, save the resuming point, and=20 >> return >> >> ret_value=3Dnew int(0); >> >> pos=3Dp1; >> >> return; >> >> label1: >> >> while(n--) { >> >> fib3=3Dnew int(*fib1+*fib2); //being constructed only now >> >> *fib1=3D*fib2; >> >> *fib2=3D*fib3; >> >> ret_value=3Dnew int(*fib3); >> >> pos=3Dp2; >> >> return; >> >> label2: >> >> b=3Dnew A(n); >> >> ret_value=3Dnew int((*even)+=3D2); >> >> pos=3Dp3; >> >> return; >> >> label3: >> >> //automatic variables going out of scope, and should be destructed >> >> delete b; >> >> delete fib3; >> >> } >> >> delete even; >> >> delete fib2; >> >> delete fib1; >> >> delete a; >> >> pos=3Dp4; >> >> } >> >> iterator(int n) : n(n),pos(p0) { >> >> next(); //get the first value >> >> } >> >> iterator() : pos(p4) {} >> >> public: >> >> iterator &operator++() { >> >> delete ret_value; >> >> next(); >> >> return *this; >> >> } >> >> int &operator*() { >> >> return *ret_value; >> >> } >> >> iterator(const iterator &it) : n(it.n),pos(it.pos) { >> >> //copy only living members >> >> if (pos>p0 && pos> >> ret_value=3Dnew int(*it.ret_value); >> >> a=3Dnew A(*it.a); >> >> fib1=3Dnew int(*it.fib1); >> >> fib2=3Dnew int(*it.fib2); >> >> even=3Dnew int(*it.even); >> >> } >> >> if (pos>p1 && pos> >> if (pos>p2 && pos> >> } >> >> iterator(iterator &&it) : n(std::move(it.n)),pos(it.pos) { >> >> if (pos>p0 && pos> >> ret_value=3Dnew int(std::move(*it.ret_value)); >> >> a=3Dnew A(std::move(*it.a)); >> >> fib1=3Dnew int(std::move(*it.fib1)); >> >> fib2=3Dnew int(std::move(*it.fib2)); >> >> even=3Dnew int(std::move(*it.even)); >> >> } >> >> if (pos>p1 && pos> >> if (pos>p2 && pos> >> } >> >> ~iterator() { >> >> if (pos>p2 && pos> >> if (pos>p1 && pos> >> if (pos>p0 && pos> >> delete even; >> >> delete fib2; >> >> delete fib1; >> >> delete a; >> >> delete ret_value; >> >> } >> >> } >> >> bool operator!=3D(const iterator &it) { >> >> return pos!=3Dit.pos; >> >> } >> >> operator bool() { >> >> return pos> >> } >> >> iterator &operator=3D(const iterator&) =3D delete; >> >> friend fib_even; >> >> }; >> >> int n; >> >> public: >> >> fib_even(int n) : n(n) {} >> >> iterator begin() { >> >> return iterator(n); >> >> } >> >> iterator end() { >> >> return iterator(); >> >> } >> >> }; >> >> So, what do you think? >> > --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_482_15419926.1372343679497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1) begin and end are the common way to iterate over something= .. I'm agree that sometimes we just want to have auto coro(args);coro();<= br>2) You're right. I had forgotten that class template arguments are n= ot being deducted - even when we just are calling the constructor

If= I understood you correctly, you mean to transfrom int : fib(int n) {/*b= lablabla/*} to fib_class fib(int n) {return fib_class(n);} , whe= n fib_class is some unnamed data structure. This seems to solve the = deduction problem. If we allow fib_class::operator(), it means that = the actual calling is represented by fib_class, and not by fib_cl= ass:iterator. That's a good idea, but it should deal with:
auto coro= =3Dfib(10);
auto iter=3Dfib.begin();
int a=3D*iter; //should be 1
= int b=3Dcoro(); //should be 2
++iter; //what does this mean? what is the= value of *iter now?
I think that since a coroutine have only one curren= tly return value, an existing iterator should be invalidated when the corou= ting is being incremented by other way (using another iterator, or opera= tor() ).
In this concept, I suggest that an iterator object will con= tain only reference to the coroutine object, and the position data.
(Thi= s also saves the parameters copy in begin)

Thanks for the fee= dback. Clearly I may think more about the concept. (My main goals were to d= iscuss some technical details which weren't clear in https://groups.google.= com/a/isocpp.org/forum/#!topic/std-proposals/PPZJVTDdDVQ , and to suggest a= new (and - according to my taste - nice) syntax.


=D7=91=D7=AA= =D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=97=D7=9E=D7=99=D7=A9=D7=99,= 27 =D7=91=D7=99=D7=95=D7=A0=D7=99 2013 11:53:53 UTC+3, =D7=9E=D7=90=D7=AA = Xeo:
While I really want to get= my hands on native coroutines, I don't think your approach works very well= ..

1) Who says we always want to use coroutines as `for(auto r : coro= (args))`? I don't think that's necessarily the main form of use
2) How w= ould the transformation to a class work for template argument deduction?
I think a better course would be to transform the return type of such = a function, as would be done with async/await-style functions.
The retur= ned type would then simply have an `operator()` and if you wanted a range f= rom that, it could be quite easily done with a general function-adaptor.
On Thursday, June 27, 2013 3:40:58 AM UTC+2, asa...@gmail.com w= rote:

Recently, I=E2=80=99ve thought a lot about coroutines, and ho= w they should behave if became a part of c++.

I found two (main) proposals:

a. https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/3g6ZIWedGJ8

It has the advantage of not requiring to change the syntax, but in force a new model of stack-based calls. It does so in purpose to let nested=20 functions to yield value, which I think is not really necessary. (If we=20 let nested functions return value on behalf of their callee, we should=20 start this in regular functions). Also, Its syntax is somehow complex.

b. https://groups.google.com/a/isocpp.org/forum= /#!topic/std-proposals/PPZJVTDdDVQ

I= t is easy to use and doesn=E2=80=99t require a new stack, and I think that t= his=20 is the right direction. However, it ignores some technical details=20 (lifetime of locals, etc). Also, adding a keyword may break too many=20 working code, and my personal opinion is that it is ugly. Sentences like =E2=80=9Cvoid numbers() yields int=E2=80=9D reminds me too many things I h= ate in Java.=20 The alternative syntax (described at the end of this proposal) is not so ugly, but still complex.

There is even a nice implementation of coroutines (using macros): http://www.chiark.greenend.org.uk/~sgtatham/c= oroutines.html<= /span>

but it has 2 major disadvantages: while using it, we can=E2=80=99t yield a val= ue=20 from within a switch statement, and, much more important, we have to=20 define all the local variables at the top of the function - back to C90=20 days! (and with constructors this is much worst.)


Another thing that was very little talk about, is for-range loops native=20 support. Let=E2=80=99s say we have a Fibonacci number generator (a very com= mon=20 example):

(Using Deni= s Bredelet=E2=80=99s proposal syntax)

void fib(int n) yields int {

 int a=3D0,b=3D1;

 while(n--) {

   int c=3Da+b;

   a=3Db;

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline">    b=3Dc;=

   yield c;=

 }

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline">}

We want the possibility to write for (int i : fib(10)) std::cout<<i&l= t;<=E2=80=99\n=E2=80=99; to print the first 10 Fibonacci numbers.


So what am I suggest?

First, to the syntax. Since we want it to work natively with for-range loops,=20 and since the  language concept is =E2=80=9Cdeclare it the way you wil= l use it=E2=80=9D, I would suggest using colon in the function signature. The nicest idea I managed to think so far is int : fib(int n)

= Also, there is no reason to add the keyword yield, when we can stick to good old return.<= /p>

Now, to the real stuff: What= does fib(10) mean? What=E2=80=99s the type of <= /span>fib(10).begin()?

I suggest this meaning: fib will be (auto-generated) class, and an object of it will represent calling the =E2=80=9Cfunction=E2=80=9D with specific = parameters.=20 The member function begi= n (and end) will return some sort of iterator, which will represent the = actual call.

Some det= ails: the fib class should have some members, to= contain the parameters it called with, but the real fun is in the <= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:italic;font-variant:normal;tex= t-decoration:none;vertical-align:baseline">iterator class: it will have (in addition to the parameters),  as (not exactly= , I will explain below) members, all the local variables of the =E2=80=9Cfunct= ion=E2=80=9D=20 (including the return value), and also the information about where it=20 stopped last time (and should resume from) - let=E2=80=99s call it, from no= w on, =E2=80=9Cposition data=E2=80=9D.

To be more precise: an iterator should contain the memory for the local variables (like every member=20 variable), but their lifetime will be as if they were local variables of the =E2=80=9Cfunction=E2=80=9D. I mean - they will been constructed only w= hen the=20 =E2=80=9Cfunction=E2=80=9D will decide so, and not automatically when the <= /span>iterator is been constructed.

When the =E2=80=9Cfunction=E2=80=9D ends= (either by falling through the ending brace, not catching exception, or si= mply saying return; without a value), the position data should contain this information,=20 and (like every function), every local variable should be destructed.

Knowing the position data let us easily determine which variables are alive,=20 and so I think that the following member functions can be automatically=20 created:

copy constru= ctor - should copy the position data, the parameters, and every living loca= l variable

move const= ructor - the same, but move instead of copy

destructor - destroy the parameters, and every livi= ng local variable.

(O= f course, if some local variable is noncopyable, so is the iterator)=

I think that it should not = be assignable - If one iterator have a live object, and another one have no= t, it=E2=80=99s a real mess.


Some example= :

Suppose that we want to yield the number 0, and then, the first n Fibonacci=20 numbers and the first n even number, alternately. To add more interest=20 (and to demonstrate more rules), I want to create and destroy some=20 objects (assume A= is a copyable, moveable, and i= nt-constructive class), so I=E2=80=99ve written the following code:<= /p>

int : fib_even(int n) {

   A a(7)= ;

   = int fib1=3D0,fib2=3D1,even=3D0;

   return 0;

   while(n--) {

       int fib= 3=3Dfib1+fib2;

 = ;      fib1=3Dfib2;

       fib2=3Dfib3;<= /span>

   &n= bsp;   return fib3;

       A b=3Dn;

       re= turn even+=3D2;

&nbs= p;  }

}


A compiler may expand it to something like= :

(Note: I=E2=80=99m using dynamic memory allocation, but It=E2=80=99s not really h= ow it should=20 be implemented - I just don=E2=80=99t want some constructors and destructor= s to=20 been invoked automatically)


class fib_eve= n {

  &nbs= p;class iterator {

&= nbsp;      int n;

       int *fib1,*fi= b2,*fib3,*even;

&nbs= p;      A *a,*b;

       int *ret_value;<= /span>

   &n= bsp;   enum {p0,p1,p2,p3,p4} pos; //resuming points

     = ;  void next() {

           switch (pos) {

   &nbs= p;           case p0: break;=

    &n= bsp;          case p1: goto label1;

    =            case p2: goto label2;

   &nbs= p;           case p3: goto label3;<= /span>

   &n= bsp;           case p4: return;

    = ;       }

//construct automatic variables of the function

          &nb= sp;a=3Dnew A(7);

&nb= sp;          fib1=3Dnew int(0);

    = ;       fib2=3Dnew int(1);

       &nbs= p;   even=3Dnew int(0);

//the retur= n process - create the v= alue, save the resuming = point, and return

           ret_value=3Dnew i= nt(0);

  &= nbsp;        pos=3Dp1;

       &nbs= p;   return;

       label1:

       &nbs= p;   while(n--) {

             = ;  fib3=3Dnew int(*fib1+*fib2); //being constructed only now

    &= nbsp;          *fib1=3D*fib2;

=

=      =          *fib2=3D*fib3;

      &nbs= p;        ret_value=3Dnew int(*fib3);<= /p>

    &nb= sp;          pos=3Dp2;

       = ;        return;

       label2:

    = ;           b=3Dnew A(n);

     = ;          ret_value=3Dnew int((*even)+= =3D2);

  &= nbsp;            pos=3Dp3;

    = ;           return;

      &nbs= p;label3:

//automatic= variables going out of scope, and should be des= tructed

 &n= bsp;             delete b= ;

   =             delete fib3;

    &= nbsp;      }

           delete= even;

  &= nbsp;        delete fib2;

       &n= bsp;   delete fib1;

           delete a;=

   &= nbsp;       pos=3Dp4;

       }

     = ;  iterator(int n) : n(n),pos(p0) {

          &nbs= p;next(); //get the firs= t value

 &n= bsp;     }

       iterator() : pos(p4) {}

   publi= c:

   = ;    iterator &operator++() {

        &nb= sp;  delete ret_value;

           next();

    = ;       return *this;

       }

     = ;  int &operator*() {

           return *= ret_value;

 &nb= sp;     }

       iterator(const iterator &= ;it) : n(it.n),pos(it.pos) {

//copy only living members

           = if (pos>p0 && pos<p4) {

           &= nbsp;   ret_value=3Dnew int(*it.ret_value);

       &nbs= p;       a=3Dnew A(*it.a);

       &nbs= p;       fib1=3Dnew int(*it.fib1);

      &nbs= p;        fib2=3Dnew int(*it.fib2);

     = ;          even=3Dnew int(*it.even);

    = ;       }

           if (= pos>p1 && pos<p4) fib3=3Dnew int(*it.fib3);

       = ;    if (pos>p2 && pos<p4) b=3Dnew A(*it.b);

   &nb= sp;   }

&n= bsp;      iterator(iterator &&it) : n(std:= :move(it.n)),pos(it.pos) {

           if (pos>p= 0 && pos<p4) {

              =  ret_value=3Dnew int(std::move(*it.ret_value));

       &nbs= p;       a=3Dnew A(std::move(*it.a));

      &= nbsp;        fib1=3Dnew int(std::move(*it.fib= 1));

  &nb= sp;            fib2=3Dnew int(= std::move(*it.fib2));

              &nbs= p;even=3Dnew int(std::move(*it.even));

           = }

   =         if (pos>p1 && pos<p4) f= ib3=3Dnew int(std::move(*it.fib3));

           if = (pos>p2 && pos<p4) b=3Dnew A(std::move(*it.b));

      &n= bsp;}

  &n= bsp;    ~iterator() {

           if= (pos>p2 && pos<p4) delete b;

          =  if (pos>p1 && pos<p4) delete fib3;

       &nb= sp;   if (pos>p0 && pos<p4) {

       &nbs= p;       delete even;

         = ;      delete fib2;

           = ;    delete fib1;

            =    delete a;

              &nb= sp;delete ret_value;

=            }

       = ;}

   = ;    bool operator!=3D(const iterator &it) {

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:Arial;color:#000000;background-col= or:transparent;font-weight:normal;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline">       =      return pos!=3Dit.pos;

       }

     = ;  operator bool() {

           return pos<= ;p4; //still hasn't ende= d

  &n= bsp;    }

       iterator &operator=3D(const i= terator&) =3D delete;

       friend fib_even;

   };

   int n;

public:

   fib_even(int n) : n(n) = {}

   = ;iterator begin() {

=        return iterator(n);

   }

   iterator end() {

   &nb= sp;   return iterator();

   }

};


=

So, what do you think?

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