By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,190 Members | 839 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,190 IT Pros & Developers. It's quick & easy.

trying to assign function pointers

P: n/a
Hi I am having some problems assigning function pointers.

this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

any ideas here is the full code below

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

#define MAX 20

int intcmp(const void *v1, const void *v2);
int increasing(const void *v1, const void *v2);
int decreasing(const void *v1, const void *v2);
int (*compar)(const void *v1, const void *v2);
main(int argc, char** argv)
{
int arr[MAX], count, key, *ptr, i, a ,b;

printf("argc = %d\n", argc);

for (i = 0; i < argc; i++)
printf("argv[%d] = \"%s\"\n", i, argv[i]);
int (*compar) () = increasing;

//if (argv[1] == "decreasing")
//int (*compar) () = increasing;
//if (argv[1] == "increasing")
//int (*compar) () = decreasing;

for (count = 0; count < MAX; count++)
scanf("%d", &arr[count]);
qsort(arr, MAX, sizeof(arr[0]), compar);
//qsort(arr, MAX, sizeof(arr[0]), increasing);

for (count = 0; count < MAX; count++)
printf("arr[%d] = %d.\n", count, arr[count]);

}
int intcmp(const void *v1, const void *v2)
{
return (*(int *)v1 - *(int *)v2);
}

int increasing(const void *v1, const void *v2)
{
// printf ("increasing\n");
return (*(int *)v1 - *(int *)v2);
}

int decreasing(const void *v1, const void *v2)
{
// printf ("decreasing\n");
return (*(int *)v2 - *(int *)v1);
}

Jun 9 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
merrittr wrote:
Hi I am having some problems assigning function pointers.

this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
You can't declare compar twice, try

int (*compar)();

if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;

qsort(arr, MAX, sizeof(arr[0]), compar);

--
Ian Collins.
Jun 9 '07 #2

P: n/a
Ian Collins said:
merrittr wrote:
>Hi I am having some problems assigning function pointers.

this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
You can't declare compar twice
Yes, he can, but it won't do him any good.

, try
>
int (*compar)();
Wouldn't he be better off with
int (*compar)(const void *, const void *); ?
>
if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;
Wouldn't he be better off looking up strcmp?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 9 '07 #3

P: n/a
Richard Heathfield wrote:
Ian Collins said:
>merrittr wrote:
>>Hi I am having some problems assigning function pointers.

this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
You can't declare compar twice

Yes, he can, but it won't do him any good.
Not the way he did in the same scope.
, try
>int (*compar)();

Wouldn't he be better off with
int (*compar)(const void *, const void *); ?
He would.
>if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;

Wouldn't he be better off looking up strcmp?
See what happens when one writes C++ all day?

--
Ian Collins.
Jun 9 '07 #4

P: n/a
Ian Collins said:
Richard Heathfield wrote:
>Ian Collins said:
>>merrittr wrote:
Hi I am having some problems assigning function pointers.

this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

You can't declare compar twice

Yes, he can, but it won't do him any good.
Not the way he did
Yes, he can...
in the same scope.
....but not in the same scope. Nit finally picked to both our
satisfactions, I think.

<snip>
>>if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;

Wouldn't he be better off looking up strcmp?
See what happens when one writes C++ all day?
Heretic. I'm suspending your clc posting licence for DBL_MIN seconds.
That'll larn ya.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 9 '07 #5

P: n/a
"Richard Heathfield" <rj*@see.sig.invalidschrieb im Newsbeitrag
news:hd******************************@bt.com...
Ian Collins said:
>Richard Heathfield wrote:
>>Ian Collins said:

merrittr wrote:
Hi I am having some problems assigning function pointers.
>
this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
>
this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
>
You can't declare compar twice

Yes, he can, but it won't do him any good.
Not the way he did

Yes, he can...
>in the same scope.

...but not in the same scope. Nit finally picked to both our
satisfactions, I think.

<snip>
>>>if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;

Wouldn't he be better off looking up strcmp?
See what happens when one writes C++ all day?

Heretic. I'm suspending your clc posting licence for DBL_MIN seconds.
Don't you think this is slightly too short and mild a punishment?

Interesting: I thought DBL_MIN to be in limits.h, but I found it in float.h,
DBL_MAX being in both...

Bye, Jojo
Jun 9 '07 #6

P: n/a
thanks guys that works perfectly


