Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #27276 > unrolled thread

callback function

Back to article view | Back to comp.lang.c

Contents

  callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-17 17:16 -0400
    Re: callback function John Gordon <gordon@panix.com> - 2012-10-17 21:36 +0000
      Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-17 17:44 -0400
        Re: callback function John Gordon <gordon@panix.com> - 2012-10-17 21:51 +0000
          Re: callback function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-18 00:11 +0100
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:37 -0400
            Re: callback function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-19 01:16 +0100
            Re: callback function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:48 -0700
      Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-18 10:45 +1300
        Re: callback function pete <pfiland@mindspring.com> - 2012-10-19 14:49 -0400
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 16:59 -0400
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 17:04 -0400
            Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-19 14:14 -0700
              Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 17:31 -0400
                Re: callback function Keith Thompson <kst-u@mib.org> - 2012-10-19 14:54 -0700
                  Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 18:42 -0400
      Re: callback function James Kuyper <jameskuyper@verizon.net> - 2012-10-17 17:47 -0400
      Re: callback function tom st denis <tom@iahu.ca> - 2012-10-19 04:44 -0700
        Re: callback function James Kuyper <jameskuyper@verizon.net> - 2012-10-19 08:24 -0400
    Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-17 14:39 -0700
      Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-17 17:50 -0400
        Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-18 11:00 +1300
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:20 -0400
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:24 -0400
            Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-18 22:30 -0700
            Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-20 11:58 +1300
              Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 19:27 -0400
                Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 19:43 -0400
                  Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-19 21:09 -0700
            Re: callback function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:53 -0700
        Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-17 19:25 -0400
          Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-18 13:34 +1300
            Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-17 20:41 -0400
              Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-18 14:37 +1300
                Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:17 -0400
                  Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-20 11:54 +1300
                Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:54 -0400
                  Re: callback function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-19 01:23 +0100
                    Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 20:32 -0400
                      Re: callback function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-19 02:43 +0100
                        Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 16:56 -0400
                          Re: callback function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-19 22:10 +0100
                      Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-18 22:30 -0700
                        Re: callback function Kenneth Brody <kenbrody@spamcop.net> - 2012-10-19 12:37 -0400
                          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 16:52 -0400
      Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-19 18:44 -0400
        Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-19 21:09 -0700
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-20 15:01 -0400
            Re: callback function Keith Thompson <kst-u@mib.org> - 2012-10-20 12:47 -0700
            Re: callback function Les Cargill <lcargill99@comcast.com> - 2012-10-20 14:51 -0500
            Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-20 14:39 -0700
              Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-20 19:06 -0400
                Re: callback function Barry Schwarz <schwarzb@dqel.com> - 2012-10-20 22:22 -0700
                  Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-21 14:35 -0400
                  Re: callback function Kenneth Brody <kenbrody@spamcop.net> - 2012-10-22 10:58 -0400
                Re: callback function Bill Cunningham <billcun@suddenlink.net> - 2012-10-24 17:28 -0700
            Re: callback function Ian Collins <ian-news@hotmail.com> - 2012-10-21 11:32 +1300
              Re: callback function Keith Thompson <kst-u@mib.org> - 2012-10-20 15:51 -0700
        Re: callback function Robert Miles <milesrf@Usenet-News.net> - 2012-11-25 22:39 -0600
    Re: callback function Keith Thompson <kst-u@mib.org> - 2012-10-17 17:51 -0700
      Re: callback function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-10-18 20:34 +0300
      Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:15 -0400
        Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:27 -0400
        Re: callback function Keith Thompson <kst-u@mib.org> - 2012-10-18 15:47 -0700
          Re: callback function "Bill Cunningham" <billcun@suddenlink.net> - 2012-10-18 18:52 -0400
        Re: callback function blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2012-10-25 10:01 +0000
          Re: callback function Kenneth Brody <kenbrody@spamcop.net> - 2012-10-25 12:44 -0400
            Re: callback function blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2012-10-26 12:48 +0000
    Re: callback function Robert Miles <milesrf@Usenet-News.net> - 2012-11-25 22:13 -0600
      Re: callback function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-26 03:42 -0800
      Re: callback function James Kuyper <jameskuyper@verizon.net> - 2012-11-26 06:59 -0500
      Re: callback function Keith Thompson <kst-u@mib.org> - 2012-11-26 23:03 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#27283

