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

Groups > comp.lang.c > #75451 > unrolled thread

Shortened form of condition

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#75756

Alla _ <modelling.data@gmail.com> writes:

>> Does the author acknowledge the problems with this read_line() function?
>> Does he provide a safer alternative later?  
>
> I don't recall him doing so. 
>
> May I ask for an advice on a book that teaches professional coding and 
> helps to develop correct coding principles, unlike Kochan's one?

I'm a bit out of date so I can't suggest any current books, but there is
a fundamental problem with trying to do what Kochan is trying to do.
He's trying to teach the basic concepts about procedural programming --
how to use variables, assignments, input/output, loops, functions and so
on to achieve some desired end result -- whist using C to do it.

Take one tiny point: testing if a character is "printable".  There's a C
function for that: isprint.  Now you may be able to skip the idea that
it's possibly macro as well, but "professional coding" requires a cast
of the argument in many cases:

  if (isprint((unsigned char)ch)) ...

That's not something that someone learning programming should have to be
fussing about, but it will come up here (as it should) if anyone posts
code.  And of course, you don't always need the cast.  When do you?
It's not a question I'd have wanted to answer in programming 101 class.

One of the key ideas in programming is orthogonality -- roughly the idea
that separate concepts don't interact in unexpected ways.  The better a
language is at manifesting this idea, the fewer the restrictions there
are on how you organise your programs.  But in C, there are lots of
entangled notions.  You can't pass an array to a function like you pass
almost any other value.  You can't return a function from a function.
You can't define functions in the same places you can define other
things.  Some arrays can be initialised with {...} notation and others
can't be.  The list goes on and on.

