How to apply qsort() with a parameter?

Discussion in 'C Programming' started by none, Oct 22, 2012.

  1. none

    none Guest

    How does one apply qsort() if the comparison criterion
    depends on a parameter?

    Specifically, suppose I wish to sort an array of int,
    according to distance from a prescribed value `n':

    int compar(const void *aa, const void *bb)
    {
    int a = *(int *)aa;
    int b = *(int *)bb;
    return abs(a - n) < abs(b - n);
    }

    One way to make this work, is to declare n as a global
    (file scope) variable. Is there a clever way to do this
    without bringing in a global variable?

    --
    Rouben Rostamian
     
    none, Oct 22, 2012
    #1
    1. Advertising

  2. none

    ImpalerCore Guest

    On Oct 22, 1:51 pm, rouben@shadow.(none) (Rouben Rostamian) wrote:
    > How does one apply qsort() if the comparison criterion
    > depends on a parameter?
    >
    > Specifically, suppose I wish to sort an array of int,
    > according to distance from a prescribed value `n':
    >
    > int compar(const void *aa, const void *bb)
    > {
    >         int a = *(int *)aa;
    >         int b = *(int *)bb;
    >         return abs(a - n) < abs(b - n);
    >
    > }
    >
    > One way to make this work, is to declare n as a global
    > (file scope) variable.  Is there a clever way to do this
    > without bringing in a global variable?


    The best method is to reparameterize the qsort function with a
    comparison that takes an external parameter.

    void qsort_ext( void* base,
    size_t num,
    size_t size,
    int (*cmp_ext_fn)( const void*, const void*, void* ),
    void* ext_data );

    Then you write your modified comparison function in this fashion.

    int compar(const void *aa, const void *bb, void *nn)
    {
    int a = *(const int *)aa;
    int b = *(const int *)bb;
    int n = *(int *)n;
    return abs(a - n) < abs(b - n);
    }

    If you have the source of a 'qsort' you want to use, you can create
    'qsort_ext' by simply adding the external parameter to the comparison
    function pointer call.

    Best regards,
    John D.
     
    ImpalerCore, Oct 22, 2012
    #2
    1. Advertising

  3. none

    ImpalerCore Guest

    On Oct 22, 2:18 pm, ImpalerCore <> wrote:
    > int compar(const void *aa, const void *bb, void *nn)
    > {
    >   int a = *(const int *)aa;
    >   int b = *(const int *)bb;
    >   int n = *(int *)n;
    >   return abs(a - n) < abs(b - n);
    > }


    The comparison should probably be 'abs(a - n) - abs(b - n)', not '<'
    which is a boolean expression.

    Best regards,
    John D.
     
    ImpalerCore, Oct 22, 2012
    #3
  4. none

    tom st denis Guest

    On Oct 22, 1:51 pm, rouben@shadow.(none) (Rouben Rostamian) wrote:
    > How does one apply qsort() if the comparison criterion
    > depends on a parameter?
    >
    > Specifically, suppose I wish to sort an array of int,
    > according to distance from a prescribed value `n':
    >
    > int compar(const void *aa, const void *bb)
    > {
    >         int a = *(int *)aa;
    >         int b = *(int *)bb;
    >         return abs(a - n) < abs(b - n);
    >
    > }
    >
    > One way to make this work, is to declare n as a global
    > (file scope) variable.  Is there a clever way to do this
    > without bringing in a global variable?


    The most portable way is to normalize your input first based on what
    you are measuring the distance from then perform your sort.

    Tom
     
    tom st denis, Oct 22, 2012
    #4
  5. none

    Eric Sosman Guest

    On 10/22/2012 1:51 PM, none Rouben Rostamian wrote:
    > How does one apply qsort() if the comparison criterion
    > depends on a parameter?
    >
    > Specifically, suppose I wish to sort an array of int,
    > according to distance from a prescribed value `n':
    >
    > int compar(const void *aa, const void *bb)
    > {
    > int a = *(int *)aa;
    > int b = *(int *)bb;
    > return abs(a - n) < abs(b - n);


    Aside: This can't be right, as it doesn't define
    a total ordering.

    > }
    >
    > One way to make this work, is to declare n as a global
    > (file scope) variable. Is there a clever way to do this
    > without bringing in a global variable?


    No, nothing clever. You could write multiple comparators,
    each hard-wiring a different `n' value:

    int compar10(const void *aa, const void *bb) {
    ... use n=10 ...
    }

    int compar20(const void *aa, const void *bb) {
    ... use n=20 ...
    }

    Or, you could subtract n from all the array elements,
    use the equivalent of compar0(), and then add n back again.
    (Sounds wasteful, but it only adds O(N) time to an operation
    that's probably O(N log N) already.)

    Neither alternative strikes me as "clever." You either
    live with the qsort() interface or write your own sort.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 22, 2012
    #5
  6. none

    Eric Sosman Guest

    On 10/22/2012 2:41 PM, Eric Sosman wrote:
    > On 10/22/2012 1:51 PM, none Rouben Rostamian wrote:
    >> How does one apply qsort() if the comparison criterion
    >> depends on a parameter?


    A further observation: Don't go overboard in parameterizing
    your comparators. A comparator may be called a large number of
    times during a sort, so it's "in the inner loop" and should be
    kept short and swift. A comparator that examines parameters
    P1,P2,P3,... in addition to the items it's comparing starts to
    stray from the "short and swift" ideal.

    A particular abuse that always seems to crop up is trying
    to use one comparator to sort on multiple keys:

    struct s {
    int k1;
    char *k2;
    double k3;
    };

    int which_key;

    int compare(const void *aa, const void *bb) {
    const struct s *a = aa;
    const struct s *b = bb;
    switch (which_key) {
    case 1:
    return (a->k1 > b->k1) - (a->k1 < b->k1);
    case 2:
    return strcmp(a->k2, b->k2);
    case 3:
    return (a->k3 > b->k3) - (a->k3 < b->k3);
    default:
    assert(false);
    }
    }

    ...
    which_key = 2;
    qsort(array, count, sizeof array[0], compare);

    This setup repeats the switch decision -- which is "just
    overhead" -- for every comparison, and there may be a lot of
    them. It would almost surely be better to have three short
    comparators than one omnibus comparator.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 22, 2012
    #6
  7. ImpalerCore <> writes:

    > On Oct 22, 1:51 pm, rouben@shadow.(none) (Rouben Rostamian) wrote:
    >> How does one apply qsort() if the comparison criterion
    >> depends on a parameter?
    >>
    >> Specifically, suppose I wish to sort an array of int,
    >> according to distance from a prescribed value `n':
    >>
    >> int compar(const void *aa, const void *bb)
    >> {
    >>         int a = *(int *)aa;
    >>         int b = *(int *)bb;
    >>         return abs(a - n) < abs(b - n);
    >>
    >> }
    >>
    >> One way to make this work, is to declare n as a global
    >> (file scope) variable.  Is there a clever way to do this
    >> without bringing in a global variable?

    >
    > The best method is to reparameterize the qsort function with a
    > comparison that takes an external parameter.
    >
    > void qsort_ext( void* base,
    > size_t num,
    > size_t size,
    > int (*cmp_ext_fn)( const void*, const void*, void* ),
    > void* ext_data );
    >
    > Then you write your modified comparison function in this fashion.
    >
    > int compar(const void *aa, const void *bb, void *nn)
    > {
    > int a = *(const int *)aa;
    > int b = *(const int *)bb;
    > int n = *(int *)n;
    > return abs(a - n) < abs(b - n);
    > }
    >
    > If you have the source of a 'qsort' you want to use, you can create
    > 'qsort_ext' by simply adding the external parameter to the comparison
    > function pointer call.


    Many C libraries already have such a thing. GNU libc has qsort_r and
    Microsoft champions qsort_s -- to the extent that it's in C11. The BSD
    C library also has qsort_r but with a different argument order (for both
    qsort_r and the comparison function). I'll bet there are others.

    A mess of #ifdefs can probably render such code reasonably portable, but
    maybe the OP wants the code to work in only one of these environments.

    --
    Ben.
     
    Ben Bacarisse, Oct 22, 2012
    #7
  8. none

    tom st denis Guest

    On Oct 22, 2:59 pm, Eric Sosman <>
    wrote:
    > On 10/22/2012 2:41 PM, Eric Sosman wrote:
    >
    > > On 10/22/2012 1:51 PM, none Rouben Rostamian wrote:
    > >> How does one apply qsort() if the comparison criterion
    > >> depends on a parameter?

    >
    >      A further observation: Don't go overboard in parameterizing
    > your comparators.  A comparator may be called a large number of
    > times during a sort, so it's "in the inner loop" and should be
    > kept short and swift.  A comparator that examines parameters
    > P1,P2,P3,... in addition to the items it's comparing starts to
    > stray from the "short and swift" ideal.
    >
    >      A particular abuse that always seems to crop up is trying
    > to use one comparator to sort on multiple keys:
    >
    >         struct s {
    >             int k1;
    >             char *k2;
    >             double k3;
    >         };
    >
    >         int which_key;
    >
    >         int compare(const void *aa, const void *bb) {
    >             const struct s *a = aa;
    >             const struct s *b = bb;
    >             switch (which_key) {
    >             case 1:
    >                 return (a->k1 > b->k1) - (a->k1 < b->k1);
    >             case 2:
    >                 return strcmp(a->k2, b->k2);
    >             case 3:
    >                 return (a->k3 > b->k3) - (a->k3 < b->k3);
    >             default:
    >                 assert(false);
    >             }
    >         }
    >
    >         ...
    >         which_key = 2;
    >         qsort(array, count, sizeof array[0], compare);
    >
    >      This setup repeats the switch decision -- which is "just
    > overhead" -- for every comparison, and there may be a lot of
    > them.  It would almost surely be better to have three short
    > comparators than one omnibus comparator.


    But that code is not thread safe and it's not really any simpler than
    just calling qsort with a variable as the compare callback that is
    determined locally on the stack.

    Tom
     
    tom st denis, Oct 22, 2012
    #8
  9. none

    Eric Sosman Guest

    On 10/22/2012 4:25 PM, tom st denis wrote:
    > On Oct 22, 2:59 pm, Eric Sosman <>
    > wrote:
    >>[...]
    >> This setup repeats the switch decision -- which is "just
    >> overhead" -- for every comparison, and there may be a lot of
    >> them. It would almost surely be better to have three short
    >> comparators than one omnibus comparator.

    >
    > But that code is not thread safe and it's not really any simpler than
    > just calling qsort with a variable as the compare callback that is
    > determined locally on the stack.


    Since qsort() itself need not be thread-safe (it need not
    even be re-entrant within just one thread), the thread-safety
    of a comparator scarcely matters. A thread-safe comparator
    could be called by qsort() in one thread while another called
    it via bsearch(), but that's a bit of a stretch.

    My personal parser recognizes all the words in your second
    and third lines, but is unable to make sense of them.

    In any event, the code I showed was an illustration of
    what I consider an inferior pattern; the suggested alternative
    could in fact be thread-safe.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 22, 2012
    #9
  10. none

    Öö Tiib Guest

    On Monday, 22 October 2012 20:51:55 UTC+3, none wrote:
    > How does one apply qsort() if the comparison criterion
    > depends on a parameter?


    Others have already replied that most platforms offer qsort variants
    with additional parameter.

    Also think over why you need to sort with dynamic criteria.
    Maybe you only need to find few items with highest order before
    your criteria changes again?
    On that case building an heap
    http://en.wikipedia.org/wiki/Heap_(data_structure)
    can be more efficient solution.
     
    Öö Tiib, Oct 22, 2012
    #10
  11. none

    none Guest

    In article <k6413q$l7u$>,
    none) (Rouben Rostamian <rouben@shadow.> wrote:
    >How does one apply qsort() if the comparison criterion
    >depends on a parameter?
    >
    >Specifically, suppose I wish to sort an array of int,
    >according to distance from a prescribed value `n':
    >
    >int compar(const void *aa, const void *bb)
    >{
    > int a = *(int *)aa;
    > int b = *(int *)bb;
    > return abs(a - n) < abs(b - n);
    >}
    >
    >One way to make this work, is to declare n as a global
    >(file scope) variable. Is there a clever way to do this
    >without bringing in a global variable?


    Thank you everyone for your suggestions and comments.
    I knew about GNU's qsort_r() with its extra parameter.
    It does exactly what I need. The reason I asked the
    question here is that I was holding out hope that
    there may be a way of doing something similar in
    standard C. From the responses it appears that it is
    not possible.

    Thanks you again.

    --
    Rouben Rostamian
     
    none, Oct 23, 2012
    #11
  12. rouben@shady.(none) (Rouben Rostamian) writes:
    [...]
    > Thank you everyone for your suggestions and comments.
    > I knew about GNU's qsort_r() with its extra parameter.
    > It does exactly what I need. The reason I asked the
    > question here is that I was holding out hope that
    > there may be a way of doing something similar in
    > standard C. From the responses it appears that it is
    > not possible.


    If qsort_r() isn't already written in standard C, I'm sure it could be.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 23, 2012
    #12
  13. none

    James Kuyper Guest

    On 10/23/2012 12:25 AM, Robert Wessel wrote:
    > On Mon, 22 Oct 2012 16:54:25 -0400, Eric Sosman
    > <> wrote:

    ....
    >> Since qsort() itself need not be thread-safe (it need not
    >> even be re-entrant within just one thread), the thread-safety
    >> of a comparator scarcely matters. A thread-safe comparator
    >> could be called by qsort() in one thread while another called
    >> it via bsearch(), but that's a bit of a stretch.

    >
    >
    > How is qsort not thread safe or non-reentrant? With the obvious, and
    > uninteresting, exception of an attempt to simultaneously sort a single
    > array more than once.


    He didn't say that qsort() is not thread-safe, or non-reentrant. He said
    that qsort() is not required to be thread-safe or reentrant. It's
    probably both - there's no obvious reason to make it otherwise - but
    he's correct that it's not required to be either.
    --
    James Kuyper
     
    James Kuyper, Oct 23, 2012
    #13
  14. none

    Eric Sosman Guest

    On 10/23/2012 12:25 AM, Robert Wessel wrote:
    >[...]
    >> Since qsort() itself need not be thread-safe (it need not
    >> even be re-entrant within just one thread), the thread-safety
    >> of a comparator scarcely matters. A thread-safe comparator
    >> could be called by qsort() in one thread while another called
    >> it via bsearch(), but that's a bit of a stretch.

    >
    > How is qsort not thread safe or non-reentrant? With the obvious, and
    > uninteresting, exception of an attempt to simultaneously sort a single
    > array more than once.


    7.1.4p4: "The functions in the standard library are not
    guaranteed to be reentrant and may modify objects with static
    or thread storage duration."

    Even so, it turns out I was wrong, at least in part. The
    quoted language appears in both C99 (except for "or thread") and
    C11, but C11 adds two further paragraphs p6,p7 describing some
    thread-safety constraints on implementations of the library.
    "Upon further review," I now believe

    In C11, qsort() is thread-safe.

    In C99, qsort() is thread-UNsafe (sort of obvious, since
    C99 has no notion of threads).

    In both C99 and C11, qsort() is non-reentrant. Two C11
    threads can use qsort() simultaneously, but it's still
    an error to call qsort() from qsort()'s comparator, or
    to call it from a handler for a signal that might be
    raised during a qsort().

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 23, 2012
    #14
  15. On Tuesday, October 23, 2012 4:52:28 AM UTC+1, none wrote:
    > In article <k6413q$l7u$>,
    >
    > Thank you everyone for your suggestions and comments.
    > I knew about GNU's qsort_r() with its extra parameter.
    > It does exactly what I need. The reason I asked the
    > question here is that I was holding out hope that
    > there may be a way of doing something similar in
    > standard C. From the responses it appears that it is
    > not possible.
    >

    No, it's a design fault with qsort(). Functions that take a fucntion pointer
    should also take an arbitrary void * which they pass back as a parameter.
    But qsort() was very early, before this was realised.
     
    Malcolm McLean, Oct 23, 2012
    #15
  16. none

    tom st denis Guest

    On Oct 22, 4:54 pm, Eric Sosman <>
    wrote:
    > On 10/22/2012 4:25 PM, tom st denis wrote:
    >
    > > On Oct 22, 2:59 pm, Eric Sosman <>
    > > wrote:
    > >>[...]
    > >>       This setup repeats the switch decision -- which is "just
    > >> overhead" -- for every comparison, and there may be a lot of
    > >> them.  It would almost surely be better to have three short
    > >> comparators than one omnibus comparator.

    >
    > > But that code is not thread safe and it's not really any simpler than
    > > just calling qsort with a variable as the compare callback that is
    > > determined locally on the stack.

    >
    >      Since qsort() itself need not be thread-safe (it need not
    > even be re-entrant within just one thread), the thread-safety
    > of a comparator scarcely matters.  A thread-safe comparator
    > could be called by qsort() in one thread while another called
    > it via bsearch(), but that's a bit of a stretch.


    It's generally a bad idea to write thread unsafe code on purpose
    unless you have a reason.

    >      My personal parser recognizes all the words in your second
    > and third lines, but is unable to make sense of them.


    I was saying in the function where you call qsort() you could resolve
    there which key to sort on and then call the appropriate comparator
    function. Instead of having one compare function you'd have n and
    they'd all compare a different key.

    Tom
     
    tom st denis, Oct 23, 2012
    #16
  17. none

    Eric Sosman Guest

    On 10/23/2012 10:05 AM, tom st denis wrote:
    > On Oct 22, 4:54 pm, Eric Sosman <>
    > wrote:
    >> On 10/22/2012 4:25 PM, tom st denis wrote:
    >>
    >>> On Oct 22, 2:59 pm, Eric Sosman <>
    >>> wrote:
    >>>> [...]
    >>>> This setup repeats the switch decision -- which is "just
    >>>> overhead" -- for every comparison, and there may be a lot of
    >>>> them. It would almost surely be better to have three short
    >>>> comparators than one omnibus comparator.

    >>
    >>> But that code is not thread safe and it's not really any simpler than
    >>> just calling qsort with a variable as the compare callback that is
    >>> determined locally on the stack.

    >>
    >> Since qsort() itself need not be thread-safe (it need not
    >> even be re-entrant within just one thread), the thread-safety
    >> of a comparator scarcely matters. A thread-safe comparator
    >> could be called by qsort() in one thread while another called
    >> it via bsearch(), but that's a bit of a stretch.

    >
    > It's generally a bad idea to write thread unsafe code on purpose
    > unless you have a reason.
    >
    >> My personal parser recognizes all the words in your second
    >> and third lines, but is unable to make sense of them.

    >
    > I was saying in the function where you call qsort() you could resolve
    > there which key to sort on and then call the appropriate comparator
    > function. Instead of having one compare function you'd have n and
    > they'd all compare a different key.


    Ah! Okay, we're in violent agreement. That's exactly
    what I meant by suggesting "It would almost surely be better
    to have three short comparators than one omnibus comparator."

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 23, 2012
    #17
  18. none

    Eric Sosman Guest

    On 10/23/2012 10:28 AM, Scott Fluhrer wrote:
    > "Eric Sosman" <> wrote in message
    > news:k6441n$oa7$...
    >> On 10/22/2012 1:51 PM, none Rouben Rostamian wrote:
    >>> How does one apply qsort() if the comparison criterion
    >>> depends on a parameter?
    >>>
    >>> Specifically, suppose I wish to sort an array of int,
    >>> according to distance from a prescribed value `n':
    >>>
    >>> int compar(const void *aa, const void *bb)
    >>> {
    >>> int a = *(int *)aa;
    >>> int b = *(int *)bb;
    >>> return abs(a - n) < abs(b - n);

    >>
    >> Aside: This can't be right, as it doesn't define
    >> a total ordering.
    >>

    >
    > I believe this point could use some expansion. What Eric was refering to
    > was the fact that a qsort implementation expects a comparison function that
    > returns negative if the first element should appear earlier than the second
    > element, positive if the second element should appear earlier, and 0 if you
    > don't care. In particular, if compare(a, b) returns positive, compare(b, a)
    > must return negative.


    Exactly. Also, if compare(a,b) and compare(a,c) both return
    zero, then compare(b,c) must return zero. It's easy to see that
    the function as shown doesn't satisfy this. (Consider n=0 for
    simplicity, then compare(10,1) and compare(10,5) both return zero,
    but compare(1,5) returns one.)

    > If the above isn't true, well, I don't know if there is any requirement on
    > what qsort is allowed to do. The most obvious thing it could do in this
    > case is not sort the array as you expect (for example, given the array [1000
    > 1] and N=0, it may leave the array undisturbed). Other misbehaviors (such
    > as infinite looping, or returning an array which is not a permutation of the
    > original, or simply crashing) are less likely, but are still conceivable.


    As far as I can see, the behavior is undefined. The "shall
    be consistent" requirement is in 7.22.5, which is not part of a
    constraint. 4p2 tells us that violating a non-constraint "shall"
    yields undefined behavior.

    As to outcomes, both crashes and infinite loops seem likely
    possibilities to me. For example, a qsort() using the Quicksort
    algorithm with Sedgewick's median-of-three heuristic may well
    walk off one end or the other of the array if the comparator
    misbehaves and fails to stop it. Even if this doesn't loop or
    crash, it might exchange some array elements with bytes outside
    the array limits.

    That's another reason to keep comparators simple: It's
    easier to verify their correctness.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 23, 2012
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Siegl
    Replies:
    1
    Views:
    968
    Marrow
    Jul 18, 2003
  2. richard

    Re: qsort and structs and ptrs

    richard, Aug 14, 2003, in forum: C Programming
    Replies:
    0
    Views:
    391
    richard
    Aug 14, 2003
  3. richard

    crashing qsort

    richard, Aug 14, 2003, in forum: C Programming
    Replies:
    34
    Views:
    1,350
  4. Debashish Chakravarty

    [possibly OT] the comparison function in qsort

    Debashish Chakravarty, Nov 23, 2003, in forum: C Programming
    Replies:
    0
    Views:
    320
    Debashish Chakravarty
    Nov 23, 2003
  5. Ingo Brueckl
    Replies:
    5
    Views:
    486
    Keith Thompson
    Dec 19, 2003
Loading...

Share This Page