Barry Schwarz wrote:
> On Wed, 17 Oct 2012 17:16:51 -0400, "Bill Cunningham"
> <billcun@suddenlink.net> wrote:
>
>>    I have these 3 functions and before I compile I am going to ask
>> about them. This is for qsort. I tried to tackle this once and
>> couldn't get it I think I get it now. I don't like const's. They are
>> a nuisance. You can't directly pass string literals to them you want
>> to change. Maybe that's just the way C is though.
>
> Since changing a string literal is prohibited, you are doomed before
> you start.
>
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int comp(constvoid *a,const void *b)
>
> Wouldn't using cut and paste be easier than retyping?  It would also
> eliminate silly errors like parameter 1 as well as provide some clue
> that this is your actual code.
>
>> {
>>     int *ia=(constint *)a;
>
> Doesn't this generate a diagnostic?  Either you make ia const or you
> cast away the const from a.
>
>>     int *ib=(const int *)b;
>>     return *ia-*ib;

Ok like int *ia=(int *)b;    ?

> Are you sure this never overflows?

    Like I said at the beginning of my post. This is untested code.

>> }
>>
>> void print_int_array(int *array,size_t len)
>> {
>>    size_t i;
>>    for (i=0;i<len;i++)
>
> Did you run out of horizontal white space or do you just enjoy
> cramming your text together to make it harder to read?
>
>>    printf("%d | ",array[i]);
>
> Still having problems with indenting?
>
>>    putchar('\n');
>> }
>>
>> void sort_int(void)
>> {
>>    int num={1,3,6,4,5};
>
> Did you mean for num to be an array?
>
>>    size_t num_len=sizeof num/sizeof (int);
>> }
>>
>> 1 because of qsorts comp callback function parameters include a
>> const do I need them and can I remove them as I have in the callback?
>
> You didn't remove any const in comp().  Maybe you meant to but are
> just posting code of the top of your head.
>
>> 2. second line of sort_int. num is not a built in type so it doesn't
>> require parenthesis does it?
>
> What????  num is an object of type int which certainly is built-in. Of
> course, you meant for it to be an array of int which is a built-in
> aggregate.  But then it would require brackets.

Yes I forgot the []. Ok I will rewrite.

Bill

[toc] | [prev] | [next] | [standalone]

#27285

On 10/18/12 10:50, Bill Cunningham wrote:
>
>      Like I said at the beginning of my post. This is untested code.

Why post untested code?  Test it, than ask for help.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27319

Ian Collins wrote:
> On 10/18/12 10:50, Bill Cunningham wrote:
>>
>>      Like I said at the beginning of my post. This is untested code.
>
> Why post untested code?  Test it, than ask for help.

    I've often wondered why post untested code too that has been posted by 
those in the *in* group. They do it I didn't know it was against the rules. 
Atleast for some.

Bill

[toc] | [prev] | [next] | [standalone]

#27320

Ian Collins wrote:
> On 10/18/12 10:50, Bill Cunningham wrote:
>>
>>      Like I said at the beginning of my post. This is untested code.
>
> Why post untested code?  Test it, than ask for help.

Besides I thought untested code was enough in answering my questions. I 
planned on testing it and have.

    And let me ask you as a programmer Ian and being in the *in* group an 
*outgroup*er question. What exactly do callback pointer functions help with. 
I know this should come from the womb but just and honest question.

Bill

[toc] | [prev] | [next] | [standalone]

#27334

