220 27251 <28358863-5be0-401a-893a-0ae5385156c2@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: loop continuation code Date: Mon, 25 Jul 2016 08:08:22 -0700 (PDT) Lines: 344 Approved: news@gmane.org Message-ID: <28358863-5be0-401a-893a-0ae5385156c2@isocpp.org> References: <2f575934-e078-411c-9c8a-c2996da7609d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_231_358107579.1469459302807" X-Trace: ger.gmane.org 1469459314 11661 80.91.229.3 (25 Jul 2016 15:08:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 15:08:34 +0000 (UTC) Cc: gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2GW3C6AKGQES776RVQ@isocpp.org Mon Jul 25 17:08:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bRhUY-0004eJ-GM for gclcip-std-proposals@m.gmane.org; Mon, 25 Jul 2016 17:08:26 +0200 Original-Received: by mail-vk0-f72.google.com with SMTP id x130sf423493608vkc.3 for ; Mon, 25 Jul 2016 08:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=tbe4SfQKjiF/WWOF3R3RJbGbBW0xB66ggsS9fR33OWk=; b=fuwe4QgwGSXCC9pWiYDvrYlyJOI7ut7IajXP9a+qzytTUH0EzA8JK5dx816fXOt6oY Jtya3QAvTdg90qEV1oDp2B9P76XpMfVwC3ZobDG9rXMEqKGV1mlszstqa3JkdOKApB6F VBH7Rntc3tYlaPLxBEFFP0ZZSAhFTOtmCrqp9Z5fMyUT8jqvASZrbdZD+BP9Rbt80Kef j+eA23oMZInTuhrCU/4QFw6ZM4xYyp+wmczjKzg3k1Vyy7WCVqLy3j8fACYne6/E0kkL A5gArI+Mz1luj6aEDHdK8Lgy/MxXaD3nJsJWVXEtjX2P6jCYa1NcmIsDcR/vg86slULY Pw2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=tbe4SfQKjiF/WWOF3R3RJbGbBW0xB66ggsS9fR33OWk=; b=L5Ri++FJG0fpFA9K7zt4G8MpcG8meUNGU4p7HhkHrpUZZJtjU7++4S5Xs8yAsZ6nhb t1p9X5WpRCx/X8Ydg8VfRixISDx43r9NFk1kzYT+rnItbhb65YH7g8kbP9WmY+EUkUHy 0UPjdg95i+QtQ+1JSrBRTp/L+mUx0ksudPlcfvl0LQnmdCdSSnZHB6bc1bn1sLlMO1SR PWSX0yGY/AqAydszbizcfG61KDMYOCi/gGKoUor9tAreLiKwPFlA086sKscwj/I5LcuA vd4HlUVEHboYmb0U0Gx3UdLWMUYYGsM4nATibfwqnbxU+joTbD/rFkaiB/SKW2yyDJb7 0UQA== 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:cc: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=tbe4SfQKjiF/WWOF3R3RJbGbBW0xB66ggsS9fR33OWk=; b=P/OMkmh/X1lbkAMy78FfP+ScqOUMY3xRCvovuwexHiOzpH34BwROzq2IQgqcwuFktM AE0pq4ZtlnrLImjeiUZSJI0/UumU8/N1S4PhyyTHgukOfozBeIhLU6cUeV78bzPmzx+j zEiz92LTAPRP+32Sv9wPE+EXYknaAmnOD5ckwsnG0le06phM2eikj4EmWDZv4ssRiyf7 ofbPobovdcMVGXvMKbANq0257/eTb3aBAizQTbLDxCzDgWDYraW+LknCGIKkoF+hWx1n Er7P2dRwbY40kPAXumQm9wSP8SIdfyLMivJFiMs4GMEgd+CaAb9L/59cTSr04BtvIee9 v9xA== X-Gm-Message-State: AEkoouvoataXKtP75g3HEFEnOyBwEBHf0UrpyqJXSwqR55WLASU7UNfrUxM9NCBxM2dRUQ== X-Received: by 10.129.40.198 with SMTP id o189mr16349105ywo.51.1469459305366; Mon, 25 Jul 2016 08:08:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.19.150 with SMTP id 22ls3496848iot.17.gmail; Mon, 25 Jul 2016 08:08:24 -0700 (PDT) X-Received: by 10.36.225.141 with SMTP id n135mr231621ith.2.1469459304000; Mon, 25 Jul 2016 08:08:24 -0700 (PDT) In-Reply-To: <2f575934-e078-411c-9c8a-c2996da7609d@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:27251 Archived-At: ------=_Part_231_358107579.1469459302807 Content-Type: multipart/alternative; boundary="----=_Part_232_1905488901.1469459302808" ------=_Part_232_1905488901.1469459302808 Content-Type: text/plain; charset=UTF-8 On Monday, July 25, 2016 at 2:40:42 AM UTC-4, gmis...@gmail.com wrote: > > Hi > > I was recently reading a reddit article where a piece of code like this > appeared: > > for ( int i = 0; pUnicast != NULL; i++ ) > { > Address address( (sockaddr_storage*) pUnicast->Address.lpSockaddr ); > > if ( !address.IsValid() ) > goto next_unicast; > > if ( address.IsLoopback() ) > goto next_unicast; > > if ( address.GetType() == ADDRESS_IPV6 && !address.IsGlobalUnicast() ) > goto next_unicast; > > addresses[numAddresses++] = address; > > if ( numAddresses >= maxAddresses ) > break; > > next_unicast: > > pUnicast = pUnicast->Next; > } > > A common response to the article was to immediately attack the code and > re-write it without using goto because people considered it sloppy. This > got me thinking about a few things: > > #1 It reminded me how fearful people are of goto so that they won't use it > even if it's appropriate; and not only that, but they will also > re-write other peoples code using goto to avoid it even if it isn't a big > deal. The example loop above isn't that unreasonable especially if you > imagine you might want to add additional statements later at the goto > target point. That then brings me to my main point: > > #2 Sometimes I want to execute the same set of code on continuation and > putting it all in the increment section of the loop isn't that nice or even > realistic. But using a goto isn't that nice either or having someone > re-write code just because *they* don't like goto. > > Proposal: > If we had a special continue block in the language, these problems > wouldn't exist because we could re-write the above loop like so: > > for ( int i = 0; pUnicast != NULL; i++ ) > { > Address address( (sockaddr_storage*) pUnicast->Address.lpSockaddr ); > > if ( !address.IsValid() ) > continue; // goto the continue block below > > if ( address.IsLoopback() ) > continue; > > if ( address.GetType() == ADDRESS_IPV6 && !address.IsGlobalUnicast() ) > continue; > > addresses[numAddresses++] = address; > > if ( numAddresses >= maxAddresses ) > break; > > continue > { > // Whatever else you like here. > pUnicast = pUnicast->Next > } // on normal exit goto the regular continue point of the loop. > } > > This seems useful to me and would solve the points mentioned above and it > could be added without introducing any new keywords. It > would make goto even less useful and allow use in multiple loops without > having to makeup random label names etc. > > The continue block might be better outside of the loop to avoid excessive > indentation or at the start inside the loop for clarity. It might also need > some re-jigging to get the syntax to play nicely with the "for else" type > suggestions I've seen, so bare that in mind too when thinking about this. > But you get the basic idea. > > I'd appreciate peoples thoughts on the merit of the core idea first and > then where they think the continuation block should go. > > I expect this feature if adopted would to be available in while and do > loops etc. too. > > Thanks > GM > I get the idea, but I really don't like the syntax for it. Especially since it's based on a symptom (ie: how you would write it with goto) rather than the problem. The actual problem is that there are times when your iteration statement can't be a single expression. So what you want is to have a multi-expression iteration statement. So... do that: for ( int i = 0; pUnicast != NULL; pUnicast = pUnicast->Next; i++) { Address address( (sockaddr_storage*) pUnicast->Address.lpSockaddr ); if ( !address.IsValid() ) continue; // goto the continue block below if ( address.IsLoopback() ) continue; if ( address.GetType() == ADDRESS_IPV6 && !address.IsGlobalUnicast() ) continue; addresses[numAddresses++] = address; if ( numAddresses >= maxAddresses ) break; } This puts all of the iteration logic in the same place: the `for` statement itself. So if you want to see what happens on each loop, you don't have to look at both the top and the bottom of the `for` statement. -- 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/28358863-5be0-401a-893a-0ae5385156c2%40isocpp.org. ------=_Part_232_1905488901.1469459302808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, July 25, 2016 at 2:40:42 AM UTC-4, gmis...@gmai= l.com wrote:
<= div>Hi

