From owner-svn-src-all@freebsd.org Thu Apr 21 15:18:47 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC4B9B157EB; Thu, 21 Apr 2016 15:18:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7373117D; Thu, 21 Apr 2016 15:18:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7B0A8B93C; Thu, 21 Apr 2016 11:18:46 -0400 (EDT) From: John Baldwin To: Bruce Evans Cc: araujo@freebsd.org, "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r298247 - head/sbin/fdisk_pc98 Date: Thu, 21 Apr 2016 08:14:52 -0700 Message-ID: <2005850.CZJyyynVaq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160421150811.K1013@besplex.bde.org> References: <201604190446.u3J4kD9G050780@repo.freebsd.org> <17068472.zUDTmEYeVg@ralph.baldwin.cx> <20160421150811.K1013@besplex.bde.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Apr 2016 11:18:46 -0400 (EDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:18:48 -0000 On Thursday, April 21, 2016 04:01:17 PM Bruce Evans wrote: > On Wed, 20 Apr 2016, John Baldwin wrote: > > > On Wednesday, April 20, 2016 01:06:38 PM Bruce Evans wrote: > >> On Wed, 20 Apr 2016, Marcelo Araujo wrote: > >> > >>> 2016-04-20 0:16 GMT+08:00 John Baldwin : > >>> > >>>> On Tuesday, April 19, 2016 04:46:13 AM Marcelo Araujo wrote: > >>>>> Author: araujo > >>>>> Date: Tue Apr 19 04:46:13 2016 > >>>>> New Revision: 298247 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/298247 > >>>>> > >>>>> Log: > >>>>> Remove redundant parenthesis. > >>>>> > >>>>> Submitted by: pfg > >>>>> MFC after: 2 weeks. > >> > >> I don't realling like churnging to the nonstandard nitems(). Use > >> of the nonstandard is bad enough. > > > > I think it's not that bad from a readability standpoint. Other languages > > have fairly concise syntax for 'for-each' loops and this provides a > > closer variant of that for statically sized arrays. TAILQ_FOREACH() is > > still nicer of course. One could imagine doing some sort of > > ARRAY_FOREACH() that was: > > Ugh, I really realling (sic) don't like the FOREACH macros. The FOREACH > macros add syntactic salt. The queue macros were bad enough before they > had FOREACH. Arrays don't start with such nastiness. > > > #define ARRAY_FOREACH(p, array) \ > > for (size_t __i = 0, (p) = &(array)[0]; __i < nitems((array)); __i++, (p)++) > > This only works in the not very usual case of a simple loop from the start > to the end. Even the name EACH becomes wrong if the range is anything else. > For full nastiness, add a few hundred FORFOO macros to handle multi- > dimensional arrays with different access methods, array slices, sentinels > and other terminating conditions, etc. Actually, combined with break this is a common case. The fairly widespread use of the queue FOREACH macros (and most of the uses of nitems() in the tree) are a testament to this. > > Perhaps better is this: > > > > #define ARRAY_FOREACH(p, array) \ > > for ((p) = &(array)[0]; (p) < &(array)[nitems((array))]; (p)++) > > > > (No need for __i) > > But hiding the indexes forces the old C programming idiom of using > pointers for everything. A mere few hundred FORFOO macros won't do. > For just 1-dimensional FOREACH, you need 3 versions to expose p, i or > both p and i. If someone wanted 'i' they could maintain it on their own through the loop. In practice, 'foreach' is a common idiom in other languages and is used to mean 'for each item in container'. The 'short' syntax always implies a full iteration (though you could use break to bail early). For example, in python: for item in list: # do stuff Or in C++11: for (p : array) { } In C++11 I think this only works for std::array rather than a plain C array, though compared to a fixed-size array for which nitems() works, std::array is equivalent. Both of these work for dynamically sized containers for which our queue macros are the equivalent. -- John Baldwin