Deferencing void pointer

[Dan Pop]

I don't /rely/ on what you call silly gadgets. I use the const==var order as
an additional check, because I know I make mistakes of this kind, no matter
how carefully I check. I know you do, too, because you have done so in an
article posted to this group, so please don't get all high and mighty on
me.

I did it in a context where it was a syntax error, so there was no risk
of silently getting the wrong result. Big difference. When I know that
the compiler can't help, I do the triple checking. When merely providing
an initialiser, I'm less careful.

In any event, const==var can never catch a mistakenly typed == where = was
meant; its purpose is to catch (where possible) the /opposite/ mistake.

While the purpose of triple checking is to catch *any* mistake related to
the (mis)usage of the assignment/equality operators. Thus rendering the
silly const==var trick futile.

Dan

 

[Dan Pop]

It's generally necessary to port C code to C++.

It NEVER happened to me... C++ has an official interface for
interoperating with C code, which completely removes the need to port C
code to C++.

Dan

 

[CBFalconer]

In <[email protected]> Richard Heathfield
.... snip ...


While the purpose of triple checking is to catch *any* mistake
related to the (mis)usage of the assignment/equality operators.
Thus rendering the silly const==var trick futile.

Most of us mere mortals have, in the past, contrived to re-read
our own code many more than three times, without catching such
errors. There appears to be a fault in our infallibility
mechanism. Thus we find a net gain in using the zero effort
"trick" up front.

My favorite foolish foulup is to add an extraneous semi to a macro
definition. At least that one tends to trigger misleading
compiler complaints rather than silent acceptance.

 

[Dan Pop]

Most of us mere mortals have, in the past, contrived to re-read
our own code many more than three times, without catching such
errors. There appears to be a fault in our infallibility
mechanism.

If you triple check at the time you write it, it is practically impossible
to end up with the wrong operator: "hey, I wrote ==, is it really what I
want?".

Thus we find a net gain in using the zero effort "trick" up front.

Your fondness of zero effort "tricks" probably explains the high rate of
bugs in the code you post... It takes real effort to write correct C
code!

My favorite foolish foulup is to add an extraneous semi to a macro
definition.

Another place where I triple check, because I don't even want to consider
the consequences of a mistake.

Dan

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


I did it in a context where it was a syntax error, so there was no risk
of silently getting the wrong result. Big difference.

No, no real difference. It just shows that we're all fallible - even you.
You have your ways of avoiding errors, and I have mine. Yours don't always
work, and neither do mine. We all make out the best we can.

When I know that
the compiler can't help, I do the triple checking. When merely providing
an initialiser, I'm less careful.

I try to be careful /all/ the time. I don't always succeed. I use all the
useful techniques I know of to assist me in reducing the number of errors
in my code, of which the const==var technique is just one. That you do not
happen to value it does not make it valueless to /me/.

 

[karl malbrain]

It NEVER happened to me... C++ has an official interface for
interoperating with C code, which completely removes the need to port C
code to C++.

Nonsense. Lot's of porting falls completely outside any "official
interface." karl m

 

[Dan Pop]

Nonsense. Lot's of porting falls completely outside any "official
interface." karl m

???

Dan

 

[Dan Pop]

No, no real difference.

Even a blind can see the difference between a mistake that requires a
diagnostic one that doesn't.

It just shows that we're all fallible - even you.

Of course I'm fallible and I have provided ample proof of that, over the
years. It's just that I am perfectly able to avoid certain insidious bugs
by paying extra attention at the points where I have a chance to actually
generate them, without resorting to any silly tricks.

I try to be careful /all/ the time. I don't always succeed. I use all the
useful techniques I know of to assist me in reducing the number of errors
in my code, of which the const==var technique is just one. That you do not
happen to value it does not make it valueless to /me/.

Which goes on to show that there is something wrong with your programming
methodology. However, if you're happy with it, keep doing things your
way... Just don't encourage other people to follow your example.

Dan

 

[Alex]

???

Methinks that he thinks that "official interface" implies
"standard library"

Alex

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