These details can get in the way of learning the other skills -- how to
organise a program.  Of course you eventually need both, but it's way
more complicated than it needs to be to lean them at the same time.
(All programming languages have restrictions, constraints and odd
quirks, or course, but only the most obsessive would deny that C has
acquired more than it's share of them over the years).

Writing bullet-proof C is not easy.  You need to know lots of little
details, and, in general, the result will be "fussier" than the
equivalent in a more modern language.  This is, therefore, a huge and
understandable temptation to simplify things to get going with the
programming, but this inevitably runs the risk of teaching bad C
programming, or at least sub-optimal C programming.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#75808

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Alla _ <modelling.data@gmail.com> writes:
 
(snip)
>> May I ask for an advice on a book that teaches professional coding and 
>> helps to develop correct coding principles, unlike Kochan's one?
 
> I'm a bit out of date so I can't suggest any current books, but there is
> a fundamental problem with trying to do what Kochan is trying to do.
> He's trying to teach the basic concepts about procedural programming --
> how to use variables, assignments, input/output, loops, functions and so
> on to achieve some desired end result -- whist using C to do it.

Seems to me that this is true of any book and any language.

You have to start somewhere, when you haven't yet taught all
you need to know.

In the case of Java, and presumably other object oriented languages,
there is the 'objects first' and 'objects last' way of teaching.

For those with no previous programming experience, it might be
that objects last, which starts teaching static methods first,
as one would teach a non-OO language. Then, after one has a good
understanding of data types, expressions, and writing static 
methods, teach instance methods. Note that you can't completely
write using static methods, as you likely need to do simple I/O
pretty early.
 
> Take one tiny point: testing if a character is "printable".  There's a C
> function for that: isprint.  Now you may be able to skip the idea that
> it's possibly macro as well, but "professional coding" requires a cast
> of the argument in many cases:
 
>  if (isprint((unsigned char)ch)) ...
 
> That's not something that someone learning programming should have to be
> fussing about, but it will come up here (as it should) if anyone posts
> code.  And of course, you don't always need the cast.  When do you?
> It's not a question I'd have wanted to answer in programming 101 class.

You can either say 'do this and we will explain it later', or do
it some other way, until later.
 
> One of the key ideas in programming is orthogonality -- roughly the idea
> that separate concepts don't interact in unexpected ways.  The better a
> language is at manifesting this idea, the fewer the restrictions there
> are on how you organise your programs.  But in C, there are lots of
> entangled notions.  You can't pass an array to a function like you pass
> almost any other value.  You can't return a function from a function.
> You can't define functions in the same places you can define other
> things.  Some arrays can be initialised with {...} notation and others
> can't be.  The list goes on and on.

Some of those obviously can't work, and others you just have to
wait and learn later.
 
> These details can get in the way of learning the other skills -- how to
> organise a program.  Of course you eventually need both, but it's way
> more complicated than it needs to be to lean them at the same time.
> (All programming languages have restrictions, constraints and odd
> quirks, or course, but only the most obsessive would deny that C has
> acquired more than it's share of them over the years).

Some languages are less orthogonal for historic reasons. Fortran
has a lot left over still from the early days, though many have been
fixed in later updates.
 
> Writing bullet-proof C is not easy.  You need to know lots of little
> details, and, in general, the result will be "fussier" than the
> equivalent in a more modern language.  This is, therefore, a huge and
> understandable temptation to simplify things to get going with the
> programming, but this inevitably runs the risk of teaching bad C
> programming, or at least sub-optimal C programming.

Yes, but again this happens in any language.  You teach enough things
as 'do it this way, you will learn why later'. 

Even more, it happens in other subjects.  You have to have some
order for teaching concepts, even if you need others to understand
them.

It is especially interesting to consider, for example in physics or
math, things that are taught in a different order than they were
historically learned.
 
<snip>

-- glen

[toc] | [prev] | [next] | [standalone]

#75812

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>  
> (snip)
>>> May I ask for an advice on a book that teaches professional coding and 
>>> helps to develop correct coding principles, unlike Kochan's one?
>  
>> I'm a bit out of date so I can't suggest any current books, but there is
>> a fundamental problem with trying to do what Kochan is trying to do.
>> He's trying to teach the basic concepts about procedural programming --
>> how to use variables, assignments, input/output, loops, functions and so
>> on to achieve some desired end result -- whist using C to do it.
>
> Seems to me that this is true of any book and any language.

Yes, that's true.  Maybe I should have swapped paragraphs, because the
issue is how particularly fiddly C is in this respect.  You always have
to teach programming whilst teaching a language to do it in, it's just
that C is an odd choice for that.

> You have to start somewhere, when you haven't yet taught all
> you need to know.
>
> In the case of Java, and presumably other object oriented languages,
> there is the 'objects first' and 'objects last' way of teaching.
>
> For those with no previous programming experience, it might be
> that objects last, which starts teaching static methods first,
> as one would teach a non-OO language. Then, after one has a good
> understanding of data types, expressions, and writing static 
> methods, teach instance methods. Note that you can't completely
> write using static methods, as you likely need to do simple I/O
> pretty early.
>  
>> Take one tiny point: testing if a character is "printable".  There's a C
>> function for that: isprint.  Now you may be able to skip the idea that
>> it's possibly macro as well, but "professional coding" requires a cast
>> of the argument in many cases:
>  
>>  if (isprint((unsigned char)ch)) ...
>  
>> That's not something that someone learning programming should have to be
>> fussing about, but it will come up here (as it should) if anyone posts
>> code.  And of course, you don't always need the cast.  When do you?
>> It's not a question I'd have wanted to answer in programming 101 class.
>
> You can either say 'do this and we will explain it later', or do
> it some other way, until later.

Yes, you can.  Again and again.  It just about works with very careful
choice of exercises and examples and you hope that the inventive joy of
programming is not lost in all that "just do it this way".

>> One of the key ideas in programming is orthogonality -- roughly the idea
>> that separate concepts don't interact in unexpected ways.  The better a
>> language is at manifesting this idea, the fewer the restrictions there
>> are on how you organise your programs.  But in C, there are lots of
>> entangled notions.  You can't pass an array to a function like you pass
>> almost any other value.  You can't return a function from a function.
>> You can't define functions in the same places you can define other
>> things.  Some arrays can be initialised with {...} notation and others
>> can't be.  The list goes on and on.
>
> Some of those obviously can't work, and others you just have to
> wait and learn later.

I don't get your point here.  You can't be saying that these
entanglements are a good thing, so presumably it's you opinion that they
don't matter much when teaching programming.  I don't think that's the
case.

>> These details can get in the way of learning the other skills -- how to
>> organise a program.  Of course you eventually need both, but it's way
>> more complicated than it needs to be to lean them at the same time.
>> (All programming languages have restrictions, constraints and odd
>> quirks, or course, but only the most obsessive would deny that C has
>> acquired more than it's share of them over the years).
>
> Some languages are less orthogonal for historic reasons. Fortran
> has a lot left over still from the early days, though many have been
> fixed in later updates.
>  
>> Writing bullet-proof C is not easy.  You need to know lots of little
>> details, and, in general, the result will be "fussier" than the
>> equivalent in a more modern language.  This is, therefore, a huge and
>> understandable temptation to simplify things to get going with the
>> programming, but this inevitably runs the risk of teaching bad C
>> programming, or at least sub-optimal C programming.
>
> Yes, but again this happens in any language.  You teach enough things
> as 'do it this way, you will learn why later'.

It happens more in C.  Do you think that because there is inevitably
some differed discussion of details, all languages are equally suitable
as a first language to learn?

What's more, in C you teach "do it this way and you'll find out why
later, and even latter you'll find out you don't need to do it all all
in other languages".

> Even more, it happens in other subjects.  You have to have some
> order for teaching concepts, even if you need others to understand
> them.
>
> It is especially interesting to consider, for example in physics or
> math, things that are taught in a different order than they were
> historically learned.

I disagree about this -- I don't see anything analogous.  There are few
subjects where the mechanism can get in the way so fundamentally.  You
need to teach some maths as you teach physics, and there will be places
where you need to defer some details, but you don't have to keep
explaining why the maths can't describe what's really going on.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#75758

On 11/11/15 08:28, Alla _ wrote:
>
>> Does the author acknowledge the problems with this read_line() function?
>> Does he provide a safer alternative later?
>
> I don't recall him doing so.
>
> May I ask for an advice on a book that teaches professional coding and
> helps to develop correct coding principles, unlike Kochan's one?

Deitel & Deitel is fairly good. So is Harbison & Steele.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#75771

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 11/11/15 08:28, Alla _ wrote:
>>> Does the author acknowledge the problems with this read_line() function?
>>> Does he provide a safer alternative later?
>>
>> I don't recall him doing so.
>>
>> May I ask for an advice on a book that teaches professional coding and
>> helps to develop correct coding principles, unlike Kochan's one?
>
> Deitel & Deitel is fairly good. So is Harbison & Steele.

Harbison & Steele is more of a reference than a tutorial.

K&R2 is widely praised.

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

[toc] | [prev] | [next] | [standalone]

#75775

On 11/11/15 16:53, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 11/11/15 08:28, Alla _ wrote:
>>>
>>> May I ask for an advice on a book that teaches professional coding and
>>> helps to develop correct coding principles, unlike Kochan's one?
>>
>> Deitel & Deitel is fairly good. So is Harbison & Steele.
>
> Harbison & Steele is more of a reference than a tutorial.

So it is. If I'd bothered to write the title instead of lazily writing 
just the authors' names, I'd have worked that out for myself.

> K&R2 is widely praised.

I think I've heard of that one.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#75744

Well, I got a reply in Objective-C group about the only program that generally
presents Objective-C methods, which I got from the same Kochan's textbook. 

I won't quote exact words because I believe it would be not ethically correct
if I do so, but, given my trust in opinion I get from people here and also
at Objective-C group (got only one for now), I just mention that a person has 
completely crashed the Kochan because of his incompetence based on the code
I posted. 
How come? Why cs50 suggests that book? 
Why in the world this guy is popular? 
Rhetorical questions.  

[toc] | [prev] | [next] | [standalone]

#75661

On 11/10/2015 12:29 PM, Keith Thompson wrote:
> [...]
>      char line[81];
>      if (fgets(line, sizeof line, stdin) == NULL) {
>          /* end-of-file or error; call feof(stdin) or ferror(stdin)
>             to find out which */
>      }
>      else {
>          const size_t len = strlen(line);
>          if (line[len-1] == '\n') {
>              line[len-1] = '\0';
>          }

Or

	line[strcspn(line, "\n")] = '\0';

>      }

	"Thou shalt study thy libraries and strive not to reinvent them
	without cause, that thy code may be short and readable and thy
	days pleasant and productive." -- The Seventh Commandment

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#75652

On Tue, 10 Nov 2015 09:07:29 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

><snip>
>
>Here is the read_line() function:
>void read_line (char buffer [])
>{
>    char character;
>    int i = 0;
>    
>    do
>    {
>        character = getchar();
>        buffer[i] = character;
>        i++;
>    }
>    while (character != '\n');
>    
>    buffer[i - 1] = '\0'; 
>}
>
>It terminates when the '\n' is entered. 

 Among the problems others have identified, if the user somehow
signals end of file or if there is any error in acquiring the next
input character, the variable character will never be set to '\n', the
loop will run forever, and the function will never return.

There is a reason getchar() returns an int and not a char.  Why did
you choose to violate that interface?

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#75484

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.

[toc] | [prev] | [next] | [standalone]

#75487

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"

[toc] | [prev] | [next] | [standalone]

#75561

Keith Thompson wrote:
> 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"

Your explanation is all clear and correct except for the typo
in the second bit of code above. It should be either

    while (!end_of_text != 0)

or

    while (end_of_text == 0)

[toc] | [prev] | [next] | [standalone]

#75497

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

I don't see how you think I said that!  It means exactly the opposite.
All of these are the same in your example program (except for some of
them being bad style):

  while (!end_of_text) ...
  while (!end_of_text == 1) ...
  while (!end_of_text != 0) ...
  while (end_of_text == 0) ...
  while (end_of_text != 1) ...

> Hence, when the loop is first encountered, the controlling expression of 
> end_of_text is 1 (!end_of_text).

There some deep misunderstanding here.  The controlling expression of
the while loop is

  !end_of_text

and the phrase "the controlling expression of end_of_text is 1" does not
make any sense to me.

You seem to be happier with 'if' statements so, at the risk of confusing
you more, the while loop is really doing this:

  loop:
    if (!end_of_text) {
        read_line(text);
        
        if (text[0] == '\0')
            end_of_text = true;
        else
            total_words += count_words (text);

        goto loop;
    }

If this baffles you, just bin the message and ignore anything else I say.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#75500

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 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)".
>
> I don't see how you think I said that!  It means exactly the opposite.
> All of these are the same in your example program (except for some of
> them being bad style):
>
>   while (!end_of_text) ...
>   while (!end_of_text == 1) ...
>   while (!end_of_text != 0) ...
>   while (end_of_text == 0) ...
>   while (end_of_text != 1) ...

That last one is equivalent to the others only because end_of_text never
takes on a value other than 0 or 1.  If end_of_text could have the value
2 or -1, for example, it would behave differently.

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

[toc] | [prev] | [next] | [standalone]

#75556

You lost me here )) I am confused. I admit I have not 
expressed my question correctly, therefore I will do my best
to do it properly a bit later today. A short note: I do clearly
understand what "!" means, and my question was not about this 
operand. I do understand that I come across as completely
silly human being, but I am not that complete in my stupidity, 
although I won't deny that the degree of it is huge )))

