Deferencing void pointer

[Mark McIntyre]

This is an entirely different issue.

Not really, You attempted to show that English usage should govern how
C is written. Chuck showed why thats a false idea.

Your example is traditional mathematical notation.

so is if (x ==0) . Your point seems null.

If this was a feature of C, I /would/ use

t'would be nice wouldn't it?

A more relevant subsection of your example would be

if (0 <= x)

which, to me, is unreadable.

Its not uncommon to see this sort of expression in maths.

 

[Alex]

On 21 Nov 2003 20:20:29 GMT, in comp.lang.c , Alex

Not really, You attempted to show that English usage should govern how
C is written. Chuck showed why thats a false idea.

To /me/, (x==0) is more natural than (0==x), while being
just as efficient of a construct. In the case of a range
expression, there is no efficient and natural way to
express:

if(x is between 0 and 3, inclusive)

This is the idea behind the simplification of such
expressions in C

if(x >= 0 && x <= 3)

....however, the simplification and repetition of the
variable, does not appeal to /me/.

This is a style issue and is, as such, moot. I was not
attempting to generalize my preference to other constructs,
other than the one presented. It is my preference to use
natural language constructs when they are as convenient to
use as their evil twins. /I/ find that this contributes
to readability.

so is if (x ==0) . Your point seems null.

Erm, unless you meant (0==x), this is in fact what I
was arguing.

Its not uncommon to see this sort of expression in maths.

My math vocabulary is somewhat limited. However, I am
yet to see an expression of this sort, with a good reason.

Alex

 

[Dan Pop]

Why restrict yourself to techniques that a compiler cannot or doesn't have
to catch? It seems a very silly restriction.

It's a *very* practical one, too. You (subconciously, in my case)
concentrate your mental resources on the things the compiler cannot help
with.

Logically, a==b and b==a are equivalent. (Duh.)

When was the last time you said "compare 0 to x" in plain English?
As a C beginner, how many times have you written "0 == x"?

You seem to see brain engagement as a Boolean phenomenon. I don't believe
it's as simple as that; people /do/ make mistakes even when their brains
/are/ engaged.

Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.

Dan

 

[Richard Heathfield]

When was the last time you said "compare 0 to x" in plain English?

Never. But we're not discussing English here. We're discussing C. When I see
either 0==x or x==0, I don't think of it as "compare 0 to x" or "compare x
to 0" but rather, "compare these two quantities for equality". It makes no
difference whatsoever which way around you put them.

As a C beginner, how many times have you written "0 == x"?

Many times.

Entirely agreed. It's just that *certain* classes of mistakes can be
trivially avoided if the brain is fully engaged and I claim that the =
vs == mistakes are one such class.

I accept that you claim that. I happen to disagree.

 

[Dan Pop]

Never. But we're not discussing English here. We're discussing C.

Nope, we're discussing the way people think. From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise. But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.

Many times.

How many years have you been a beginner?

I accept that you claim that. I happen to disagree.

Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.

Dan

 

[xarax]

In <[email protected]> Richard Heathfield

Nope, we're discussing the way people think. From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise. But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.


How many years have you been a beginner?


Which means that you can't tell for sure which operator is which when
writing C code. If you could, it would be impossible to use the wrong
operator when performing an equality test. The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.

That line of reasoning is equivalent to saying, "Don't use a debugger. You
should be able to desk-check your code to determine that it will work without
using a debugger to test it."

I actually had a manager say that.

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


Nope, we're discussing the way people think.

No, we're discussing C. Psychology is down the hall.

From the C's point of view
it doesn't make any difference how you write it and nobody claimed
otherwise.

Quite so.

But C code is not written for the exclusive perusal of the
C compilers. And when people read the code, *many* things that don't
make any difference to the compiler become (more or less) important.

True enough, and I accept that there is a minor readability hit on
const==var for /some/ people, but I consider the benefit (of avoiding a
subtle error) to outweigh the cost. Obviously, you disagree.

How many years have you been a beginner?

Just over 14 years. How about you?

Which means that you can't tell for sure which operator is which when
writing C code.

As a matter of fact, I can. Sometimes my fingers and/or keyboard can't,
though.

If you could, it would be impossible to use the wrong
operator when performing an equality test.

Wrong. It's not impossible at all.

The usual excuse for this
mistake is not paying enough attention, which can be entirely avoided by
engaging the brain.

The brain is often too busy to notice minor typos. Why not help the compiler
to pick up as many as it can? It seems perfectly logical to me.

 

[Dan Pop]

That line of reasoning is equivalent to saying, "Don't use a debugger. You
should be able to desk-check your code to determine that it will work without
using a debugger to test it."

Bullshit! Locally checking the correctness of an operator in the context
of the code you're just writing is not the same thing as globally
checking the correctness of a program. The human mind has its
limitations.

BTW, I don't need a debugger to test the correctness of a program.
There are much better and more efficient ways of doing it.

I actually had a manager say that.

Either he was an idiot or you're quoting him out of context.

Dan

 

[xarax]

In <[email protected]> "xarax"

Bullshit! Locally checking the correctness of an operator in the context
of the code you're just writing is not the same thing as globally
checking the correctness of a program. The human mind has its
limitations.

BTW, I don't need a debugger to test the correctness of a program.
There are much better and more efficient ways of doing it.


Either he was an idiot or you're quoting him out of context.

He was the former.

 

[CBFalconer]

.... snip ...