Even a blind can see the difference between a mistake that requires a
diagnostic one that doesn't.

Oh, of course I can. That's why I use the const == var construct.

Of course I'm fallible and I have provided ample proof of that, over the
years. It's just that I am perfectly able to avoid certain insidious bugs
by paying extra attention at the points where I have a chance to actually
generate them, without resorting to any silly tricks.

And I am perfectly able to avoid certain insidious bugs by using a technique
that requires a diagnostic if I type = instead of ==, instead of being
silly enough to rely solely on my remembering to triple-check each time.
One man's silly is another man's sensible. To use words like "silly" in
this context is silly. (There ya go - two sig block quotes for the price of
one.) (Or is that three?)

Which goes on to show that there is something wrong with your programming
methodology.

I disagree.

However, if you're happy with it, keep doing things your
way...

I plan to do just that.

Just don't encourage other people to follow your example.

Oh, but I /do/. You see, it's a sensible technique for fallible people. That
you disagree does not affect my opinion in the slightest, despite the high
regard I have for your knowledge of the C language.

 

[karl malbrain]

???

Porting code fragments from one function to another, and from C to C++
falls outside the C++ "official interface" for interacting with C.
karl m

 

[Dan Pop]

Oh, but I /do/. You see, it's a sensible technique for fallible people.

Nope, it isn't. All people are fallible, and the only technique that
catches any = vs == error that a compiler cannot or doesn't have to catch
is engaging your brain. If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view), if you do, you don't need it in the first place.

Dan

 

[Dan Pop]

Porting code fragments from one function to another, and from C to C++
falls outside the C++ "official interface" for interacting with C.

No problem, that's why it's called *porting* code fragments and not
*reusing* code fragments.

It's no different from porting code fragments from C to *any* other
programming language. There is *nothing* special about C++.

Dan

 

[Sheldon Simms]

Nope, it isn't. All people are fallible, and the only technique that
catches any = vs == error that a compiler cannot or doesn't have to catch
is engaging your brain. If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view), if you do, you don't need it in the first place.

Logical?
How is (0 == X) any less logical than (X == 0)?

 

[Dan Pop]

Logical?
How is (0 == X) any less logical than (X == 0)?

I was not talking about formal logic, merely about code that reflects the
programmer's intention (aka readable code).

You want to test whether X is equal to zero, not whether zero is equal to
X. X == 0 *directly* reflects this intention, while 0 == X doesn't.

Dan

 

[Alex]

Nope, it isn't. All people are fallible, and the only technique that
catches any = vs == error that a compiler cannot or doesn't have to catch
is engaging your brain. If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view), if you do, you don't need it in the first place.

[/QUOTE]

Logical?
How is (0 == X) any less logical than (X == 0)?

How many times have you said aloud "if 0 is equal to X then ..."?

Alex

 

[CBFalconer]

.... snip ...

I was not talking about formal logic, merely about code that
reflects the programmer's intention (aka readable code).

You want to test whether X is equal to zero, not whether zero
is equal to X. X == 0 *directly* reflects this intention, while
0 == X doesn't.

No, I want to test whether the entity represented by 0 is
interchangeable with the entity represented by X in terms of some
pre-specified set of attributes. Some consider this symettry,
others consider it special relativity, while others consider it
pouring oil upon the flames.

 

[CBFalconer]

.... snip ...


How many times have you said aloud "if 0 is equal to X then ..."?

In languages other than C, how many times have you said:

if (0 <= x <= 3) then ....

 

[Alex]

In languages other than C, how many times have you said:

if (0 <= x <= 3) then ....

This is an entirely different issue. Your example is traditional
mathematical notation. If this was a feature of C, I /would/ use
it.

A more relevant subsection of your example would be

if (0 <= x)

which, to me, is unreadable.

Alex

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


Nope, it isn't. All people are fallible, and the only technique that
catches any = vs == error that a compiler cannot or doesn't have to catch
is engaging your brain.

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

If you don't engage the brain, the technique
doesn't buy you anything (it just make your code look silly, from a
logical point of view),

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

if you do, you don't need it in the first place.

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.