Yann DirsonWhile writing the bulk-move series, I introduced 2 new functions, locate_bulkmove_candidate() and locate_rename_dst_dir(), closely derived from locate_rename_dst(). That was because it seemed not so trivial to overcome the differences in those 3 funcs while retaining readability.
Now when working on bulk-rm (as a new basis for next-gen bulk-move), I find myself in the need of adding more of them: again functions for searching/inserting in a sorted list of various contents. My first approach (this series) was to generalize locate_rename_dst() to operate on other "lists of a filespec and something", since that was matching my needs for "bulkrm_candidates".
Tell me your opinion on this: I find the result hard to read, and difficult to adapt to all of locate_rename_dst_dir() with its non-filespec input, let alone locate_bulkmove_candidate() with 2 of them. And even the memset() call is probably less efficient than the original "= NULL".
So I'm planning of redoing the thing with a different principle: change the core function to accept func-pointer for comparison and initialization - that would make the core func much more readable. Since those trivial funcs would be trivial static ones, compilers ought to be able to instantiate specific versions of the core func, inlining those trivial ones; if it does not, however, that would surely give a performance penalty if it does not...
The alternative, having several mostly-identical funcs, which have to be made generic anyway to prevent proliferation, seems to me much more of a hell. What's the general opinion ?