On Jun 9, 5:53 am, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
"Richard Heathfield" <r...@see.sig.invalidschrieb im Newsbeitragnews:hd******************************@b t.com...
Ian Collins said:
Richard Heathfield wrote:
Ian Collins said:
>>merrittr wrote:
Hi I am having some problems assigning function pointers.
>>>this works fine:
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
>>>this doesn't:
if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);
>>You can't declare compar twice
>Yes, he can, but it won't do him any good.
Not the way he did
Yes, he can...
in the same scope.
...but not in the same scope. Nit finally picked to both our
satisfactions, I think.
<snip>
>>if (argv[1] == "decreasing")
compar = decreasing;
if (argv[1] == "increasing")
compar = increasing;
>Wouldn't he be better off looking up strcmp?
See what happens when one writes C++ all day?
Heretic. I'm suspending your clc posting licence for DBL_MIN seconds.

Don't you think this is slightly too short and mild a punishment?

Interesting: I thought DBL_MIN to be in limits.h, but I found it in float.h,
DBL_MAX being in both...

Bye, Jojo

Jun 9 '07 #7

P: n/a
On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:

[snip]
Interesting: I thought DBL_MIN to be in limits.h, but I found it in float.h,
DBL_MAX being in both...
Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jun 10 '07 #8

P: n/a

"Jack Klein" <ja*******@spamcop.netschrieb im Newsbeitrag
news:43********************************@4ax.com...
On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:

[snip]
>Interesting: I thought DBL_MIN to be in limits.h, but I found it in
float.h,
DBL_MAX being in both...

Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.
It does, sort of, with an #ifdef DBL_MAX

Bye, Jojo
Jun 10 '07 #9

P: n/a
Joachim Schmitz wrote, On 10/06/07 20:47:
"Jack Klein" <ja*******@spamcop.netschrieb im Newsbeitrag
news:43********************************@4ax.com...
>On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:

[snip]
>>Interesting: I thought DBL_MIN to be in limits.h, but I found it in
float.h,
DBL_MAX being in both...
Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.
It does, sort of, with an #ifdef DBL_MAX
It it was not defined before including limits.h but it is after then it
does not conform to the standard.
--
Flash Gordon
Jun 10 '07 #10

P: n/a
"Flash Gordon" <sp**@flash-gordon.me.ukschrieb im Newsbeitrag
news:c3************@news.flash-gordon.me.uk...
Joachim Schmitz wrote, On 10/06/07 20:47:
>"Jack Klein" <ja*******@spamcop.netschrieb im Newsbeitrag
news:43********************************@4ax.com.. .
>>On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:

[snip]

Interesting: I thought DBL_MIN to be in limits.h, but I found it in
float.h,
DBL_MAX being in both...
Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.
It does, sort of, with an #ifdef DBL_MAX

It it was not defined before including limits.h but it is after then it
does not conform to the standard.
That's why I said 'sort of'. I just checked again: float.h is doing the same
thing, so it doesn't matter which is included or in what order, si I guess
we're save here...

Bye, Jojo
Jun 11 '07 #11

P: n/a
Joachim Schmitz wrote, On 11/06/07 07:26:
"Flash Gordon" <sp**@flash-gordon.me.ukschrieb im Newsbeitrag
news:c3************@news.flash-gordon.me.uk...
>Joachim Schmitz wrote, On 10/06/07 20:47:
>>"Jack Klein" <ja*******@spamcop.netschrieb im Newsbeitrag
news:43********************************@4ax.com. ..
On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:

[snip]

Interesting: I thought DBL_MIN to be in limits.h, but I found it in
float.h,
DBL_MAX being in both...
Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.
It does, sort of, with an #ifdef DBL_MAX
It it was not defined before including limits.h but it is after then it
does not conform to the standard.
That's why I said 'sort of'. I just checked again: float.h is doing the same
thing, so it doesn't matter which is included or in what order, si I guess
we're save here...
No you are not because if you do not include float.h it is legal for you
to unconditionally define DBL_MAX. I.e. the following is perfectly legal...

#include <limits.h>

#define DBL_MAX "Hello World"

int main(void)
{
puts(DBL_MAX);
return 0;
}

Subject to typos/thinkos, anyway.
--
Flash Gordon
Jun 11 '07 #12

P: n/a
Flash Gordon said:

<snip>
[...] if you do not include float.h it is legal for
you to unconditionally define DBL_MAX. I.e. the following is perfectly
legal...

#include <limits.h>

#define DBL_MAX "Hello World"

int main(void)
{
puts(DBL_MAX);
return 0;
}

Subject to typos/thinkos, anyway.
Such as the typo of omitting <stdio.h- not strictly a problem in C90
for this particular program, but I believe it moves your code outside
the common subset of C90 and C99.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 11 '07 #13

