small program

[Morris Keesan]

#include <stdio.h>

int main() /*int is needed I guess and void is optional */

{
int a[128]={0};
int b[128]={0};
int i,j;
for (i=0;i<127;++i)
{
for (j=128;j!=0;--j)
printf("%i %i\n",a,b[j]);
}
}

I don't know if that would work or not.

It depends on what you mean by "work".
Here's a shorter and simpler program which does the same thing
as yours:

#include <stdio.h>

int main(void)
{
for (int i = 0; i < 16256; ++i) puts("0 0");
return 0;
}

 

[Andrey Tarasevich]

...
CONCLUSION:

ALWAYS WRITE BRACES IN YOUR FOR STATEMENTS!!!
...

Always writing braces in your 'for' statements provides absolutely no
protection from an accidental erroneous excessive semicolon after 'for'.
With the semicolon, your braced code can still be treated as an
independent compound statement, not related to the preceding 'for'
statement in any way. I.e. what you are saying in your "conclusion"
achieves absolutely nothing.

"Always write braces in your 'for' statements" is one of those fake C
"wisdoms" that seem to sound right at first, but in fact make no sense
whatsoever. The reason it does appear to sound right at first is because
the idea is "stolen" from a completely different statement: it might
make sense to "always write braces" in your 'if' statements, since it
might protect your from accidental mis-association of 'else' branches.
It is worth noting though that while it does make sense in theory, in
practice it is about as useful as the popular advice to always write
your comparisons as '2 == x' (as opposed to 'x == 2'), i.e. not useful
at all and actually does more harm than good.

 

[Andrey Tarasevich]

Translation: they have not yet saved /you/ time and money.

They certainly have not. While the negative impact such coding habits
have in the code readability is felt by me immediately (this, of course,
depends a lot on personal preferences), after almost two decades of
almost everyday C/C++ development I'm yet to see someone to actually
make those dreaded mistakes the doomsayers keep predicting.

 

[Nick Keighley]

    I have rewritten and rewritten and written again this small program. Can
anyone that knows what I am try to achieve tell me what I'm doing wrong?

you mean you don't know what you are tryingt o achieve?

 

[Nick Keighley]

Richard Heathfield wrote:

reinserted advice:

"It is worth noting though that
while it does make sense in theory, in practice it is about as
useful as the popular advice to always write your comparisons as '2
== x' (as opposed to 'x == 2')"

They certainly have not. While the negative impact such coding habits
have in the code readability is felt by me immediately (this, of course,
depends a lot on personal preferences), after almost two decades of
almost everyday C/C++ development I'm yet to see someone to actually
make those dreaded mistakes the doomsayers keep predicting.

I've certainly confused = and == in the past (not recently though).
One of my collegues (an experienced C programmer) actually made that
mistake within the last few days.

But I agree I can't take the lack of readability. So I neither
reverse my equality tests nor put in {}s around mono-statement ifs and
fors.

 

[Seebs]

He knows exactly what he's trying to achieve - he's trying to write a
cryptographically secure relational database management system.

Well, insofar as the key component of this is strings of text of which
the cleartext meaning cannot be discerned by an attacker, I think he's
making a good start.

-s

 

[Nick Keighley]

Nick Keighley wrote:

Neither do I. An equality test is saying "are these two values the
same?" From a readability perspective, it's hard to understand why
you might think that apple == mango is somehow more readable than
mango == apple. It's also hard to understand why you think that
putting the mango first constitutes a "reversal". Why doesn't putting
/apple/ first constitute a reversal?

you really are comparing apples with mangos

apple == mango isn't 2 == x

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

or
IF alarm_count = alarm_count_limit
scram_reactor()

The variable quantity coming before the constant.

Normal mathematical notation follows the same convention

A x,y s.t. x + y = 0

Again, do you have trouble reading the following code?

if(cond)
{
  statementA;
  statementB;

}

If those don't cause you any trouble, why should

if(cond)
{
  statementA;
}

be any more difficult to read?

but then
return (0);
and
sizeof (*ptr)

aren't all that hard to read either. Your way of coding mono-statement
fors (etc) wastes vertical space which is still a limited resource
(more
so if I code on my laptop)

 

[Nick Keighley]

I would write: if the alarm count 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.

not if it isn't C (IF isn't a language word in C). If I wanted to
assign
a value to alarm_count I'd write

