220 3627 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "break break ;" etc. to break out of nested loops Date: Sun, 7 Apr 2013 19:06:38 -0700 (PDT) Lines: 184 Approved: news@gmane.org Message-ID: References: <1f964e4b-2762-43b8-85e5-41392926b07a@isocpp.org> <51614514.2060103@bubblescope.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3930_3918084.1365386798374" X-Trace: ger.gmane.org 1365444767 24495 80.91.229.3 (8 Apr 2013 18:12:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Apr 2013 18:12:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMGMRCFQKGQEL2QVDRI@isocpp.org Mon Apr 08 20:12:51 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPGYj-0006C8-VY for gclcip-std-proposals@m.gmane.org; Mon, 08 Apr 2013 20:12:50 +0200 Original-Received: by mail-gh0-f198.google.com with SMTP id r11sf8503175ghr.5 for ; Mon, 08 Apr 2013 11:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to: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=c/ELRjlQAVPxntdF6aIELJpD5+SYOK70eZ/MpIZukp4=; b=KZWp1iRb+L9mX2tfTOU04bmTpOen1/FU0X0WF4+MOPNNzb+KO93lXWzag0s+MeaNmI gZhObZYyOxuGUOBI5fEovPFN1shCiqvN+DKnHYYgl5lgIVLZUInbdqJBsKaOQoVJm+wE ruFCrjlFuI9amdgNYyPW9vsigeomVMwV+CNpmw5+yQEfMgrPA7w+sbGyFyJOUkF9+7cu sE8MRVc2G+EcgONIxpVOVAwXFdZ7LfsYkEo01yda2rHdyJUKZd5w1jjLgosZBIc9OAwx 7ywBDIYvi6ZvFmDzb5gVyTlPKEXd2WNoWxUcIFWBTLcw0Dxa/Nr+QTWlj89S2nqb/jga E97g== X-Received: by 10.224.18.132 with SMTP id w4mr4872273qaa.1.1365386800889; Sun, 07 Apr 2013 19:06:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.82.83 with SMTP id g19ls2832498qey.51.gmail; Sun, 07 Apr 2013 19:06:38 -0700 (PDT) X-Received: by 10.49.82.134 with SMTP id i6mr1486306qey.20.1365386798821; Sun, 07 Apr 2013 19:06:38 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:3627 Archived-At: ------=_Part_3930_3918084.1365386798374 Content-Type: text/plain; charset=ISO-8859-1 On Sunday, April 7, 2013 11:40:04 AM UTC-7, Benjamin Lindley wrote: > > On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris Jefferson wrote: >> >> On 05/04/13 20:23, temp...@freemail.hu wrote: >> >> I hesitate to suggest this simple enhancement to the language, because >> it's so obvious that *somebody* must have thought of it before. In which >> case there must have been a good reason for rejecting it! But here goes: >> >> *Problem* >> The *break* statement jumps out of the nearest enclosing *do, for, >> switch, *or *while *statement. All programmers know that breaking out of >> a nested for-loop to the *second*-nearest enclosing *do, for, switch, * >> or *while *statement is a pain, and requires a *goto* statement or worse. >> >> *Suggestion* >> I suggest the following syntax: >> >> The *break break* statement jumps out of the second-nearest enclosing *do, >> for, switch, *or *while *statement. >> The *break break* *break *statement jumps out of the third-nearest >> enclosing *do, for, switch, *or *while *statement. >> The *break break* *break break *statement jumps out of the >> fourth-nearest enclosing *do, for, switch, *or *while *statement. >> >> And so on. For instance: >> >> for (int i = 0 ; i < 10 ; i++) >> for (int j = 0 ; j < 10 ; j++) >> for (int k = 0 ; k < 10 ; k++) { >> // do stuff >> if (a[i][j][k] == 0) break break break ; // the same as "goto >> ContinueExecution ;" >> } >> ContinueExecution: >> >> Easy to understand. Easy to implement. 100% backwards compatible. >> What's not to like? >> >> >> Serious question: If this is equivalent to 'goto ContinueExecution', then >> why not just teach people to use goto? That has the advantage that I don't >> have to be careful to figure out where 'break break break;' will go, I can >> see the label! >> >> Chris >> > > It's only equivalent if the label ContinueExecution is actually there. > With the goto, you can't be sure where it's actually going to until you > actually find that label. That could be up or down any distance within the > function. With "break break;", you know exactly where to look. Down to the > end of the loop, and then down to the end of the next one. Doesn't seem > that hard to me. > I'm with everyone else; we shouldn't add syntax that encourages people to write such loops. They should be sufficiently exceptional circumstances in your code that people should have to use exceptional syntax (ie: gotos) to do it. -- --- 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/?hl=en. ------=_Part_3930_3918084.1365386798374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sunday, April 7, 2013 11:40:04 AM UTC-7, Benjamin Lindley wrote:On Sunday, April 7, 2013 5:06:12 AM UT= C-5, Chris Jefferson wrote:
=20 =20 =20
On 05/04/13 20:23, temp...@freemail.hu wrote:
I hesitate to suggest this simple enhancement= to the language, because it's so obvious that somebody must have thought of it before. In which case there must have been a good reason for rejecting it! But here goes:

Problem
The break statement jumps out of the nearest enclosing do, for, switch, or while statement. All programmers know that breaking out of a nested for-loop to the second-nearest enclosing do, for, switch, = ;or while statement is a pain, and requires a goto statement or worse.

Suggestion
I suggest the following syntax:

The break break statement jumps out of the second-nearest enclosing do, for, switch, or&nbs= p;while statement.
The break break break statem= ent jumps out of the third-nearest enclosing do, for, switch, or&= nbsp;while statement.
The break break break break = statement jumps out of the fourth-nearest enclosing do, for, switch, = ;or while statement.

And so on. For instance:

for (int i =3D 0 ; i < 10 ; i++)
  for (int j =3D 0 ; j < 10 ; j++)
    for (int k =3D 0 ; k < 10 ; k++) {
      // do stuff
      if (a[i][j][k] =3D=3D 0) break break brea= k ; // the same as "goto ContinueExecution ;"
    }
ContinueExecution:

Easy to understand. Easy to implement. 100% backwards compatible. What's not to like?

Serious question: If this is equivalent to 'goto ContinueExecution', then why not just teach people to use goto? That has the advantage that I don't have to be careful to figure out where 'break break break;' will go, I can see the label!

Chris
 
It's only equivalent if the = label ContinueExecution is actually there.  With the goto, you can't b= e sure where it's actually going to until you actually find that label.&nbs= p; That could be up or down any distance within the function.  With "b= reak break;", you know exactly where to look. Down to the end of the loop, = and then down to the end of the next one.  Doesn't seem that hard to m= e.

I'm with everyone else; we shouldn't add = syntax that encourages people to write such loops. They should be sufficien= tly exceptional circumstances in your code that people should have to use e= xceptional syntax (ie: gotos) to do it.

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_3930_3918084.1365386798374-- .