small program

[Phil Carmody]

In

you really are comparing apples with mangos

apple == mango isn't 2 == x

Neither is it x == 2 - so?

If I were writing pseudo code (structured english) Id'd write things
like
when alarm count is equal to the alarm count limit scram the
reactor

I would write: if the alarm count [...]

Yup, that's what we're saying. If the alarm count [satisfies some
predicate]. Predicate follows variable.

exceeds the alarm count tolerance,
scram the reactor (except that I wouldn't write "scram"). Which just
goes to show that there's more than one way to think about these
things.


Ouch. You just scrammed the reactor.

No he didn't. If you're mistaking the above for C, then you've got
way bigger problems than scrammed reactors. See someone about that,
or maybe we can hold an intervention for you here?

Why? Surely they have equal relevance?

Because of the similarity to the natural language being used to
describe what is wanted. I can imagine it's possible that people
with different language backgrounds having different biases.

Phil

 

[Phil Carmody]

[...]
Certainly x != 0 and 0 != x are semantically exactly equivalent. ....
I'm not suggesting that the way you think about it is wrong.
In fact, your point of view is probably closer to mathematical
reality than mine.

Nah, he didn't curry the equality operator.

Phil

 

[Phil Carmody]

In C++, it's often quite a bit cheaper -- x++ may involve creating a new
object, while ++x might merely modify an existing one.

In C, I usually assume that the optimizer will do the right thing either
way, and there will only be a performance difference when I care about
the semantics. In any event, the cost is much lower -- there's no (reasonable)
chance that "x++" will invoke malloc() or the equivalent.

(Unreasonable? I can conceive of a system where if you use too many
intermediate values in an expression, something has to be allocated to stash
previous register values, or something similar. This is not the sort of
worry that keeps me up at night.)

More unreasonable - you've just dropped a pointer clearly off the end
of the array, invoked UB, and malloc(sizeof(struct nasal_demon)) ensued.

Phil

 

[Michael Foukarakis]

of jibberish:

The stupidity in your code is astounding. But then again, you don't
completely understand what you're trying to do.
Please promise me you'll consider that coding may not be the right
profession for you.

Anyway, how about this:

int main() {
int i = 0;
printf("0 0\n");
for(;i < 128; i++)
printf("%d %d\n", i, 128-i);
}

I'm pretty sure it does what you're "trying to do".

 

[osmium]

(And I must admit I find it rather puzzling that some people make such
a big deal out of this.)

It's a bit like seeing color spelled as colour, annoying.

I used to work for a guy who spelled develop as develope, a perfectly valid
American variant spelling. I would proof his work and change it to develop,
he would bitch and moan and change it back to develope. We never resolved
this, we just got different jobs.

I believe that (2 == x) is annoying and stoopid. Computers are to be bent
to our will, not the other way around. I am sure Asimov must have addressed
this issue.

 

[Dik T. Winter]

> Bill Cunningham a écrit : ....
>
> You see the nasty semicolon at the end of your second
> "for" statement ??????? ....
> This means that the whole "j" loop is an empty loop, and
> at the exit of that empty loop j is 127, so the
> while never catches!

And once that is corrected, the while will loop forever.

 

[Tim Rentsch]

<snip/>

That's quite a sentence to parse.

This suggests a new C idiom:

#define EXAMPLE (;0

for EXAMPLE {
...
}


(Sorry, I just couldn't resist.

 

[Seebs]

This suggests a new C idiom:

#define EXAMPLE (;0

for EXAMPLE {
...
}

Ooh!

#define INSTANCE (int lucky = 0; lucky < 1; ++lucky)

(If you're going to write code which depends on luck to run, might as
well be explicit about it.)

-s

 

[Andrey Tarasevich]

...
For example:

for ( i=0 ; i < 10 ; i++ )
do_something;
do_something_else;

The indenting makes it look as if the writer intended both statements to
be part of the loop, but the lack of braces means that only one
statement is actually in the loop. What was the writer's intent?
Sometimes, it's obvious from a quick look. Other times, you need to
delve deeper to figure out what the code "should" be doing.
...

A proper non-over-braced coding style would call for a vertical empty
space after the loop body in addition to the properly indented non-loop code


for ( i=0 ; i < 10 ; i++ )
do_something;

do_something_else;

"Creative" indentation as in your example, combined with the lack of
vertical spacing and braces, would indicate that the author himself
wasn't sure whether the 'do_something_else' part should be part of the
loop body.

 

[Tim Rentsch]

Ooh!

#define INSTANCE (int lucky = 0; lucky < 1; ++lucky)

(If you're going to write code which depends on luck to run, might as
well be explicit about it.)

Clearly we need to get the EXAMPLE macro canonized and
added to <errno.h> so all C programmers can benefit from
its use.