| Re: Convenient array & hash iterators & accessors
From: Julian Foad <julianfoad_at_btopenworld.com>
 Date: Fri, 6 Mar 2015 10:30:21 +0000 
Hi, Greg and Brane. Thanks for your feedback.
 Branko Čibej wrote:
 The new functions are aimed at making typical, shortish loops shorter and clearer to read. Those previous iterators were too cumbersome for most cases and rarely useful.
 >> I find the SVN_ITER_T() and SVN_ARRAY_ITER() macros in your example to
 At first sight, yes, of course, but they could quickly become a familiar idiom.
 > Agreed. The new macros don't really add any type safety, since they rely
 That's right: they do not check that the declared element type of an array/hash matches the type requested for iteration, except that it is a pointer.
 The comment about 'parameterized element type' does not refer to type *safety* but rather means that the iterator's 'val' field has the requested type rather than 'void *', which enables using it directly as an element pointer like this:
   for (SVN_ARRAY_ITER(i, array_of_string_t, pool))
 rather than having to first assign it to a variable of the correct type like this:
   for (SVN_ARRAY_ITER(i, array_of_string_t, pool))
       foo(s->data, s->len);
 > I'm also *very* scared of the
 It's invoked only if you write "..._SORTED()" or "..._sorted()". That's explicit and visible. What's so scary about that?
 > It would make sense to design type-safe, light-weight container and
 I understand the point. I note that "explicit" is not a binary quality: there are degrees of it.
 I suppose I want to be writing in a higher level language. Maybe I should just go ahead and really do so.
 - Julian
 | 
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.