Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #75484

Re: Shortened form of condition

Show all headers | View raw

On 11/09/2015 01:11 PM, Alla _ wrote:
> Thank you for your explanations. I am sorry but Ben and James suggested
> the ones that are close to my interpretation, while Barry has a different one.
> I don't have problems with reading bool values and their opposites, but I 
> do have an issue with controlling expressions and the way bool values are used
> in them.
> 
> 1) Ben and James suggest (it is close to how I have read the condition of 
> while loop), if I am not mistaken, that because end_of_text had been initially
> set to false, i.e. to 0, then "while (!end_of_text)" means 
> "while(end_of_text is true, i.e. equals 1)".

No. while(!end_of_text) means that at the start of every pass through
the loop, the expression !end_of_text is evaluated. end_of_text starts
with a value of false (==0), and so long as that value does not change,
!end_of_text will have a value of 1 (==true). The while loop notices
that 1 does not compare equal to 0, so it executes the body of the loop.

> Hence, when the loop is first encountered, the controlling expression of 
> end_of_text is 1 (!end_of_text). The loop iterates while this controlling expression is equal to 1. But in case the inner if condition is met, which 
> sets end_of_text to true, i.e. to 1, the next round of while loop will be 
> terminated because now !end_of_text will be equal to false. 
> 
> If this is the correct reading, then does it mean that I give the while loop
> a peremptory value of end_of_text being True (opposite to the initial value), 
> and the while loop takes it for granted, because nothing has physically occurred
> that would change initial assignment of 0 value to end_of_text?

I'm sorry to be nit-picking, but I can't figure out what you're trying
to say. If you're talking about a possible change to the code, perhaps
it might be clearer if you actually showed me the change you're talking
about, rather than trying to describe it. In particular, what do you
mean by a "peremptory value"?
The while loop takes nothing for granted: you provide a condition
expression to the while loop, and it's required to evaluate that
expression at the start of each pass through the loop, and to use the
result of that expression to decide whether or not to perform that pass.
When you say "nothing has physically changed", what do you mean by
"physically changed"? Could you give an example of something that would
be a "physical change"?

> 2) Barry suggests a different approach. while(!end_of_text) means that 
> end_of_text is false, i.e. as it had been initially declared. ...

All three of us indicated, by different methods, that
while(!end_of_text) means that the loop will continue executing so long
as end_of_text is false. If you thought that any of the us said anything
different, you were misunderstanding something.

> ... Hence the loop
> iterates if this condition holds; it ends terminates only if the inner if
> conditions is met and the value of end_of_text is set to true.
> 
> Therefore,
> which version is a correct one? :)

I recognized no errors in either Ben or Barry's explanations, nor did I
see any contradictions between anything any of us have said. So I'd say
they're all correct.

> And also, in either of above interpretations, - how does this while loop 
> know when to stop looping, if the inner if condition is not met, if there 
> is a text to read? 

When text[0] == '\0', end_of_text gets set to true. At the start of the
next pass through the loop, the expression !end_of_text gets evaluated.
That expression has the value 0 (==false). Because the value is zero,
the while loop terminates.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-09 06:23 -0800
  Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 14:44 +0000
  Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-09 10:17 -0500
  Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-09 09:20 -0800
  Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-09 10:11 -0800
    Re: Shortened form of condition Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 10:35 -0800
      Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 00:14 -0800
        Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-10 03:04 -0800
          Re: Shortened form of condition glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-10 21:42 +0000
        Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-10 11:13 +0000
          Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 07:58 -0800
            Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 17:06 +0000
            Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-10 12:11 -0500
              Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-10 14:01 -0500
          Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 08:30 -0800
            Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 09:07 -0800
              Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 09:29 -0800
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 11:02 -0800
                Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 11:33 -0800
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-11 00:28 -0800
                Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 16:05 +0000
                Re: Shortened form of condition glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-12 09:29 +0000
                Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-12 10:56 +0000
                Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:24 +0000
                Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-11 08:53 -0800
                Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:59 +0000
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-11 06:42 -0800
                Re: Shortened form of condition Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-10 14:04 -0500
              Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-10 10:43 -0800
    Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-09 13:44 -0500
    Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-09 10:57 -0800
      Re: Shortened form of condition Philip Lantz <prl@canterey.us> - 2015-11-10 01:52 -0800
    Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 19:35 +0000
      Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-09 11:52 -0800
  Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 00:33 -0800
    Re: Shortened condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 09:00 +0000
  Re: Shortened form of condition Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 16:01 -0800

csiph-web