alarm_count := 94
or
alarm_count <- 94

Why? Surely they have equal relevance?

you aren't arguing about that one?


<snip>

 

[Nick Keighley]

as God and the Revised Report intended

I'd use the assignment operator. That's what it's for.



Not being a mathematician, I'm not qualified to argue about that one.
I am mildly curious to know what it has to do with C programming,
though. We /are/ talking about C programming, yes?

I thought programming in C was simply a straightforward application
of mathematics.

What is the Standard but the formal definition of a series of
transformations
to an input text?

(this is why I couldn't agree the the Objective Truth guy)

 

[Morris Keesan]

Nick Keighley wrote:

Why? Surely they have equal relevance?

Yes, perhaps logically and mathematically, but psychology and linguistics
are not logic and maths. Where I live, a native English speaker is much,
much,
more likely to say things like, "If the door is open ..." or "If the
outside
temperature is below 20 degrees ...", compared to "If 'open' is the state
of
the door" or "If 20 degrees is greater than the outside temperature".

Since the format of this kind of construct is purely for the human reader,
I find that the logic of a piece of code is easier to read the more it
conforms
to natural language. I can read and understand code with "if (2 == x)" in
it,
but even though I know what the author intended, I still experience a
mental
"stumble" while reading it, because it feels unnatural.

(I wonder: if you write equality expressions as "2 == x", do you also, for
consistency, write code like "0 != x" and
"for (i = 0; sizeof chararray > i; i++)"?)

 

[Keith Thompson]

(a) Those aren't equality expressions. There is no !== operator, no =>
operator, no risk of accidentally assigning instead of comparing;
(b) I see no logical difference between x != 0 and 0 != x, so I don't
understand the point you're trying to make.

Certainly x != 0 and 0 != x are semantically exactly equivalent.
But to me, and to a lot of other people, x != 0 looks right and
0 != x looks -- well, not wrong exactly, but awkward. I don't
have any real problem reading it, but it does cause me to stumble
mentally, just briefly.

It's very similar to the mental stumble I experience when I read
a top-posted Usenet article; all the information is there, and I
can read and understand it, but it's presented in an order that I
find unnatural.

I know that some people don't see the difference. Well, obviously
you see the difference, but you don't find either form more awkward
than the other.

More generally, when I see x != y, I think of x as the thing I'm
asking about, and "!= y" as the question I'm asking about it. When I
think about it that way, x != 0 makes sense. I have a quantity x,
and I don't know everything about it, so I have to ask: is it unequal
to 0? When I see 0 != x, it's like I start with the quantity 0,
something I already know all about -- and now I'm asking for more
information about 0 (is it unequal to x?).

Yoda-style word order fan of I am not.

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. But perhaps this will help you understand a
bit better why some of us dislike the 0 != x form.

 

[Kenny McCormack]

-=-=-=-=-=-



Indeed. The amount of time lost trying to parse that unnatural order
far exceeds the amount of time saved. If you know enough to write
(2==x), you also know enough to write (x==2) instead of (x=2) -- and any
decent compiler will warn you about the (x=2) case these days.

That's the usual argument advanced - that it prevents the x=2 error.
But, as you say, it's been decades since compilers have failed to warn
about that.

This might have made sense a few decades ago, like the advice I often
see to use ++x instead of x++ or x<<1 instead of x*2, but not today.
Compilers have gotten smarter; we humans haven't.

All very true.

 

[Gus Gassmann]

Indeed. The amount of time lost trying to parse that unnatural order
far exceeds the amount of time saved. If you know enough to write
(2==x), you also know enough to write (x==2) instead of (x=2) -- and any
decent compiler will warn you about the (x=2) case these days.

This might have made sense a few decades ago, like the advice I often
see to use ++x instead of x++ or x<<1 instead of x*2, but not today.
Compilers have gotten smarter; we humans haven't.

I don't want to step into a hornets nest, but I have never seen anyone
advocating the use of ++x instead of x++. To me they mean very different
things. Why would one use them interchangeably, and what reason might
one give for preferring ++x?

 

[Seebs]

I don't want to step into a hornets nest, but I have never seen anyone
advocating the use of ++x instead of x++. To me they mean very different
things. Why would one use them interchangeably, and what reason might
one give for preferring ++x?

If I do not specifically need the ++x semantics, I always write ++x because
"increment x" is more natural to me than "x increment". Also, the semantics
of ++x are simpler. (It's very close to equivalent to (x+=1), while there's
no similarly trivial way to express the semantics of x++.)

-s

 

[Andrey Tarasevich]

I don't want to step into a hornets nest, but I have never seen anyone
advocating the use of ++x instead of x++. To me they mean very different
things. Why would one use them interchangeably, and what reason might
one give for preferring ++x?

For some the recommendation to use '++x' instead of 'x++' comes from C++
world, where in general case the former form is preferable. I, for one,
also use '++x' in C code whenever I can, and only use 'x++' when it is
really necessary (i.e. when I care about the result and specifically
need the original value).

 

[Seebs]

Why is it preferable in the general case?

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

-s

 

[Andrey Tarasevich]

Why is it preferable in the general case?

Because in general case in C++ one might run into an 'x' of user-defined
type with overloaded '++'. In order to implement the overloaded postfix
'++' (while adhering its expected behavior, i.e. "evaluates to the
original value of its operand"), one usually has to explicitly copy the
former value of 'x' aside, then perform the physical modification of 'x'
and then return the [previously copied] former value as the result
(which often involves another instance of copying). With prefix
increment nothing like that is necessary. For this reason, depending on
the type of 'x', postfix '++' might prove to be quite a bit more
expensive than prefix '++'.

In C the above does not apply, since these operators are only applicable
to basic types, and introduce no extra sequence points, which gives the
compiler full understanding of the semantics of the operation and full
freedom in optimizing it. In C there's nothing to prevent the compiler
from generating the same most efficient code for both '++x' and 'x++' in
contexts where both are interchangeable.

 

[Seebs]

And if you /do/ specifically need the ++x semantics, you always write
++x because you specifically need to write it.

.... The first "++x" should probably have been "x++".

(Rereading, I realize that when I first wrote the above, I omitted the final
double-quote character...)

This gets right back into the "assuming programmers are idiots" discussion
we had a while back. I'm very fast, I'm quite good at getting elaborate and
arcane bits of code correct, I regard deep mysteries as fairly obvious...

But in third grade, I flunked the math test that involved performing 100
single-digit addition problems. To this day, my error rate on those is about
3-5%; I simply can't do simple operations reliably. (This is, in turn,
why I'm fairly good at a lot of more esoteric arithmetic; because if I don't
parity-check my results, invert operations, and otherwise verify them, they're
pretty much useless.)

It's not that it's necessarily a fatal flaw in a programmer to be physically
incapable of getting details like this right; it just requires a great deal
of attention to detail, an aggressive code review process, and tolerant
coworkers.

-s

 

[Morris Keesan]

I don't want to step into a hornets nest, but I have never seen anyone
advocating the use of ++x instead of x++. To me they mean very different
things. Why would one use them interchangeably, and what reason might
one give for preferring ++x?

I've never "advocated" using ++x, but I long ago got in the habit of
using ++x instead of x++ when the desired result is simply incrementing x
(e.g. I almost always write for loops like "for (i = 0; i < LIMIT; ++i)
....".
"++x" means exactly the same thing as "x = x + 1" (assuming that x is not
an expression with side-effects), while "x++" means
"increment x, but the value of this expression is the pre-incremented
value of x."

For several years, I was using a compiler that wasn't clever enough to
optimize
away the difference, and for "x++", even when the expression value wasn't
being
used, t would generate machine code which saved the pre-incremented value
of x
somewhere, perform the increment, store the incremented value back into x,
and
then load the saved pre-incremented value back onto the stack, or into
whatever
register was holding the value of the most-recently evaluated expression.
In the name of micro-optimization, I got into the habit of preferring "++x"
unless I need the post-increment behavior, and I still use it,
unthinkingly,
in C and any other language sufficiently C-like to have ++ operators.

 

[Keith Thompson]

I think you've put your finger(!) on the principal objection that many
people have to this technique - i.e. that any programmer worth his or
her salt or pepper should know that = means assignment and == means
comparison. And of course they /do/. But typos happen.

The objection that "most compilers warn about this" I consider
entirely spurious. It's a bit like saying "well, most cars have
airbags nowadays so nobody needs to worry about driving too fast".
Not a perfect analogy because it's late/early and I'm tired, but my
point is that most != all.

Don't you mean all != most?

}