Branko Čibej wrote: > On 06.03.2015 11:30, Julian Foad wrote: >> Branko Čibej wrote: >>> 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? > > The term "sorted iteration" is ambiguous. In this case, it means "sort > the container, then iterate", which means it has a side effect.
No, in this case it means the common meaning you suggest it should have. See the doc strings: +/** Like SVN_ARRAY_ITER but iterating over a copy of the array sorted by + * @a comparison_func. */ +#define SVN_ARRAY_ITER_SORTED(i, array, comparison_func, pool) \ +/** Start iterating over the array @a array, in sorted order according to + * @a comparison_func. Return a pointer to the first element, or NULL if + * there are no elements. + * + * It is permissible to change the original array @a array during the + * iteration. Doing so will not affect the sequence of elements returned + * by svn_array__next(), as svn_array__sorted_first() takes a snapshot of + * pointers to the original keys and values. The memory in which the + * original keys and values of HT are stored must remain available during + * the iteration. + */ +svn_iter_t * +svn_array__sorted_first([...] > A more > common meaning is "iterate in sorted order, leaving the container > unchanged". See, for example, Python's sorted() generator adaptor. > > It's much more visible and unambiguous to sort the container and then > iterate on the result. Iterations should not have side effects on the > container. That's exactly the approach I took. - Julian
