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
Received on 2015-03-06 12:02:44 CET