On Thu, 18 Oct 2012 18:24:37 -0400, "Bill Cunningham"
<billcun@suddenlink.net> wrote:

snip

>    And let me ask you as a programmer Ian and being in the *in* group an 
>*outgroup*er question. What exactly do callback pointer functions help with. 
>I know this should come from the womb but just and honest question.

There are callback functions and function pointers but what do you
think a callback pointer function is?

Consider the common case of qsort.  It contains a sorting algorithm
which at some point needs to know what the relationship between to
array elements is.  Unfortunately, it doesn't know what the type of
the array elements is and therefore cannot compare them internally.
You provide a compare function which qsort can "callback" to determine
the relationship.  The function then returns the status of that
relationship to qsort which makes the appropriate processing decision
based on that status.

In general, callback functions provide a way for a user to tailor a
generic process by providing information specific to the current
application.

In this way the same qsort library function can be used once to sort
an array of pointer to double based on the value of the double and
again to sort an array of struct based on a character array in that
struct.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#27396

On 10/19/12 11:24, Bill Cunningham wrote:
> Ian Collins wrote:
>> On 10/18/12 10:50, Bill Cunningham wrote:
>>>
>>>       Like I said at the beginning of my post. This is untested code.
>>
>> Why post untested code?  Test it, than ask for help.
>
> Besides I thought untested code was enough in answering my questions. I
> planned on testing it and have.
>
>      And let me ask you as a programmer Ian and being in the *in* group an
> *outgroup*er question.

What on earth is the in group?  Did I pay a fee, compete a right of 
passage or accept a nomination?

> What exactly do callback pointer functions help with.

What exactly is a "callback pointer function"?

> I know this should come from the womb but just and honest question.

You have already demonstrated a use for function pointers in your example.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27398

Ian Collins wrote:

> What on earth is the in group?  Did I pay a fee, compete a right of
> passage or accept a nomination?

    Those who run clc. Top C programmers who know C well enough to decide 
whose worthy to learn. Never ask a question but answer those want to learn, 
if found worthy and decide who is or isn't plonked and put into the 
outgroup.

question: "How does a linked list work in C ?"

asked by a and b. (newbies to comp science)

ingrouper a explains to newbie a a linked list.
ingrouper a tells newbie b to piss off.
ingrouper a tells ingrouper b to plonk newbie b and does
so himself.
ingrouper b says "why plonk"
ingrouper a says "I said so".

See the hierarchy in ingrouper a and b? b listens to a .

[toc] | [prev] | [next] | [standalone]

#27399

Bill Cunningham wrote:

>    Those who run clc. Top C programmers who know C well enough to
> decide whose worthy to learn. Never ask a question but answer those
> want to learn, if found worthy and decide who is or isn't plonked and
> put into the outgroup.
>
> question: "How does a linked list work in C ?"
>
> asked by a and b. (newbies to comp science)
>
> ingrouper a explains to newbie a a linked list.
> ingrouper a tells newbie b to piss off.
> ingrouper a tells ingrouper b to plonk newbie b and does
> so himself.
> ingrouper b says "why plonk"
> ingrouper a says "I said so".
>
> See the hierarchy in ingrouper a and b? b listens to a .

    Now an outgrouper such as myself may not necessarily be in "everyones" 
killfile but if your in a killfile you in the outgroup. I'm not a newbie 
either. A troll or even suspected troll has the honor of the outgroup title 
also. Or someone simply who "asks the wrong questions".

[toc] | [prev] | [next] | [standalone]

#27403

On Fri, 19 Oct 2012 19:43:21 -0400, "Bill Cunningham"
<billcun@suddenlink.net> wrote:

>Bill Cunningham wrote:
>
>>    Those who run clc. Top C programmers who know C well enough to
>> decide whose worthy to learn. Never ask a question but answer those

It's bad enough that you can't be bothered to post valid C code but at
least try to get the English right: "who's", not "whose".
 
