Velocity Reviews > callback function

# callback function

Barry Schwarz
Guest
Posts: n/a

 10-19-2012
On Thu, 18 Oct 2012 20:32:13 -0400, "Bill Cunningham"
<(E-Mail Removed)> wrote:

>Ben Bacarisse wrote:
>> "Bill Cunningham" <(E-Mail Removed)> 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

>
>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.

--
Remove del for email

tom st denis
Guest
Posts: n/a

 10-19-2012
On Oct 17, 5:36*pm, John Gordon <(E-Mail Removed)> wrote:
> > 2. second line of sort_int. num is not a built in type so it doesn't require
> > parenthesis does it?

>
> 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
Guest
Posts: n/a

 10-19-2012
On 10/19/2012 07:44 AM, tom st denis wrote:
> On Oct 17, 5:36�pm, John Gordon <(E-Mail Removed)> wrote:
>>> 2. second line of sort_int. num is not a built in type so it doesn't require
>>> parenthesis does it?

>>
>> 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.

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)

--
James Kuyper

Bill Cunningham
Guest
Posts: n/a

 10-19-2012
Kenneth Brody wrote:
> On 10/19/2012 1:30 AM, Barry Schwarz wrote:
>> On Thu, 18 Oct 2012 20:32:13 -0400, "Bill Cunningham"
>> <(E-Mail Removed)> wrote:
>>
>>> Ben Bacarisse wrote:
>>>> "Bill Cunningham" <(E-Mail Removed)> 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;

> [...]
>> 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
Guest
Posts: n/a

 10-19-2012
Ben Bacarisse wrote:

> 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
Guest
Posts: n/a

 10-19-2012
pete wrote:
> Ian Collins wrote:
>>
>> On 10/18/12 10:36, John Gordon wrote:

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

>>
>> Except, as in this case, where its argument is a type.
>>
>> See what happens when you get sucked into a Bill troll?

>
> 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
Guest
Posts: n/a

 10-19-2012
pete wrote:
> Ian Collins wrote:
>>
>> On 10/18/12 10:36, John Gordon wrote:

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

>>
>> Except, as in this case, where its argument is a type.
>>
>> See what happens when you get sucked into a Bill troll?

>
> 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
Guest
Posts: n/a

 10-19-2012
"Bill Cunningham" <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:
>
>> 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.

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

--
Ben.

Barry Schwarz
Guest
Posts: n/a

 10-19-2012
On Fri, 19 Oct 2012 17:04:01 -0400, "Bill Cunningham"
<(E-Mail Removed)> wrote:

>pete wrote:
>> Ian Collins wrote:
>>>
>>> On 10/18/12 10:36, John Gordon wrote:

>>
>>>> Sizeof is a keyword, not a function call.
>>>> It never needs parentheses.
>>>
>>> Except, as in this case, where its argument is a type.
>>>
>>> See what happens when you get sucked into a Bill troll?

>>
>> 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.

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

--
Remove del for email

Bill Cunningham
Guest
Posts: n/a

 10-19-2012
Barry Schwarz wrote:
> On Fri, 19 Oct 2012 17:04:01 -0400, "Bill Cunningham"
> <(E-Mail Removed)> wrote:
>
>> pete wrote:
>>> Ian Collins wrote:
>>>>
>>>> On 10/18/12 10:36, John Gordon wrote:
>>>
>>>>> Sizeof is a keyword, not a function call.
>>>>> It never needs parentheses.
>>>>
>>>> Except, as in this case, where its argument is a type.
>>>>
>>>> See what happens when you get sucked into a Bill troll?
>>>
>>> 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.

>
> 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