[futurebasic] Re: [FB] Sorting Records on multiple key fields within the record

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : April 2009 : Group Archive : Group : All Groups

From: Brian Stevens <bstevens33@...>
Date: Tue, 28 Apr 2009 20:51:38 -0700
On Apr 28, 2009, at 6:38 PM, Max Taylor wrote:

>
> “CompareForSort” function, whose address is passed to on to qsort_r  
> is used for and sets up the entire criteria for the actual sort  
> itself if this function address is passed to qsort_r. Correct?  
> (answered above)
CompareForSort is a callback and is very similar to other callbacks  
such as a databrowser item data callback. The databrowser uses the  
same basic method of a callback to find out how ( i.e. less than,  
greater than or equal ) two pieces of data ( typically  in a column  
where the user controls the sort by clicking on the column ) are  
related in order to sort. In the databrowser itemIDs ( two of them )  
are passed to the item compare callback. The callback is invoked many  
times with each iteration passing two items. This sort uses  
essentially the same method with aIndexAddr and bIndexAddr except they  
are obviously pointers

>
>
> Also, I have to assume that ANY comparator function one defines  
> could also be used as long as the address of that function is passed  
> on to  qsort_r as the last argument.
Yes, the programmer is responsible for supplying their own comparison  
function.

>
>
> Also, since in the example you use an index named gIndex(…) that  
> will contain the end results as an index of the final sorted order  
> THEN is there any reason whatever that one could not create multiple  
> indices for use on the same array to be used as needed.
No. The programmer could create and use as many indices as they choose  
to maintain.

>
> Question:
>
> fn CompareForSort( arrayAddr as ptr, aIndexAddr as ptr, bIndexAddr  
> as ptr ) takes three arguments in this example, the array to sort  
> and two indices, yet qsort_r, being only passed its address, has no  
> way of knowing how many indices it is supposed to sort by in  
> advance. How does this work?
The sort processes the entire data file and calls the callback many  
times during this process. As mentioned above, each time the callback  
is invoked it passes two pieces of data. They are pointers to two  
indices within the data array. The sort is asking the callback  
function to tell it if the two items passed ( indirectly ) are equal,  
GT or LT. Of course, the address of the data array is also passed to  
the callback via "thunk" and the array to sort ( the index array ) is  
also passed.

>
> Does it use something like va_list internally or what?
I haven't seen source for qsort_r, but there is no reason to expect a  
variable argument list ( but I've been wrong before ). Sounds like  
you've been working with va_list a lot and possibly making this more  
complicated than it is. If I missed your point, please post again and  
forgive my slowness.


>
> Does it infer arguments by seeing the function definition prior in  
> the listing as a sort of prototype?
the toolbox statement simply allows the system function to be called.  
There are no arguments to be inferred AFAIK since they are explicitly  
defined.
>
> Is there a theoretical limit to the number of indices one could use?
No, not that I'm aware of.  Try it and find out.

>
> I know that this may seem quite understandable to some but there are  
> still some confusions in my mind. Maybe a few others have similar  
> issues trying to fully comprehend it.

The "thunk" argument is the only unusual one. It is like a utility  
argument to be used by the programmer to pass something to the  
comparison function. In the demo's case, it is used to pass the  
address of the data array ( remember we're sorting the index ). The  
"thunk" argument is always passed as the first ( in our case the  
arraryAddr pointer ) argument ( see documentation:   in a terminal  
window  "man qsort".  ) to the comparison function.

I wrote all of that quickly, so please excuse the redundancies. HTH.

Brian S