Is this C program doing what it is supposed to do ?

[Keith Thompson]

Were you unaware that it does?

But even in pure C90, which doesn't have _Bool/bool, the lack of
*direct* support for a boolean type is largely irrelevant.  Several
built-in operators ("==", "<", "!", etc.) yield int results that are
either 0 or 1, representing false or true results.

[snip]

<g>
I'm aware of C90's boole type and the way an int is easily used as a
substitute.

It's C99's (not C90's) bool (not boole) type. I'm glad you're
aware of it. Did you want to comment on anything else I wrote?
If not, why did you quote the entire article?

When posting a followup, it's best to quote just enough of the
parent article so that your followup makes sense. In particular,
it's best not to quote signatures unless you're commenting on them.

 

[Hans Vlems]

Well, if only C had built-in support for booleans ;-)
Were you unaware that it does?
But even in pure C90, which doesn't have _Bool/bool, the lack of
*direct* support for a boolean type is largely irrelevant.  Several
built-in operators ("==", "<", "!", etc.) yield int results that are
either 0 or 1, representing false or true results.

[snip]

<g>
I'm aware of C90's boole type and the way an int is easily used as a
substitute.

When posting a followup, it's best to quote just enough of the
parent article so that your followup makes sense.  In particular,
it's best not to quote signatures unless you're commenting on them.

Read my earlier posts; look for the [snip] entries
Text is possibly the worst way to clarify an issue.
Hans

 

[Chris H]

I agree with the general points you're making here -- but you're only
making very general points.

Where I strongly disagree is your apparent assertion that

if (foo == bar) {
flag = 1;
}
else {
flag = 0;
}

is clearer than

flag = (foo == bar);

It isn't but the original line was

flag = foo == bar;

or that

if (flag == 1) ...

is clearer than

if (flag) ...

The second implies. Where as the first is explicit.

That is what I was implying but you missed it ).

 

[Lew Pitcher]

why "by definition"?

Because:
"debugging is twice as hard as writing the code in the first place"
and
"you write code as cleverly as possible"

It is assumed that "as cleverly as possible" means "to the best of your
ability", and thus debugging is twice as hard as your ability to write
code.

debugging is the place where someone see, if he see right when he wrote
the code...

ITYM "extensive code testing".

Debugging is the place where someone sees that he was *not* right when he
wrote the code.

If he *had been* right, there would not have been bugs, and there would have
been no need to debug.

 

[Eric Sosman]

[...]
It isn't but the original line was

flag = foo == bar;

No, the original line was