>> want to learn, if found worthy and decide who is or isn't plonked and
>> put into the outgroup.
>>
>> question: "How does a linked list work in C ?"
>>
>> asked by a and b. (newbies to comp science)
>>
>> ingrouper a explains to newbie a a linked list.
>> ingrouper a tells newbie b to piss off.
>> ingrouper a tells ingrouper b to plonk newbie b and does
>> so himself.
>> ingrouper b says "why plonk"
>> ingrouper a says "I said so".
>>
>> See the hierarchy in ingrouper a and b? b listens to a .
>
>    Now an outgrouper such as myself may not necessarily be in "everyones" 
>killfile but if your in a killfile you in the outgroup. I'm not a newbie 
>either. A troll or even suspected troll has the honor of the outgroup title 
>also. Or someone simply who "asks the wrong questions".

Posting stupid messages about why you are in the out group is a
self-fulfilling prophecy.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#27416

On Oct 18, 11:24 pm, "Bill Cunningham" <bill...@suddenlink.net> wrote:
> Ian Collins wrote:
> > On 10/18/12 10:50, Bill Cunningham wrote:
>
> >>      Like I said at the beginning of my post. This is untested code.
>
> > Why post untested code?  Test it, than ask for help.
>
> Besides I thought untested code was enough in answering my questions. I
> planned on testing it and have.
>
>     And let me ask you as a programmer Ian and being in the *in* group an
> *outgroup*er question.

could you stop this in/out group nonsense?

> What exactly do callback pointer functions help with.
> I know this should come from the womb but just and honest question.

how would you implement qsort without using function pointers? How is
qsort to do a comparison of an arbitary type?

[toc] | [prev] | [next] | [standalone]

#27291

Bill Cunningham wrote:

> Yes I forgot the []. Ok I will rewrite.

Now this seems to work.

#include <stdio.h>
#include <stdlib.h>

int comp(const void *a, const void *b)
{
    int *pa = (int *) a;
    int *pb = (int *) b;
    return *pa - *pb;
}

void print_int_array(int *array, size_t len)
{
    size_t i = 0;
    for (; i < len; i++)
        printf("%d | ", array[i]);
    putchar('\n');
}

int main(void)
{
    int num[] = { 3, 4, 1, 2, 5 };
    size_t num_len = sizeof(num) / sizeof(int);
    qsort(num, num_len, sizeof(int), comp);
    print_int_array(num, num_len);
}

And it's perfectly indented just for you Barry.

Bill

[toc] | [prev] | [next] | [standalone]

#27292

On 10/18/12 12:25, Bill Cunningham wrote:
> Bill Cunningham wrote:
>
>> Yes I forgot the []. Ok I will rewrite.
>
> Now this seems to work.
>
> #include<stdio.h>
> #include<stdlib.h>
>
> int comp(const void *a, const void *b)
> {
>      int *pa = (int *) a;
>      int *pb = (int *) b;
>      return *pa - *pb;
> }

Why do you keep those silly casts?  Just write

     const int *pa = a;
     const int *pb = b;

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27293

Ian Collins wrote:
> On 10/18/12 12:25, Bill Cunningham wrote:
>> Bill Cunningham wrote:
>>
>>> Yes I forgot the []. Ok I will rewrite.
>>
>> Now this seems to work.
>>
>> #include<stdio.h>
>> #include<stdlib.h>
>>
>> int comp(const void *a, const void *b)
>> {
>>      int *pa = (int *) a;
>>      int *pb = (int *) b;
>>      return *pa - *pb;
>> }
>
> Why do you keep those silly casts?  Just write
>
>     const int *pa = a;
>     const int *pb = b;

I'm more interested in why the dereferences. If I'm dereferencing pa and pb 
then I must be using or change the object they're pointing to which must be 
the generic void *a and void *b.

[toc] | [prev] | [next] | [standalone]

