From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [PATCH 1/6] Introduce sorted-array binary-search function. Date: Fri, 10 Dec 2010 14:29:09 -0800 Message-ID: <7vwrnhb6tm.fsf@alter.siamese.dyndns.org> References: <1291848695-24601-1-git-send-email-ydirson@altern.org> <1291848695-24601-2-git-send-email-ydirson@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org To: Yann Dirson X-From: git-owner@vger.kernel.org Fri Dec 10 23:29:28 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PRBSv-0007NS-0M for gcvg-git-2@lo.gmane.org; Fri, 10 Dec 2010 23:29:25 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754332Ab0LJW3T (ORCPT ); Fri, 10 Dec 2010 17:29:19 -0500 Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:36908 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753683Ab0LJW3S (ORCPT ); Fri, 10 Dec 2010 17:29:18 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5703033BB; Fri, 10 Dec 2010 17:29:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=ulCPcdqcBCfQ5kUYxWmZXI7t9l4=; b=dUaWSK zel4T4/2WSZGq4vakuy97nAD/oDbfbl4KYK7ASBcKfkzoFctj6hG1An+qVA3jnU1 6DFmdxTyi63zph3+U1LxspcpA0MTAwjpPRmf3qN94G6pz6qDs/sqmHdKlPSzZAuO UHyWQrxDaSeXU8VWjzXygx3rzBUXZaKU6pdn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=t0vzWMC+wcgppQqCf6ZEN4ce44YDpWAe zKK8ChwXcFAksLyoPJ/chFX3FmPXOxQ/54lwdXjlfcQlagyFhNFihH2U30RQsvzE WV4sEoiZ14fofVxbtjm43AbIDdJYEbcGVzxyh9KtxJmCbLJWj0VR2jLxIUYtICFN km7lxxzzqUY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 33AE333B9; Fri, 10 Dec 2010 17:29:40 -0500 (EST) Received: from pobox.com (unknown [76.102.170.102]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 48E9D33B8; Fri, 10 Dec 2010 17:29:37 -0500 (EST) In-Reply-To: <1291848695-24601-2-git-send-email-ydirson@altern.org> (Yann Dirson's message of "Wed\, 8 Dec 2010 23\:51\:30 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-Pobox-Relay-ID: FA52A822-04AC-11E0-8225-C4BE9B774584-77302942!a-pb-sasl-sd.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Yann Dirson writes: > +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.