while( (ch==getchar())!= EOF){

Please don't fabricate "facts" in support of your argument,
not even if you have a good one. The ends do not justify
the dishonest means.

 

[Ian Collins]

[...]
It isn't but the original line was

flag = foo == bar;

No, the original line was

while( (ch==getchar())!= EOF){

Please don't fabricate "facts" in support of your argument,
not even if you have a good one. The ends do not justify
the dishonest means.

The line (justifiably) deemed appalling was:

at_beginning = ch == '\n';

 

[Dr Nick]

[...]
It isn't but the original line was

flag = foo == bar;

No, the original line was

while( (ch==getchar())!= EOF){

Please don't fabricate "facts" in support of your argument,
not even if you have a good one. The ends do not justify
the dishonest means.

The line (justifiably) deemed appalling was:

at_beginning = ch == '\n';

It was, I'm afraid.

I certainly don't have a problem, particularly if you have a decent
boolean type, with

bool at_beginning = false;
....
....
if(ch == '\n')
at_beginning = true;

And in fact probably prefer it to

bool at_beginning;

at_beginning = (ch == '\n');

idiomatic C or not.

 

[Eric Sosman]

[...]
It isn't but the original line was

flag = foo == bar;

No, the original line was

while( (ch==getchar())!= EOF){

Please don't fabricate "facts" in support of your argument,
not even if you have a good one. The ends do not justify
the dishonest means.

Chris, I apologize for writing this. A simple ambiguity or
at worst a mistake is no reason for me to hurl injurious words
like "dishonest" around, and I should not have done so. Again,
I am sorry, and I will try behave more civilly henceforth.

 

[Ben Bacarisse]

The line (justifiably) deemed appalling was:

at_beginning = ch == '\n';

Ah, maybe you'd explain why it's appalling? Chris H won't say despite
being asked. Do you also agree with him that it's dangerous?

 

[Ian Collins]

Ah, maybe you'd explain why it's appalling? Chris H won't say despite
being asked. Do you also agree with him that it's dangerous?

Well it is compared to

at_beginning = (ch == '\n');

it takes the reader longer to parse the first, is it an assignment to
at_beginning or to at_beginning and ch?

at_beginning = ch = '\n';

 

[Keith Thompson]

It isn't but the original line was

flag = foo == bar;

Ok.

I agree that the parentheses make it clearer; I also prefer
flag = (foo == bar);
to
flag = foo == bar;
though not as strongly as you do.

I've been asking for some time now for you to clarify this point.
We could have saved considerable time if you had done so sooner.

The second implies. Where as the first is explicit.

That is what I was implying but you missed it ).

Ok, so the second form is more explicit than the first. So what?
Do you actually prefer "if (flag == 1)" to "if (flag)"? I still
haven't seen a clear answer to that question. On the other hand,
I and several others have explained the reasoning behind our
preference for "if (flag)" at some length.

I'm interested in your opinion, but not interested enough to spend
too much more time trying to drag it out of you.

 

[Keith Thompson]

Well, if only C had built-in support for booleans ;-)

Were you unaware that it does?

But even in pure C90, which doesn't have _Bool/bool, the lack of
*direct* support for a boolean type is largely irrelevant.  Several
built-in operators ("==", "<", "!", etc.) yield int results that are
either 0 or 1, representing false or true results. [snip]

<g>
I'm aware of C90's boole type and the way an int is easily used as a
substitute.

When posting a followup, it's best to quote just enough of the
parent article so that your followup makes sense.  In particular,
it's best not to quote signatures unless you're commenting on them.

Read my earlier posts; look for the [snip] entries
Text is possibly the worst way to clarify an issue.

Text is all we've got here. If you're not interested in clarifying
what you wrote before, I guess there's nothing else to say.

I find it frustrating when someone disagrees with something I've
written and doesn't clearly explain why, or respond to questions
about it. I *like* having my ideas challenged. It's always possible
that I'm wrong, and that someone else has a better idea than I do.
But if you aren't willing to enage in discussion, then neither of
us will learn anything.

 

[Ben Bacarisse]

Well it is compared to

It is what? Appalling or dangerous or both?

at_beginning = (ch == '\n');

You know what? If Chris H had said "I prefer to add parentheses round
the equality test" this whole sub-thread would not have happened. I
accept that people have style preferences and I am always interested to
read about them, but I doubt that this is Chris H's objection although
we'll probably never know.

it takes the reader longer to parse the first, is it an assignment to
at_beginning or to at_beginning and ch?

at_beginning = ch = '\n';

My problem is deciding where the reader needs help. In this case, I
deliberately posted without parentheses because I think it helps
students if they have to work things out a little ("ah! it's an
assignment just like x = y + 2;"), but there are many cases where extra
parentheses just get in way.

How do you decide? You must have some pretty clear-cut rules if the
bracketed version is fine and the un-bracketed one is cappalling (and
possibly dangerous).

 

[Ian Collins]

It is what? Appalling or dangerous or both?

Probably both, because at_beginning = ch = '\n' would look like a valid
assignment of at_beginning and ch, while a baracketed version would
arouse suspicion.

My problem is deciding where the reader needs help. In this case, I
deliberately posted without parentheses because I think it helps
students if they have to work things out a little ("ah! it's an
assignment just like x = y + 2;"), but there are many cases where extra
parentheses just get in way.

How do you decide? You must have some pretty clear-cut rules if the
bracketed version is fine and the un-bracketed one is cappalling (and
possibly dangerous).

I tend to bracket any expression used as an rvalue, or where I'd have to
remember precedence rules!.

 

[Anders Wegge Keller]

Ah, maybe you'd explain why it's appalling? Chris H won't say
despite being asked. Do you also agree with him that it's
dangerous?

Would you at the same time explain why you think this is a safe and
beutifull piece of code?

 

[luser- -droog]

Would you at the same time explain why you think this is a safe and
beutifull piece of code?

He's already done that, upthread.

If you want the variable at_beginning (be it of whatever integer type)
to contain a zero if ch is not equal to newline or a one if it is
equal,
then this is the most beautiful and safe way to do it in C.
If that isn't what you want, then you should do it a different way.

 

[Chris H]

[...]
It isn't but the original line was

flag = foo == bar;

No, the original line was

while( (ch==getchar())!= EOF){

Please don't fabricate "facts" in support of your argument,
not even if you have a good one. The ends do not justify
the dishonest means.

Chris, I apologize for writing this. A simple ambiguity or
at worst a mistake is no reason for me to hurl injurious words
like "dishonest" around, and I should not have done so. Again,
I am sorry, and I will try behave more civilly henceforth.

Apology accepted. Email is not a good way to have a conversation and
things tend to get miss understood.

However, as you say "a simple ambiguity" and that is my point. When
coding you need no ambiguities or implied things. It should all be
explicit.

 

[luser- -droog]

Which is provably bullshit as ANY half decent programmer knows. Shit
happens, bugs happen and many/most are easily debugged by anyone with
half a clue how to use a debugger.

This is NOT teletype/punch hole days.

Perhaps it *should* be. We'd all be really good at it by now!

 

[Anders Wegge Keller]

Anders Wegge Keller wrote:

He's already done that, upthread.

Not really. I just see a stated opinion, which is what I'm curious to
hear the reasoning behind.

If you want the variable at_beginning (be it of whatever integer
type) to contain a zero if ch is not equal to newline or a one if it
is equal,

I've been writing C for a living since 1998, so I know about the
syntax. I just fail to see how it is in any way safer, clearer or in
any other better than this:

if (ch == '\n') {
at_beginning = 1;
} else {
at_beginning = 0;
}

then this is the most beautiful and safe way to do it in C. If that
isn't what you want, then you should do it a different way.

Showing off doesn't score high with me. And that is the only reason
for coding in that cramped style.


at_beginning = ch == '\n';
at_beginning = ch = '\n';

Both of the lines are equally plausible, when seen by themselves. So
to figure out the intent, you need to look elsewhere in the source. In
this case it isn't that hard, but when you are looking at 400k lines
of code written over a decade by a multitude of developers, each with
their own idea about how "clever" they are, constructs like this
become a major risk.

 

[luser- -droog]

 Not really. I just see a stated opinion, which is what I'm curious to
hear the reasoning behind.


 I've been writing C for a living since 1998, so I know about the
syntax. I just fail to see how it is in any way safer, clearer or in
any other better than this:

 if (ch == '\n') {
   at_beginning = 1;
 } else {
   at_beginning = 0;
 }


 Showing off doesn't score high with me. And that is the only reason
for coding in that cramped style.

 at_beginning = ch == '\n';
 at_beginning = ch = '\n';

 Both of the lines are equally plausible, when seen by themselves. So
to figure out the intent, you need to look elsewhere in the source. In
this case it isn't that hard, but when you are looking at 400k lines
of code written over a decade by a multitude of developers, each with
their own idea about how "clever" they are, constructs like this
become a major risk.

I see where you're coming from. I think here we're saved by
the semantic information in the variable name. Perhaps
is_at_beginning would be better. But I'm not currently
able to think of a reason to store '\n' in a variable
named 'at_beginning'.