Re: [PATCH 1/6] Introduce sorted-array binary-search function.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 10, 2010, 22:29 UTC
- Message-ID
- <7vwrnhb6tm.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1291848695-24601-2-git-send-email-ydirson@altern.org>
Yann Dirson <ydirson@altern.org> writes:
Show 5 quoted lines
> +Suffix meanings are as follows: > + > +`check`:: > +... > +* those defining the generic algorithms
Yuck.
All of these feel way overengineered and at the same time too rigid and brittle.
I have a suspicion that the "convenience" macros that generate many functions and definitions are the main culprit. For example, why do all the functions generated by a "convenience" macro must share the same MAYBESTATIC? "binsearch" takes a comparison function pointer, and always picks the midpoint, but what is the performance implication if we wanted to use sorted-array.h to rewrite say sha1-lookup.c? How can an API user who wants to use declare_sorted_array_insert_checkbook() easily figure out what other macros fromt this family can be used without getting the same thing generated twice? If somebody wanted to have a sorted array in a struct, it may be tempting to use declare_sorted_array() with an empty MAYBESTATIC inside struct's field declaration (even when the struct itself is static---which leaves a queasy feeling, but that is a separate issue), and the _current_ macro definition of declare_sorted_array() may allow such a usage work perfectly fine, but how can such an API user be rest assured it won't break in later revisions of these macros?
In addition, these macros in this patch are almost unreadable, but that probably is mostly a fault of C's macro, not yours.