[toc] | [prev] | [next] | [standalone]

#75557 — Re: Shortened condition

On 10/11/15 08:33, Alla _ wrote:
> You lost me here )) I am confused.

Yes. :-)  You are replying to your own article, so the implication is 
that you lost yourself.

What is it that is confusing you? You have not provided any context, so 
it is impossible to answer your question in detail.

But I can guess that you are confused by code like:

loop_termination_condition = 0;

while(! loop_termination_condition)
{
   do_stuff();
   if(something)
   {
     loop_termination_condition = 1;
   }
}

The while loop evaluates the expression within parentheses, and compares 
the result to 0. If the result *is* 0, the loop body does not execute, 
and the loop terminates.

In this situation (the code above), the expression is ! (not) 
loop_termination_condition. ! determines whether its operand is true 
(non-0) or false (0). If the operand is true, well, NOT true is false, 
so ! yields a result of 0. If the operand is false, well, NOT false is 
true, so ! yields a result of 1.

In this case, loop_termination_condition is 0 (false), so ! (NOT) 
loop_termination_condition is !0 = NOT false = true = 1, so while's 
expression evaluates to 1, so the loop continues.

At some point, presumably, loop_termination_condition is set to 1. When 
that happens... well, next time while() evaluates its expression... the 
! operator is handed a value of 1, so it yields a result of 0 (false) 
for while() to chew on. The while construct will see the 0 result and 
halt the loop.

I hope that's clearer now. But PLEASE provide enough context to your 
questions so that we don't have to guess. Thanks.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#75703

Alla _ <modelling.data@gmail.com> writes:

> [snip]
>
> int main (void)
> {
>     char text[81];
>     int total_words = 0;
>     bool end_of_text = false;
>
>     printf ("Type in your text.\n");
>     printf ("When done, press 'RETURN'.\n\n");
>
>     while ( !end_of_text ) 
>     {
>         read_line (text);
>
>         if (text[0] == '\0')
>             end_of_text = true;
>
>         else
>             total_words += count_words (text);
>     }
>
>     printf ("\nThere are %i words in the above text.\n", total_words);
>
>     return 0;
>
> }
> 
> I have an issue with the shorted form of condition in while
> statement.  [snip]

Note that you can sidestep the difficulties and also simplify
the code by writing the loop differently (and getting rid of
that confusing variable in the process):

    int main (void)
    {
        char text[81];
        int total_words = 0;

        printf ("Type in your text.\n");
        printf ("When done, press 'RETURN'.\n\n");

        while (  read_line (text),  text[0] != '\0'  ) 
        {
            total_words += count_words (text);
        }

        printf ("\nThere are %i words in the above text.\n", total_words);

        return 0;

    }

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web