On 27.04.2018 21:23, Greg Stein wrote:
> At one point, we used to use an svn_array_find() or some such. We
> deprecated it. Creating a function to do comparisons, then set up a
> function call... It was just annoying. Iteration over an APR array is
> easy, and very clear. There is basically no code or mental overload.
> Using a comparator function, there is.
Yes, I was thinking along those lines, too ... consider:
const char* key = "key";
int i;
for (i = 0; i < array->nelts; ++i) {
if (0 == strcmp(key, APR_ARRAY_IDX(array, i, const char*)))
break;
}
Compare that to:
static int compare(const void* x, const void* y) {
return strcmp(*(const char**) x, (const char*) y));
// Oops ... is the first argument the pointer to the
// array element and the second the search key, or is
// it the other way around? Or do we have to dereference
// the search key in order to make these arguments
// symmetric?
}
// ... lots of code in between
int i = apr_array_find(array, compare, "key");
The first form is definitely easier to understand and nicely localized.
"Explicit is better than implicit" and all that.
-- Brane
>
> -0 on the concept.
>
> Cheers,
> -g
>
> ps. and if written, it *should* allow for structs; we use those often
> in svn. Avoids alloc'ing a structure and sticking a ptr in the array.
>
> On Fri, Apr 27, 2018, 13:46 William A Rowe Jr <wr...@rowe-clan.net
> <mailto:wr...@rowe-clan.net>> wrote:
>
> SVN's extensions to apr largely exist here;
>
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/
>
> Because they are based on apr and rooted in that ecosystem, there
> are a number of useful extensions in that repo that were never
> pushed upstream, but are not "withheld". Nobody had the time to
> submit and champion them.
>
> On Fri, Apr 27, 2018, 13:25 Jim Riggs <jim...@riggs.me
> <mailto:jim...@riggs.me>> wrote:
>
> > On 27 Apr 2018, at 11:50, William A Rowe Jr
> <wr...@rowe-clan.net <mailto:wr...@rowe-clan.net>> wrote:
> >
> > If we code this abstractly, comparator declaration is not
> type-safe, but can
> > be declared so that it is usable by table, hash, b-tree and
> many other
> > approaches to data organization. With clever use of
> wrappers, we should
> > be able to make a derivation (counted-byte-string tables,
> for example)
> > behave in a type-safe manner at no performance penalty.
> >
> > We should cross check the subversion util feature set to
> ensure we don't
> > have something ready to borrow, already.
>
> I fear things have now started going over my head. :-) I'll
> try to keep up.
>