#27296

On 10/18/12 13:41, Bill Cunningham wrote:
> Ian Collins wrote:
>> On 10/18/12 12:25, Bill Cunningham wrote:
>>> Bill Cunningham wrote:
>>>
>>>> Yes I forgot the []. Ok I will rewrite.
>>>
>>> Now this seems to work.
>>>
>>> #include<stdio.h>
>>> #include<stdlib.h>
>>>
>>> int comp(const void *a, const void *b)
>>> {
>>>       int *pa = (int *) a;
>>>       int *pb = (int *) b;
>>>       return *pa - *pb;
>>> }
>>
>> Why do you keep those silly casts?  Just write
>>
>>      const int *pa = a;
>>      const int *pb = b;
>
> I'm more interested in why the dereferences. If I'm dereferencing pa and pb
> then I must be using or change the object they're pointing to which must be
> the generic void *a and void *b.

The whole point of the parameters being const qualified is you can't 
change values pointed to.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27318

Ian Collins wrote:

> The whole point of the parameters being const qualified is you can't
> change values pointed to.

    Yes I understand. I am just expressing the opinion like those in the 
*in* group that you can just not change it. I think it's a waste to the 
standard personally. FWIW.

Bill

[toc] | [prev] | [next] | [standalone]

#27395

On 10/19/12 11:17, Bill Cunningham wrote:
> Ian Collins wrote:
>
>> The whole point of the parameters being const qualified is you can't
>> change values pointed to.
>
>      Yes I understand. I am just expressing the opinion like those in the
> *in* group that you can just not change it. I think it's a waste to the
> standard personally. FWIW.

What is a waste, const?  It certainly is not.  Just consider the case 
where the data pointed to is in read only memory.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27326

Ian Collins wrote:

> The whole point of the parameters being const qualified is you can't
> change values pointed to.

    Then why

return *pa-*pb;

B

[toc] | [prev] | [next] | [standalone]

#27328

"Bill Cunningham" <billcun@suddenlink.net> writes:

> Ian Collins wrote:
>
>> The whole point of the parameters being const qualified is you can't
>> change values pointed to.
>
>     Then why
>
> return *pa-*pb;

What's the connection with whether or not the pointers are to const-
qualified types or not?  I can't see any connection between Ian's remark
and your reply.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27329

Ben Bacarisse wrote:
> "Bill Cunningham" <billcun@suddenlink.net> writes:
>
>> Ian Collins wrote:
>>
>>> The whole point of the parameters being const qualified is you can't
>>> change values pointed to.
>>
>>     Then why
>>
>> return *pa-*pb;
>
> What's the connection with whether or not the pointers are to const-
> qualified types or not?  I can't see any connection between Ian's
> remark and your reply.

There's been some kind of posting mixup here. I asked about dereferencing in 
an earlier post and changing the object pointed to. He said that is why 
const was used. I am asking then why these dereferences.

HTH
B

[toc] | [prev] | [next] | [standalone]

#27331

"Bill Cunningham" <billcun@suddenlink.net> writes:

> Ben Bacarisse wrote:
>> "Bill Cunningham" <billcun@suddenlink.net> writes:
>>
>>> Ian Collins wrote:
>>>
>>>> The whole point of the parameters being const qualified is you can't
>>>> change values pointed to.
>>>
>>>     Then why
>>>
>>> return *pa-*pb;
>>
>> What's the connection with whether or not the pointers are to const-
>> qualified types or not?  I can't see any connection between Ian's
>> remark and your reply.
>
> There's been some kind of posting mixup here. I asked about dereferencing in 
> an earlier post and changing the object pointed to. He said that is why 
> const was used. I am asking then why these dereferences.

And I am asking why you use the word "then".  You seem to think there is
a connection between the issues of changing objects and pointers to
const types and these two dereferences.  I'm just curious to know what
you think the connection is.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web