220 3589 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: "break break ;" etc. to break out of nested loops Date: Sat, 6 Apr 2013 06:59:47 -0700 (PDT) Lines: 114 Approved: news@gmane.org Message-ID: References: <1f964e4b-2762-43b8-85e5-41392926b07a@isocpp.org> <85c0ae97-3440-4a81-96c2-1af7ebb892ba@isocpp.org> <1365208009.32597.12.camel@patrick-laptop-debian.home> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2833_14956985.1365256787789" X-Trace: ger.gmane.org 1365270103 6255 80.91.229.3 (6 Apr 2013 17:41:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Apr 2013 17:41:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBVOUQCFQKGQETCQZLBY@isocpp.org Sat Apr 06 19:41:44 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f71.google.com ([209.85.212.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UOWTl-0007u8-Cy for gclcip-std-proposals@m.gmane.org; Sat, 06 Apr 2013 19:00:37 +0200 Original-Received: by mail-vb0-f71.google.com with SMTP id w16sf5575542vbb.2 for ; Sat, 06 Apr 2013 10:00:36 -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=xCdTSeRDUGQlgksd0ojPRGrJ7lCHB9Gpc6A933f6UkY=; b=MmfvwNl3DbRYY0jFmU3Wt83k+8Dp/CbJTE5FSdD6VB8DjShJqv8m9YxOPSJ0WwEiul +FMSHEVDdfXGJ2udCk1+4nn5l0vmtZhQW696p0aoJghJqjQbDake6XEQ2DOZ6DxVgJ/B rxDhA/jmjT2/xNZsgBsIyJwA/81vP/Raevk9Nqf+VICUWpv8PKJ2nhFQSiku/odWLMtR x+CVRWcDUyP7zO4O6miBLd8RsXgT22TLRVGHzmED0vpTrsBz3bkM0eHvaXj9smCPkZle /B7m+wFEQPbeq8o58eX9gOZfTQBtxsBDUXA2J19KCgIhOfnkwYdVgZLeK+4CNuf1mLMM qWZQ== X-Received: by 10.224.157.1 with SMTP id z1mr1319106qaw.8.1365256790026; Sat, 06 Apr 2013 06:59:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.3.138 with SMTP id c10ls2547095qec.54.gmail; Sat, 06 Apr 2013 06:59:48 -0700 (PDT) X-Received: by 10.49.85.106 with SMTP id g10mr1271132qez.13.1365256788426; Sat, 06 Apr 2013 06:59:48 -0700 (PDT) In-Reply-To: <1365208009.32597.12.camel@patrick-laptop-debian.home> X-Original-Sender: akrzemi1@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:3589 Archived-At: ------=_Part_2833_14956985.1365256787789 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu sobota, 6 kwietnia 2013 02:26:49 UTC+2 u=BFytkownik Patrick M.=20 Niedzielski napisa=B3: > > On ven, 2013-04-05 at 12:53 -0700, Andrew Sandoval wrote:=20 > > How about *return*? That way you are pushed towards keeping your=20 > functions=20 > > simple.=20 > > [slightly off-topic, but keeping the same thread for now]=20 > > For large and complex loops, this is good advice. For small and short=20 > nested loops (looping a single statement over a two dimensional array),= =20 > breaking the code off into a separate function can (*can*, not *will*)=20 > make the code harder to understand. It should be determined on a=20 > case-by-case basis whether breaking the code into a separate function is= =20 > actually productive or makes the flow and reasoning behind the code less= =20 > clear.=20 > > This is actually an okay place for a goto, if the loops are short and=20 > clear, and breaking the two loops into a separate function doesn't make= =20 > sense. Just be sure to document the reason for its use in the code.=20 > + 1 Programmers are told to avoid "goto" so aggressively, that they forget it= =20 is sometimes just useful. Goto offers functionality only slightly worse=20 that labelled loops. And given that the problem we are trying to solve=20 occurs fairly rarely (or am I wrong?), I do not believe an alternative to= =20 "goto" is worth the C++ Committee's effort. Regards, &rzej =20 --=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/?hl=3Den. ------=_Part_2833_14956985.1365256787789 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu sobota, 6 kwietnia 2013 02:26:49 UTC+2 u=BFytkownik Patrick = M. Niedzielski napisa=B3:
On ve= n, 2013-04-05 at 12:53 -0700, Andrew Sandoval wrote:
> How about *return*?  That way you are pushed towards keeping = your functions=20
> simple.

[slightly off-topic, but keeping the same thread for now]

For large and complex loops, this is good advice.  For small and s= hort
nested loops (looping a single statement over a two dimensional array),
breaking the code off into a separate function can (*can*, not *will*)
make the code harder to understand.  It should be determined on a
case-by-case basis whether breaking the code into a separate function i= s
actually productive or makes the flow and reasoning behind the code les= s
clear.

This is actually an okay place for a goto, if the loops are short and
clear, and breaking the two loops into a separate function doesn't make
sense.  Just be sure to document the reason for its use in the cod= e.

+ 1
Programmers are told to avoid "goto" so ag= gressively, that they forget it is sometimes just useful. Goto offers funct= ionality only slightly worse that labelled loops. And given that the proble= m we are trying to solve occurs fairly rarely (or am I wrong?), I do not be= lieve an alternative to "goto" is worth the C++ Committee's effort.

= Regards,
&rzej

 

--
 
---
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_2833_14956985.1365256787789-- .