I was recently reading a reddit article whe= re a piece of code=C2=A0like this appeared:

for ( = int i =3D 0; pUnicast !=3D NULL; i++ )
{
=C2=A0=C2=A0 Address address= ( (sockaddr_storage*) pUnicast->Address.lpSockaddr );

=C2=A0=C2= =A0 if ( !address.IsValid() )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto next_u= nicast;

=C2=A0=C2=A0 if ( address.IsLoopback() )
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 goto next_unicast;

=C2=A0=C2=A0 if ( address.GetType= () =3D=3D ADDRESS_IPV6 && !address.IsGlobalUnicast() )
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 goto next_unicast;

=C2=A0=C2=A0 addresses[numA= ddresses++] =3D address;

=C2=A0=C2=A0 if ( numAddresses >=3D maxA= ddresses )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;

next_unicast:
=C2=A0=C2=A0 pUnicast =3D pUnicast->Next;
}

A common=C2=A0response to the article was to immediately at= tack the code and re-write it without using goto because people considered = it sloppy. This got me thinking about a few things:

#1 It reminded me=C2=A0how fearful people are=C2=A0of goto so that they w= on't use it even if it's appropriate;=C2=A0and not only that, but t= hey=C2=A0will also re-write=C2=A0other peoples code=C2=A0using goto=C2=A0to= avoid it even if it isn't a big deal. The example loop above isn't= that unreasonable=C2=A0especially if you imagine you might want to add add= itional statements later at the goto target point. That then brings me to m= y main point:

