callback function

[Bill Cunningham]

Why do some people post untested code? I didn't know it was against
the rules. I've seen it alot. It's tested now and works perfectly.

Also untested code illustrated my point and answered my question
perfectly. I'm just in the *out* group.

Bill

 

[Bill Cunningham]

Whoops, I was mistaken. If you're getting the size of a variable you
don't need parentheses. But if you're getting the size of a type,
you do
need them.

(And it's an operator, not a keyword. Wrong all around!)

That's fine John I appreciate your opinion though yes you where wrong.
No problem. But be forewarned, this *could* be the start that leads you to
the *outgroup* If you start asking questions especially you should know as a
computer programming expert (ingroup) and sticking yourself out there...Be
careful.

Bill

 

[Keith Thompson]

Why do some people post untested code? I didn't know it was against the
rules. I've seen it alot. It's tested now and works perfectly.

Your code wasn't merely untested; you hadn't even compiled it.
It wasn't a violation of some specific rule, it was a violation of
common sense. You didn't bother to spend a minute or so compiling
your code before you posted it here. The code you posted was full
of syntax errors that anyone trying to help you would have to fix
before answering your actual question.

int comp(constvoid *a,const void *b)

Why should I spend time fixing errors like this, not relevant to the
question you're asking, that you could have fixed yourself? How is
anyone supposed to know which errors are just typos, and which are
relevant to the problem you're trying to solve?

 

[Bill Cunningham]

Your code wasn't merely untested; you hadn't even compiled it.
It wasn't a violation of some specific rule, it was a violation of
common sense. You didn't bother to spend a minute or so compiling
your code before you posted it here. The code you posted was full
of syntax errors that anyone trying to help you would have to fix
before answering your actual question.

int comp(constvoid *a,const void *b)

Why should I spend time fixing errors like this, not relevant to the
question you're asking, that you could have fixed yourself? How is
anyone supposed to know which errors are just typos, and which are
relevant to the problem you're trying to solve?

I'll be more careful.

Bill

 

[Bill Cunningham]

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

Then why

return *pa-*pb;

B

 

[Ben Bacarisse]

That's fine John I appreciate your opinion though yes you where
wrong.

Actually he's not "wrong all around" -- sizeof *is* a keyword. It's an
operator, too, but it's also a keyword.

<snip sociology>

 

[Ben Bacarisse]

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.

 

[Bill Cunningham]

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

 

[Ben Bacarisse]

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.

 

[Barry Schwarz]

On Thu, 18 Oct 2012 18:24:37 -0400, "Bill Cunningham"

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.

 

[Barry Schwarz]

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.

Because you are not interested in sorting the pointer values. You
don't care if pa is >, ==, or < pb.

You do want to sort the values the pointers point to. The value pa
points to is *pa. Ditto for *pb. You do care if *pa is >, ++, or <
*pb. Other than the possibility of overflow, *pa-*pb is a convenient
way of determining that relationship and returning the result in a
form qsort can use.

 

[tom st denis]

Sizeof is a keyword, not a function call. It never needs parentheses.

Not true. Consider this:

char a;
int x, y, z;

x = sizeof a;
y = sizeof a * 1UL;
z = sizeof (a * 1UL);

What are the values of x/y/z?

So the only time you should use () is when you want the size of an
expression.



Tom

 

[James Kuyper]

Not true. Consider this:

char a;
int x, y, z;

x = sizeof a;
y = sizeof a * 1UL;
z = sizeof (a * 1UL);

What are the values of x/y/z?

So the only time you should use () is when you want the size of an
expression.

That's only true when the expression in question does not parse as unary
expression. Each of the following expressions is already a unary
expression, and would therefore not need parentheses if passed to sizeof:

a
1UL
"sizeof"
_Generic(a, int:5.0, double:5)
array[1]
printf("output")
mystruct.member
pmystruct->member
a++
a--
(struct tm){.tm_year=112, .tm_month=9, .tm_mday=18}
++a
--a
&a
*array
+a
-a
~a
!a
sizeof a
sizeof(int)
_Alignof(a)

 

[Bill Cunningham]

Ben Bacarisse wrote:

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;

[...]
Because you are not interested in sorting the pointer values. You
don't care if pa is >, ==, or < pb.

You do want to sort the values the pointers point to. The value pa
points to is *pa. Ditto for *pb. You do care if *pa is >, ++, or <
*pb. Other than the possibility of overflow, *pa-*pb is a convenient
way of determining that relationship and returning the result in a
form qsort can use.

Consider this:

You have a bunch of bins, each a different color, full of toys. You
want to sort them by the age group for the toys in each. You don't
compare "green bin" to "blue bin", but rather you need to compare
what's *in* the bins. That's (sort of) the equivalent of
dereferencing a pointer -- you don't compare "pa" and "pb", but
rather what's "in" them.
Yes, it's a lame analogy, but I think it's about the right level of
simplicity for the OP.

That helps Kenneth thanks.

Bill

 

[Bill Cunningham]

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.

If I am understanding you right the connection between these two is what
I want to understand.

Bill

 

[Bill Cunningham]

The catching of the mistakes
in the explanations to Bill Cunningham,
is the real value of a Bill Cunningham thread.

I'm trying to warn John from getting into the *outgroup* ! He may not
Know all about C! Like an Eric Sosman or Ian collins &c.

Bill

 

[Bill Cunningham]

The catching of the mistakes
in the explanations to Bill Cunningham,
is the real value of a Bill Cunningham thread.

People who make mistakes in clc by trying to help and might be flawed are
looked down on in clc. There is no value to one who doesn't know C or makes
mistakes in clc.

B

 

[Ben Bacarisse]

If I am understanding you right the connection between these two is what
I want to understand.

Well, good luck with that. In the mean time, if you happen to think of
an answer to my question, don't hold back!

 

[Barry Schwarz]

People who make mistakes in clc by trying to help and might be flawed are
looked down on in clc. There is no value to one who doesn't know C or makes
mistakes in clc.

Compared to these ravings, your C code is a model of clarity.

 

[Bill Cunningham]

Compared to these ravings, your C code is a model of clarity.

One thing is clear in clc. C expert, computer programmer, nothing to do
but program ->ingroup. Don't know C, ask questions about it, other things to
do than program or *don't understand* there's a biggy ->outgroup. Possibly
to the point of plonk by the ingroup. The ultimate outgrouper.

B