for loop problem

C

CBFalconer

Keith said:
You said that the ability to read a single input character without
waiting for an end-of-line is (a) non-standard (which is quite
correct, at least with regard to the C standard, and nobody has
disputed that point), and (b) "unique to that system" (which is quite
incorrect).

No, I said that "Any other ability is non-standard and unique to
that system". Willem broke the sentence in two.
 
K

Keith Thompson

CBFalconer said:
No, I said that "Any other ability is non-standard and unique to
that system". Willem broke the sentence in two.

Is that intended to support your claim? It doesn't. You're still
wrong. Breaking the sentence in two doesn't change that.

Incidentally, in the article to which the above was a followup, I wrote:

| (If you've read my entire followup, please quote this line.)

Please do me, and all of us, the simple courtesy of not responding to
an article until and unless you've actually read all of it. I'm
assuming, based in part on your recent history, that you in fact
didn't read it, rather than that you chose to disregard my simple
request.
 
G

Guest

Please TEST your code before posting. You would then save a lot of
people yourself. Having the unnecessary continue also deflects from
noticing the error of course and why I in over 20 years of programming I
have never known anyone use it for that use in C.

while ((EOF != (ch = getc(f))) && ('\n' != ch));

is better but still horrible. You have a habit or tendency to convolute
your code. This is C. C can and should be concise.

while (((ch=getc(f))!=EOF)&&(ch!='\n'));

Is even clearer and reads properly left to right.

I don't think taking all the spaces out improves the clarity
I find it particularly
amusing that your pathetic defence of the " CONST == var" style is to
defend against "accidentally" using "=" instead of "==" and yet you
still <got it wrong>

<snip>
 
G

Guest

No, I said that "Any other ability is non-standard and unique to
that system".  Willem broke the sentence in two.

and in what way did that change the meaning?
That is a valid transformation that preserves the meaning
 
J

James Kuyper

CBFalconer said:
See underlining.

Since my response was to the part of your comment about non-standard
abilities, how is your reference to "the facilities of standard C"
relevant? My point was that those non-standard abilities might be very
far from being unique to his particular system. They might be found on
many different systems, despite the fact that they are not "facilities
of standard C". The phrase "unique to" has a very specific meaning, one
which does not allow for that possibility.
 
J

James Kuyper

CBFalconer said:
I don't believe this. Are you now claiming that POSIX is part of
standard C? I don't find that word in any copy I have of the C
standard.

Who suggested anything of the kind. The commont was very specifically
about "non-standard abilities". How could such a comment be
misunderstood as referring to something that is part of the C standard?
 
J

James Kuyper

CBFalconer said:
No, I said that "Any other ability is non-standard and unique to
that system". Willem broke the sentence in two.

So? Is his break up of your sentence invalid? Do you claim that your
actual phrase has a meaning different from "Any other ability is
non-standard. Also, any other ability is unique to that system."? If so,
could you please explain how? Please try using truth tables. That is to
say, would your phrase be true, false, or indeterminate if the ability
in question were:

1. standard and not unique
2. standard and unique
3. non-standard and not unique
4. non-standard and unique

Willem's breakage of your statement produced a pair of sentences which
are as a pair, are false in the first 3 cases, and true for case 4. How
does that differ from your sentence as originally written?

Note that the reality of this situation corresponds to case 3.
 
B

Ben Bacarisse

luserXtrog said:
CBFalconer <[email protected]> writes:
[...] I in over 20 years of programming I
have never known anyone use it for that use in C.

while ((EOF != (ch = getc(f))) && ('\n' != ch));

is better but still horrible. You have a habit or tendency to convolute
your code. This is C. C can and should be concise.

Platitudes and truisms.
while (((ch=getc(f))!=EOF)&&(ch!='\n'));

Is even clearer and reads properly left to right. I find it particularly
amusing that your pathetic defence of the " CONST == var" style is to
defend against "accidentally" using "=" instead of "==" and yet you
still fucked it up. Nice one. A real achievement.

We recently had quite a lengthy skirmish about this very issue.
The trend was unanimously against the zero-length statement
(nothing between the ')' and the ';') because of the statement's
syntactic significance.

Silence != consent. I am very happy to discuss ways to make the
statement controlled by the while more visible, but that does not mean
I am arguing in favour! This may seem odd, but a lot of energy can be
expended on matters of style without reaching any sort of agreement so
I think it is better to calmly discuss the options; debate the pros
and cons and leave it at that. In the end, I usually go back to doing
what I did before.
My own preference tends toward a brief (possibly empty) comment,
perhaps:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) /*eat till \n*/;

or even:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) 0x2E0L;

Well, that last one illustrates the whole problem. Anything you do
over an above what the syntax requires is arbitrary. If you like
while (C) {}, why not while (C) {{{}}}? Surely even more visible is
better than slightly visible?

