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


Groups > comp.lang.c > #75487

Re: Shortened form of condition

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: Shortened form of condition
Date 2015-11-09 10:57 -0800
Organization None to speak of
Message-ID <lntwovxaom.fsf@kst-u.example.com> (permalink)
References <b6b2a9ec-4944-4e34-95e1-779161509469@googlegroups.com> <62775b24-22c8-4b78-85ca-6ca99456f2c5@googlegroups.com>

Show all headers | View raw


Alla _ <modelling.data@gmail.com> writes:
> 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)".

Quoting the C standard:

    The result of the logical negation operator ! is 0 if the
    value of its operand compares unequal to 0, 1 if the value
    of its operand compares equal to 0. The result has type int.
    The expression !E is equivalent to (0==E).

"is true" does not mean "equals 1".  It means "does not equal 0".

If a value is being used as a condition, 0 is false, anything other than
0 is true.  The specific value 1 can be thought of as the canonical true
value, and it's the value yielded by any operators whose results are
meant to be used as conditions (==, !=, <=, >=, <, >, !).

So this:

    while (!end_of_text)

is exactly equivalent to this:

    while (end_of_text != 0)

But the way I'd *read* it is:

    "while not end_of_text"

To understand that, one has to understand that the "!" operator is
pronounced "not" *and* what the "!" operator itself does.  (There's a
macro `not` defined in <iso646.h> that expands to `!`, but I suggest
ignoring that.  It was introduced to cater to programmers with keyboards
that don't have the ! characater, and its use is not idiomatic.)

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

It iterates while the controlling expression `!end_of_text` is unequal
to 0.  As it happens, the only values it can have are 0 and 1, so the
two descriptions are effectively equivalent *in this case*, but it's
still an important distinction in the general case.

Since end_of_text is defined as an object of type bool, the only values
it can have (unless you do something really strange) are false (0) and
true (1).  So although the language defines the ! operator as I've
quoted above, when applied to a bool value you can safely think of it as
changing false to true and true to false.  But even for objects of type
bool, you shouldn't compare a value of equality or inequality to
`false`, `true`, `0`, or `1`; just test the value itself.

[...]

> 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? 

It stops looping when !end_of_text is false, i.e., when end_of_text
becomes true, which happens when the statement

    end_of_text = true;

is executed, which happens when (text[0] == '\0').

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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