Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Function-types: compatability, and typedefs
Message-ID: <10928@smoke.BRL.MIL>
Date: 4 Sep 89 05:15:28 GMT
References: <KERS.89Aug31164048@cdollin.hpl.hp.com> <19361@mimsy.UUCP> <1989Sep1.113440.28300@jarvis.csri.toronto.edu> <1999@munnari.oz.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <1999@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>If you're sorting an array of numbers, a half-way decent radix sort will
>GROSSLY outperform qsort(), and if you're sorting anything else qsort()
>is too inefficient anyway.

Unless the sorting operation is a bottleneck in your application,
you're probably better off using a prepackaged tested sorting routine
like qsort(), guaranteed to be in every (hosted) C library, than
spending the time it takes to get an adequate replacement designed,
coded, and tested.  qsort() isn't too bad for sorting internal
tables in most applications; its main deficiency is having to
perform a function call for every comparison.  One tip: since the
array of records undergoes numerous element swaps during the sort,
it is often best to set up an array of pointers to the actual data
items and sort the array of pointers instead.