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

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

Re: while loop vs do while loop reading from the file issue

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:27 -0800
    Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:41 -0800
      Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 13:57 -0800
        Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2016-12-29 22:55 +0000
          Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2016-12-29 15:34 -0800
      Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:51 -0800

#100492 — Re: while loop vs do while loop reading from the file issue

supercat@casperkitty.com writes:

> On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
>> Now I had thought that the C while was robust to creating non-
>> structured programs.  But I think now it is not.  But it's not quite
>> clear to me which rule you are breaking and why.
>
> Conditional tests aren't allowed to have side-effects in the traditional
> pattern, [...]

Wrong.

[toc] | [next] | [standalone]

#100503

On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote:
> supercat@casperkitty.com writes:
> 
> > On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
> >> Now I had thought that the C while was robust to creating non-
> >> structured programs.  But I think now it is not.  But it's not quite
> >> clear to me which rule you are breaking and why.
> >
> > Conditional tests aren't allowed to have side-effects in the traditional
> > pattern, [...]
> 
> Wrong.
>
I don't think so. We have boxes which do something, and control always 
enters at the top and comes out at the bottom, and in the box we have
a bit of text saying what the box does. Now of course we can expand
most boxes, unless that box is a single machine instruction. Then
we also have diamonds. Control does not always enter from the top,
it can also enter from the spare vertex, and there are two (always 
exactly two) control paths out. On the diamond we write the conditions
of the test. But I'm not sure we can expand the diamonds, I think that
is disallowed. Certainly, if we expand the diamonds, we've lost a
primary property, because whilst the block has one point of entry
and of exit, a diamond has two points of exit and possibly two points 
of entry. So a diamond is not a sub-program.

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

#100517

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote:
>> supercat@casperkitty.com writes:
>> > On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
>> >> Now I had thought that the C while was robust to creating non-
>> >> structured programs.  But I think now it is not.  But it's not quite
>> >> clear to me which rule you are breaking and why.
>> >
>> > Conditional tests aren't allowed to have side-effects in the traditional
>> > pattern, [...]
>> 
>> Wrong.
>>
> I don't think so. We have boxes which do something, and control always 
> enters at the top and comes out at the bottom, and in the box we have
> a bit of text saying what the box does. Now of course we can expand
> most boxes, unless that box is a single machine instruction. Then
> we also have diamonds. Control does not always enter from the top,
> it can also enter from the spare vertex, and there are two (always 
> exactly two) control paths out. On the diamond we write the conditions
> of the test. But I'm not sure we can expand the diamonds, I think that
> is disallowed.

Disallowed by what or whom?

>                Certainly, if we expand the diamonds, we've lost a
> primary property, because whilst the block has one point of entry
> and of exit, a diamond has two points of exit and possibly two points 
> of entry. So a diamond is not a sub-program.

You are describing what *you* think of as structured programming, but
you're providing no basis for your claims about it.

Tim cited a source, Dijkstra's "Notes on Structured Programming".
What's your source?  If you have none, perhaps you could call it
Malcolm-structured programming to avoid confusion.

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

#100551

Keith Thompson <kst-u@mib.org> writes:

> You are describing what *you* think of as structured programming, but
> you're providing no basis for your claims about it.
>
> Tim cited a source, Dijkstra's "Notes on Structured Programming".
> What's your source?  If you have none, perhaps you could call it
> Malcolm-structured programming to avoid confusion.

Remember when this used to be a C language newsgroup?

Good times.

Do Not Feed The .... Whatever the Hell Malcolm Is.

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

#100570

Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> You are describing what *you* think of as structured programming, but
>> you're providing no basis for your claims about it.
>>
>> Tim cited a source, Dijkstra's "Notes on Structured Programming".
>> What's your source?  If you have none, perhaps you could call it
>> Malcolm-structured programming to avoid confusion.
>
> Remember when this used to be a C language newsgroup?
>
> Good times.
>
> Do Not Feed The .... Whatever the Hell Malcolm Is.

Point taken -- but in this case Malcolm is actually talking about C
programming, such as the common C idiom of conditions with side effects.

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

#101595

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, December 29, 2016 at 9:27:16 PM UTC, Tim Rentsch wrote:
>> supercat@casperkitty.com writes:
>>
>>> On Friday, December 16, 2016 at 4:19:41 PM UTC-6, Malcolm McLean wrote:
>>>> Now I had thought that the C while was robust to creating non-
>>>> structured programs.  But I think now it is not.  But it's not quite
>>>> clear to me which rule you are breaking and why.
>>>
>>> Conditional tests aren't allowed to have side-effects in the
>>> traditional pattern, [...]
>>
>> Wrong.
>
> I don't think so.  We have boxes which do something, and control
> always enters at the top and comes out at the bottom, [...]

Yes, I know you have your own ideas about what certain words
mean.  My response is in reference to "the traditional pattern",
which for structured programming may reasonably be taken as
Dijkstra's monograph on the subject.  That discussion admits
the possibility that tests in if's and while's might have
side effects.

[toc] | [prev] | [standalone]

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

csiph-web