P: n/a
"Flash Gordon" <sp**@flash-gordon.me.ukschrieb im Newsbeitrag
news:41************@news.flash-gordon.me.uk...
Joachim Schmitz wrote, On 11/06/07 07:26:
>"Flash Gordon" <sp**@flash-gordon.me.ukschrieb im Newsbeitrag
news:c3************@news.flash-gordon.me.uk...
>>Joachim Schmitz wrote, On 10/06/07 20:47:
"Jack Klein" <ja*******@spamcop.netschrieb im Newsbeitrag
news:43********************************@4ax.com ...
On Sat, 9 Jun 2007 13:53:44 +0200, "Joachim Schmitz"
<no*********@schmitz-digital.dewrote in comp.lang.c:
>
[snip]
>
>Interesting: I thought DBL_MIN to be in limits.h, but I found it in
>float.h,
>DBL_MAX being in both...
Your implementation's <limits.his broken if it defines DBL_MAX,
unless it includes some mechanism to disable that definition when
compiling in strictly conforming mode.
It does, sort of, with an #ifdef DBL_MAX
It it was not defined before including limits.h but it is after then it
does not conform to the standard.
That's why I said 'sort of'. I just checked again: float.h is doing the
same thing, so it doesn't matter which is included or in what order, si I
guess we're save here...

No you are not because if you do not include float.h it is legal for you
to unconditionally define DBL_MAX. I.e. the following is perfectly
legal...

#include <limits.h>

#define DBL_MAX "Hello World"
Hmm, well, maybe I have to take that up to the compiler vendor then (who at
the same time is my employer...)

Bye, Jojo
Jun 11 '07 #14

P: n/a
Richard Heathfield wrote, On 11/06/07 09:08:
Flash Gordon said:

<snip>
>[...] if you do not include float.h it is legal for
you to unconditionally define DBL_MAX. I.e. the following is perfectly
legal...

#include <limits.h>

#define DBL_MAX "Hello World"

int main(void)
{
puts(DBL_MAX);
return 0;
}

Subject to typos/thinkos, anyway.

Such as the typo of omitting <stdio.h- not strictly a problem in C90
for this particular program, but I believe it moves your code outside
the common subset of C90 and C99.
It was a lackofthinko that would have been caught by the compiler as I
normally use it. At least I did not use a varidac function so it was
valid for C90 and K&R :-)

You are, of course, correct to point out the error.
--
Flash Gordon
Jun 11 '07 #15

P: n/a
On Sat, 09 Jun 2007 23:06:39 +1200, Ian Collins <ia******@hotmail.com>
wrote:
Richard Heathfield wrote:
Ian Collins said:
merrittr wrote:
>if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

You can't declare compar twice
Yes, he can, but it won't do him any good.
Not the way he did in the same scope.
In C99, they're not in the same scope. Each if statement now has its
own (sub)scope, and the two declarations are legal. <joke>Of course,
RH won't consider this relevant.</They are useless, since neither is
available to the attempted use. And as already noted, comparing
strings that way won't work as desired either, and that type is not as
exact (complete) as it could usefully be.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Jul 1 '07 #16

P: n/a
David Thompson wrote:
On Sat, 09 Jun 2007 23:06:39 +1200, Ian Collins <ia******@hotmail.com>
wrote:
>Richard Heathfield wrote:
Ian Collins said:

merrittr wrote:
>>if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

You can't declare compar twice

Yes, he can, but it won't do him any good.
Not the way he did in the same scope.
In C99, they're not in the same scope. Each if statement now has its
own (sub)scope, and the two declarations are legal.
In both C90 and C99, tbe attempted declarations are syntax errors. The if
condition must be followed by a statement. A declaration is not a
statement.
Jul 1 '07 #17

P: n/a
Harald van D?k said:
David Thompson wrote:
>On Sat, 09 Jun 2007 23:06:39 +1200, Ian Collins
<ia******@hotmail.comwrote:
>>Richard Heathfield wrote:
Ian Collins said:

merrittr wrote:
>>>if (argv[1] == "decreasing")
int (*compar) () = decreasing;
if (argv[1] == "increasing")
int (*compar) () = increasing;
qsort(arr, MAX, sizeof(arr[0]), compar);

You can't declare compar twice

Yes, he can, but it won't do him any good.

Not the way he did in the same scope.
In C99, they're not in the same scope. Each if statement now has its
own (sub)scope, and the two declarations are legal.

In both C90 and C99, tbe attempted declarations are syntax errors. The
if condition must be followed by a statement. A declaration is not a
statement.
See, this is why David Thompson is so useful. He notices things like
this. My reply was incorrect: I am so used to braces around the 'body'
of an if (because I always use them) that it seems I can see them even
when they're not there.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 1 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.