www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/03/14/13:00:50

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Mon, 14 Mar 2016 13:00:06 -0400
Message-Id: <201603141700.u2EH06la024493@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <alpine.DEB.2.00.1603140610270.7885@igor2priv>
(gedau AT igor2 DOT repo DOT hu)
Subject: Re: [geda-user] pcb: more memory leaks
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1603130700180 DOT 7885 AT igor2priv> <alpine DOT DEB DOT 2 DOT 00 DOT 1603140610270 DOT 7885 AT igor2priv>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> not a leak, just wondering: hid/common/flags.c:hid_find_init() why
> do we implement bsearch() in the second half of the function instead
> of just calling it, especially that we did not implement our own
> qsort()?  bsearch() should be as portable as qsort() - both are
> C89. (In pcb-rnd I've replaced the whole thing with a
> string->pointer hash, so I don't need a linked list, an array and a
> flag to remember whether the array is sorted, etc - shorter,
> simpler, faster code (r1261)).

binary search is so simple to implement, that using bsearch() would
not have saved that many bytes and/or cycles.  A hash would make more
sense but I was going for "what can I type in the fastest" :-)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019