[BTW you might no have noticed that you don't need a hex constant.
2E0L is a valid floating point constant!]

This motivates my own preference for minimal, and that includes the
brackets that everyone has so far left alone. I'd write:

while ((ch = getc(f)) != '\n' && ch != EOF);

I think the '\n' test is the more important one, so I would want to
bring it forward. I don't think spaces impede reading (I think they
help) so I never use minimal spaces, but superfluous brackets get in
the way. If anyone disagrees with this, I am very happy to listen,
but I doubt I would want to argue my corner, any more than I am likely
to change my preference.
 
L

luserXtrog

luserXtrog said:
CBFalconer <[email protected]> writes:
CBFalconer said:
     while ((EOF != (ch = getc(f))) && ('\n' !- ch)) continue;
[...] I in over 20 years of programming I
have never known anyone use it for that use in C.
while ((EOF != (ch = getc(f))) && ('\n' != ch));
is better but still horrible. You have a habit or tendency to convolute
your code. This is C. C can and should be concise.
Platitudes and truisms.
We recently had quite a lengthy skirmish about this very issue.
The trend was unanimously against the zero-length statement
(nothing between the ')' and the ';') because of the statement's
syntactic significance.

Silence != consent.  I am very happy to discuss ways to make the
statement controlled by the while more visible, but that does not mean
I am arguing in favour!  This may seem odd, but a lot of energy can be
expended on matters of style without reaching any sort of agreement so
I think it is better to calmly discuss the options; debate the pros
and cons and leave it at that.  In the end, I usually go back to doing
what I did before.

Conceded. I hesitated over the word 'unianimously'. I ought to have
indulged that doubt a little further.
Well, that last one illustrates the whole problem.  Anything you do
over an above what the syntax requires is arbitrary.  If you like
while (C) {}, why not while (C) {{{}}}?  Surely even more visible is
better than slightly visible?

For any given context there is an appropriate level of visibility.
But short of deliberate obfuscation (which charge I deny), I maintain
that some (brief) thing ought to be there. Perhaps a newline and
indentation before the semi?
[BTW you might no have noticed that you don't need a hex constant.
2E0L is a valid floating point constant!]

Excellent. Thanks. This was (half-)joking.
This motivates my own preference for minimal, and that includes the
brackets that everyone has so far left alone.  I'd write:

  while ((ch = getc(f)) != '\n' && ch != EOF);

I think the '\n' test is the more important one, so I would want to
bring it forward.  I don't think spaces impede reading (I think they
help) so I never use minimal spaces, but superfluous brackets get in
the way.  If anyone disagrees with this, I am very happy to listen,
but I doubt I would want to argue my corner, any more than I am likely
to change my preference.

I do like that arrangement of comparisons.
But how about this?:

while( !wmemchr( (wchar_t[]){'\n',EOF}, (wchar_t)ch=getc(f), 2 ))
;
 
B

Ben Bacarisse

luserXtrog said:
On Apr 16, 10:23 am, Ben Bacarisse <[email protected]> wrote:

For any given context there is an appropriate level of visibility.
But short of deliberate obfuscation (which charge I deny), I maintain
that some (brief) thing ought to be there. Perhaps a newline and
indentation before the semi?

Whatever you like! Honestly, the best we can manage is to say what we
do and why. Everyone not so far ossified can then pick what they like
having seen lots of options and opinion.

All C programmers will have to be happy to read code that has lone ;s in
it, and most of us have to be happy to write code the way other people
sometimes specify, so it is best not to be too inflexible.

I do like that arrangement of comparisons.
But how about this?:

while( !wmemchr( (wchar_t[]){'\n',EOF}, (wchar_t)ch=getc(f), 2 ))
;

That is waaaay too tricksy for my taste. The cast is another of those
"I know what I am doing" casts causing so much trouble in another
thread and I don't think that wmemchr is guaranteed to find
(wchar_t)EOF when it is asked to look for it. It might not even be a
valid wide character. I suspect there are no implementations where
this will go wrong, but that is not the point.

If you want to do this, write your own

const int *intchr(const int *where, int what);

function and use that.

I am rather stuffy about "coding tricks". I think programmers should
reserve their ingenuity for algorithms. Be as clever as you like with
algorithms, but be as boringly conventional as you can stomach in you
coding.
 
C

CBFalconer

Ben said:
.... snip ...

Silence != consent. I am very happy to discuss ways to make the
statement controlled by the while more visible, but that does not
mean I am arguing in favour! This may seem odd, but a lot of
energy can be expended on matters of style without reaching any
sort of agreement so I think it is better to calmly discuss the
options; debate the pros and cons and leave it at that. In the
end, I usually go back to doing what I did before.

Agreed. However, this portion of the thread is entirely due to the
ravings of that troll Richard noname, who objects to valid code.

I find "continue;" much clearer than a nude ";".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top