Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c Subject: Re: Value of microeffiency (was: Re: Optimal ...) Message-ID: <483@proxftl.UUCP> Date: 17 Jul 88 11:43:07 GMT References: <163@navtech.uucp> <2775@ttrdc.UUCP> <164@navtech.uucp> <4616@b-tech.UUCP> <472@proxftl.UUCP> <255@chem.ucsd.EDU> Reply-To: bill@proxftl.UUCP (T. William Wells) Organization: Proximity Technology, Ft. Lauderdale Lines: 28 Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <255@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes: > In article <472@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: > >In article <4616@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes: > >) In article <688@clsib21.UUCP> ebg@clsib21.UUCP (Ed Gordon) writes: > >) >>> [I wrote a much-faster clone of qsort() using linked-lists] > > However, I might go ahead and > >publish it. There is one minor gotcha: the drawback, not copied > >in the message above, is that the routine has got to get memory > >for the linked list. > > Rewrite your interface so that the user must supply the memory for > the linked list and free it himself, so that if allocation/deallocation > is an issue, the user can handle it. That leads to a quandry: should I make it a qsort replacement or not? If so, then this is not reasonable. If not, then it is less useful. Then again, I could write it with variable arguments and a global control variable that determines whether it does the allocation or whether the caller passes allocated memory. And that requires conditional compilation for those who do not want to pull in malloc. Ugh! Sigh.