Bullshit! Locally checking the correctness of an operator in the
context of the code you're just writing is not the same thing as
globally checking the correctness of a program. The human mind has
its limitations.

Counter example:

if (p = malloc(N * sizeof *p)) {
/* carry on with gay abandon */
}
else {
/* cleanup */
exit(EXIT_FAILURE);
}

is perfectly legitimate code, although some may disapprove. We
can also flip it to something slightly more readable with:

if (NULL == (p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILURE);
}
else {
/* carry on with gay abandon */
}

or we could use (my preference):

if (!(p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILURE);
}
else {
/* carry on with gay abandon */
}

and I am sure you can come up with further variations.

The point is that I have flipped operators about with some
abandon, but all the fragments are correct code. So, to requote,
"Locally checking the correctness of an operator in the
context of the code you're just writing" has very little to do
with it.

 

[Dan Pop]

Counter example:

if (p = malloc(N * sizeof *p)) {
/* carry on with gay abandon */
}
else {
/* cleanup */
exit(EXIT_FAILURE);
}

is perfectly legitimate code, although some may disapprove. We
can also flip it to something slightly more readable with:

if (NULL == (p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILURE);
}
else {
/* carry on with gay abandon */
}

or we could use (my preference):

if (!(p = malloc(N * sizeof *p))) {
/* cleanup */
exit(EXIT_FAILURE);
}
else {
/* carry on with gay abandon */
}

and I am sure you can come up with further variations.

The point is that I have flipped operators about with some
abandon, but all the fragments are correct code. So, to requote,
"Locally checking the correctness of an operator in the
context of the code you're just writing" has very little to do
with it.

Are you sure you have engaged your brain before posting this reply?
How is this stuff a counterexample of anything I have said?

Dan

 

[Dan Pop]

No, we're discussing C. Psychology is down the hall.


Quite so.

If, we're discussing C, and from the C point of view the order doesn't
matter, then why do you insist that *for you* one order is better than
the other? It seems to me that we're discussing more than just C, here.

True enough, and I accept that there is a minor readability hit on
const==var for /some/ people, but I consider the benefit (of avoiding a
subtle error) to outweigh the cost. Obviously, you disagree.

Obviously, since the "subtle" error can be *trivially* avoided at NO
readability hit for anybody.

Just over 14 years. How about you?

There is no point in playing idiotic semantic games with me. If you truly
consider yourself a beginner, making a major contribution to a C book was
dishonest. Did you introduce yourself as a C beginner at the beginning of
the book in question, to warn your readers?

As a matter of fact, I can. Sometimes my fingers and/or keyboard can't,
though.

I was not aware that you were typing your code with your eyes closed.
What do you think I meant by "triple checking"?

Wrong. It's not impossible at all.

It is, after the triple checking.

The brain is often too busy to notice minor typos.

While typing code, it should be busy checking its correctness...

Why not help the compiler
to pick up as many as it can? It seems perfectly logical to me.

Because it creates bad habits. If you do the checking yourself, you don't
need to "help" the compiler, if you get used on helping the compiler you
get (unconsciously) less careful when typing the code, just as I get
myself unconsciously less careful when I know that the compiler *must*
catch my mistakes. It's human nature, whether we discuss here C or not.

Both of us have proved the previous paragraph, with mistakes in pieces of
code we have actually posted, so your disagreement is futile.

Dan

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


If, we're discussing C, and from the C point of view the order doesn't
matter, then why do you insist that *for you* one order is better than
the other? It seems to me that we're discussing more than just C, here.

It doesn't matter to the compiler (*provided* you don't mis-type). And it
doesn't matter from a logical perspective. And it matters hardly at all to
the reader. So I see no reason not to take advantage of this (slight) gain.

Obviously, since the "subtle" error can be *trivially* avoided at NO
readability hit for anybody.

Yes, the subtle error (and it /is/ a subtle error, since it can be very hard
to track down) can be trivially avoided by perfect C programmers. Trouble
is, I've never met one.

There is no point in playing idiotic semantic games with me.

If you truly
consider yourself a beginner, making a major contribution to a C book was
dishonest.

Not at all. I can share what I know, even if I don't know everything.

Did you introduce yourself as a C beginner at the beginning of
the book in question, to warn your readers?

No. It didn't occur to me that it would be necessary. And the feedback I've
had on the book from language experts suggests that I didn't make too bad a
job of it, so the omission appears to have done no harm.

I was not aware that you were typing your code with your eyes closed.

Neither was I.

What do you think I meant by "triple checking"?

Presumably, you mean "take much longer to write a comparison of a constant
against a variable than I currently take".

It is, after the triple checking.

Alas, no - it is certainly possible to triple-check something and still not
notice an error (either one's own error or someone else's, in peer review).

While typing code, it should be busy checking its correctness...

Of course. But it's not foolproof. (There's a one-liner feed for you...)

Because it creates bad habits.

On the contrary, it prevents bugs.

If you do the checking yourself, you don't
need to "help" the compiler,

And if I do the checking myself /and/ "help" the compiler, I get the best of
both worlds.

if you get used on helping the compiler you
get (unconsciously) less careful when typing the code,

When I'm unconscious, I'm very careless indeed.

just as I get
myself unconsciously less careful when I know that the compiler *must*
catch my mistakes. It's human nature, whether we discuss here C or not.

Both of us have proved the previous paragraph, with mistakes in pieces of
code we have actually posted,

Of course. All the more reason to use every possible means to catch errors.

so your disagreement is futile.

Well, I can see that this argument is pointless, if that's what you mean.