#2=C2=A0Sometimes I want to=C2=A0exe= cute=C2=A0the same=C2=A0set of=C2=A0code on continuation and putting it all= in the increment section of the loop isn't that nice or even realistic= .. But using a goto isn't that nice either or having someone re-write=C2= =A0code just because *they* don't like goto.

P= roposal:
If we had a special continue block in the language, thes= e problems wouldn't exist because=C2=A0we could re-write the above loop= =C2=A0like=C2=A0so:=C2=A0

for ( int i =3D 0; pUnic= ast !=3D NULL; i++ )
{
=C2=A0=C2=A0 Address address( (sockaddr_storag= e*) pUnicast->Address.lpSockaddr );

=C2=A0=C2=A0 if ( !address.Is= Valid() )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continue; // goto the continue = block below

=C2=A0=C2=A0 if ( address.IsLoopback() )
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 continue;

=C2=A0=C2=A0 if ( address.GetType() =3D= =3D ADDRESS_IPV6 && !address.IsGlobalUnicast() )
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 continue;

=C2=A0=C2=A0 addresses[numAddresses++] =3D= address;

=C2=A0=C2=A0 if ( numAddresses >=3D maxAddresses )
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;

=C2=A0=C2=A0 continue
=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Whatever= else you like here.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pUnicast =3D p= Unicast->Next
=C2=A0=C2=A0=C2=A0} // on normal exit goto the r= egular continue point of the loop.
}

This seems=C2=A0useful to me and would solve the points mentioned above an= d=C2=A0it could be added without introducing any new keywords.=C2=A0It woul= d=C2=A0make=C2=A0goto=C2=A0even less useful and allow use=C2=A0in multiple = loops=C2=A0without having to makeup=C2=A0random label names etc.=C2=A0

The continue block=C2=A0might be better=C2=A0outside o= f=C2=A0the loop to avoid excessive indentation=C2=A0or at the start inside = the loop for clarity.=C2=A0It=C2=A0might also need some re-jigging to get= =C2=A0the syntax to play nicely with the "for else" type suggesti= ons I've seen, so bare that in mind too when thinking about this. But y= ou get the basic idea.

I'd appreciate peoples = thoughts on the merit of the core=C2=A0idea first and then=C2=A0where they = think the continuation block should go.

= I expect=C2=A0this feature if adopted would=C2=A0to be available in while a= nd do loops etc. too.

Thanks
GM

I get the idea, but I really don&#= 39;t like the syntax for it. Especially since it's based on a symptom (= ie: how you would write it with goto) rather than the problem.

The a= ctual problem is that there are times when your iteration statement can'= ;t be a single expression. So what you want is to have a multi-expression i= teration statement. So... do that:

for ( int= i = =3D 0; pUnicast !=3D NULL;
=C2=A0 pUnicast =3D pUnicast->Next; i++)
{
=C2=A0 =C2=A0Address address( (sockaddr_storage*) pUnicast->A= ddress.lpSockaddr );

=C2=A0 =C2= =A0if ( !address.IsValid() )=
=C2=A0 =C2=A0= =C2=A0 co= ntinue; // goto the continue b= lock below=

=C2=A0 =C2=A0if ( address= .IsLoopback() )
=C2=A0 =C2=A0 =C2=A0 continue;

=C2=A0 =C2=A0if ( address.GetType() =3D=3D ADDRESS_IPV6 && !address.IsGlobalUnicast() )
=C2=A0 =C2=A0 =C2=A0 continue;

=C2=A0 =C2=A0addresses[numAddresses++] =3D address;
=C2=A0 =C2=A0if ( numAddresses = >=3D maxAddresses )
=C2=A0 =C2=A0 =C2=A0 = break;
}
<= br>This puts all of the iteration logic in the same place: the `for` statem= ent itself. So if you want to see what happens on each loop, you don't = have to look at both the top and the bottom of the `for` statement.

--
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/28358863-5be0-401a-893a-0ae5385156c2= %40isocpp.org.
------=_Part_232_1905488901.1469459302808-- ------=_Part_231_358107579.1469459302807-- .