>seeing second posting

I think that you should make a two-pass of it. (q)icksort knows nothing of
the data structure, excepting its size. It calls a function you supply.

Since the function that evaluates the cost (sort key) of each vector is
expensive, and needed several times, I'd first run through the vector to
compute this cost (key) and store it in the vector in an additional field
(or is that what you use 'blanks' for ?), then call qsort and set a
comparison function that simply compares the keys in the vectors. Why do
you need all those operators in the class ?

Since qsort does a copy on every inequality you can halve (or third, or
more, as who knows how big the runtime size of quine instances is - can
you post a sizeof(quine) printed at runtime ?), the amount of data moved
by using a second vector of (8 million) pointers into the vector of quine.
(I know how this sounds). The vector is initialized to unity
(a[i]=quine[i]) and qsort re-arranges it, so a[0..8E6] is your sorted
output. Whether or not this will speed things up depends on the amount of
RAM you have. If you have 96+ MB of RAM for the application, use the third
vector, if not, use qsort on the quine vector (with computed keys). In
general, if you swap (to disk), you lose ;) imho.

To compute the cost (sort key = number of 1's) the algorythm invented for
PICs could be used with some changes for 32 bits. The algorythm (? by John
Payson(sp?)) is available somewhere in the piclist archives.

good or bad ? who knows. But you need like 128MB of RAM to make this
'fast' on a normal (home PC) machine, and it will take a few seconds even
at 1000MHz.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.