[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Convenient array & hash iterators & accessors

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 06 Mar 2015 11:46:37 +0100

On 06.03.2015 11:30, Julian Foad wrote:
> Hi, Greg and Brane. Thanks for your feedback.
>
> Branko Čibej wrote:
>> Greg Stein wrote:
>>> We've seen some of this kind of stuff in svn_iter.h, and it did not
>>> turn out to be useful. The additional concepts needed to
>>> learn/keep/use costed more than the incremental benefit.
> 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
>>> be rather inscrutable.
> 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
>> on implicit conversions from void*.
> 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))
> foo(i->val->data, i->val->len);
>
> 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))
> {
> svn_string_t *s = i->val;
>
> foo(s->data, s->len);
> }
>
>> I'm also *very* scared of the
>> implicit, hidden qsort in the sorted.
> 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
>> iterator template wrappers around the APR structures if we decided to
>> write code in C++. Since we're not, "explicit is better than
>> implicit".
> 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.

Many of us do, I guess. :) But as long as we're stuck with C and APR,
it's worth considering the actual gain of any macro wrappers compared to
their apparent gain. This was very painfully demonstrated recently with
the fun we had with svn_hash_sets/gets.

-- Brane
Received on 2015-03-06 11:47:54 CET

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.