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

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

gcc needs a curly bracket matching/counting function

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

Contents

  gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 20:38 -0500
    Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 01:59 +0000
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 22:30 -0500
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 11:46 +0100
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 13:20 +0000
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 13:30 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 05:35 -0800
            Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:07 +0100
              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 12:46 +0000
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 15:10 +0100
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:10 +0000
                    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 19:50 +0100
                      Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 20:15 +0000
                        Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-21 22:36 +0000
                          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 23:46 +0000
                            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 01:54 +0000
                              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 12:16 +0000
                                Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 13:06 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 05:25 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 13:34 +0000
                                      Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:16 -0800
                                        Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-22 09:30 -0800
                                          Re: gcc needs a curly bracket matching/counting function luser droog <luser.droog@gmail.com> - 2016-12-22 09:40 -0800
                            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:33 -0800
                              Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:41 -0800
                                Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 14:53 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:11 -0800
                                  Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 08:27 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 16:48 +0000
                                      Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 09:27 -0800
                                        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 20:12 +0000
                                          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 12:18 -0800
                Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:04 -0800
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:24 +0000
                    Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:41 -0800
                    Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-22 18:10 +1300
                      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:50 +1300
                        Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:07 -0800
                          Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2017-01-02 11:16 +0100
                      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:40 -0800
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 08:52 -0800
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 20:16 +0100
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-22 09:41 +0100
        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:04 +0000
          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:46 +0000
            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 21:55 +0000
          Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:52 -0500
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:09 +0000
            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 19:14 +0000
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:16 -0800
                Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-20 20:53 +0000
                  Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 13:51 -0800
                    Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:49 +0000
                    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:36 -0800
                      Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-29 12:44 +0100
                Re: gcc needs a curly bracket matching/counting function bart4858@gmail.com - 2016-12-20 13:25 -0800
                  Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 13:39 -0800
                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 21:58 +0000
                      Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 14:05 -0800
                      Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 22:17 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:03 +0000
                      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 14:31 -0800
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 23:21 +0000
                          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 15:51 -0800
                            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 00:38 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:11 +0000
      Re: gcc needs a curly bracket matching/counting function mark.bluemel@gmail.com - 2016-12-20 00:50 -0800
    gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-19 18:11 -0800
      Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 03:00 -0800
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:50 -0800
          Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 05:20 -0800
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:46 -0500
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:59 +0000
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:02 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:13 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 20:25 +0000
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 20:35 +0100
    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-20 08:56 +0100
    Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:26 -0800
      Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 10:41 +0000
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:52 -0800
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:00 +0000
            Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:19 -0800
              Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:31 +0000
              Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:21 +0000
                Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:49 +0000
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:25 +0100
                  Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:14 -0800
      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:07 -0800
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:14 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:33 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:39 +0000
            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 09:45 -0800
        Re: gcc needs a curly bracket matching/counting function gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-20 17:56 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 10:01 -0800
      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-21 07:44 +1300
    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 10:46 +0000
    Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-20 22:00 +0000
      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:39 -0800
    Re: gcc needs a curly bracket matching/counting function Ken Brody <kenbrody@spamcop.net> - 2016-12-22 12:12 -0500
    Re: gcc needs a curly bracket matching/counting function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-22 12:59 -0700
    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:10 -0800

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#99900

On Tuesday, December 20, 2016 at 10:41:23 AM UTC, Richard Heathfield wrote:
> On 20/12/16 10:26, Malcolm McLean wrote:
>
> > Use i, ii, iii as loop
> > counter or i, j, k. If you need iv or l (which looks like a 1)
> > then consider breaking out into a subroutine.
> >
> > If code isn't human-understandable it is far less valuable.
> 
> Those two paragraphs contradict each other.
> 
i, j, k is a mathematical convention. I prefer i, ii, iii so I
can use j as a secondary counter rather than an inner one.
But I'm idiosyncratic there.

The names aren't meaningful outside the context of the function,
if that's what you mean. But since we only allow three levels of 
nesting, most functions will be quite short. The reader doesn't
get lost. 

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

#99901

On 20/12/16 10:52, Malcolm McLean wrote:
> On Tuesday, December 20, 2016 at 10:41:23 AM UTC, Richard Heathfield wrote:
>> On 20/12/16 10:26, Malcolm McLean wrote:
>>
>>> Use i, ii, iii as loop
>>> counter or i, j, k. If you need iv or l (which looks like a 1)
>>> then consider breaking out into a subroutine.
>>>
>>> If code isn't human-understandable it is far less valuable.
>>
>> Those two paragraphs contradict each other.
>>
> i, j, k is a mathematical convention. I prefer i, ii, iii so I
> can use j as a secondary counter rather than an inner one.
> But I'm idiosyncratic there.

Idiosyncrasies can be appropriate in some limited circumstances, but in 
general they make for code that is less readable, whereas you were 
touting this particular idiosyncrasy as if it made code /more/ readable. 
It doesn't.

> The names aren't meaningful outside the context of the function,

Or indeed within it.

> if that's what you mean. But since we only allow three levels of
> nesting,

Citation required.

> most functions will be quite short. The reader doesn't
> get lost.

Counter-examples abound. For example, consider a three-nested loop that 
iterates through a phase space (say: shelf number, aisle number, and 
warehouse number) searching for a particular tag number. Which phase 
space dimension is associated with which of i, ii, iii? Answer: you 
can't tell just by looking at the code.

So much for readable code.

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

#99904

On Tuesday, December 20, 2016 at 11:00:49 AM UTC, Richard Heathfield wrote:
> On 20/12/16 10:52, Malcolm McLean wrote:
> > On Tuesday, December 20, 2016 at 10:41:23 AM UTC, Richard Heathfield wrote:
> 
> > i, j, k is a mathematical convention. I prefer i, ii, iii so I
> > can use j as a secondary counter rather than an inner one.
> > But I'm idiosyncratic there.
> 
> Idiosyncrasies can be appropriate in some limited circumstances, but in 
> general they make for code that is less readable, whereas you were 
> touting this particular idiosyncrasy as if it made code /more/ readable. 
> It doesn't.
> 
My view is that i, ii, iii is more readable because it makes it
obvious that the Roman numeral represent levels of nesting. However
i, j, k is more common. So I wouldn't represent my own view as
something established, or for which there is a consensus.

Rule of three is established. The clue is that after k comes l,
and programmers who use i,j,k are understandably reluctant to
go up to l. I formalised the rule of three and called it "the
rule of three" but I didn't just invent it. It's a commonplace
that functions and expressions shouldn't be allowed to go over
a certain level of complexity.

> > The names aren't meaningful outside the context of the function,
> 
> Or indeed within it.
> 
> Counter-examples abound. For example, consider a three-nested loop that 
> iterates through a phase space (say: shelf number, aisle number, and 
> warehouse number) searching for a particular tag number. Which phase 
> space dimension is associated with which of i, ii, iii? Answer: you 
> can't tell just by looking at the code.
> 
> So much for readable code.
> 

typedef struct
{
   char barcode[32];
   int N;
} ITEM:

typedef struct
{
   ITEM *items;
   int Nitems;
} SHELF;

typedef struct
{
   SHELF *shelf;
   int Nshelves;
} AISLE;

typedef struct
{
    AIsle *aisle;
   int Naisles;
} WAREHPUSE;

/*
   count the number of items we have in our warehouse;
*/
int countitems(WAREHOUSE *wh, char *barcode)
{
   int i, ii, iii;
   int answer = 0;

   for(i=0;i<wh->Naisles;i++)
     for(ii=0;ii<wh->aisle[i].Nshelves;ii++)
       for(iii=0;iii<wh->aisle[i]->shelf[ii].Nitems;iii++)
         if(!strcmp(wh->aisle[i]->shelf[ii]->item[iii].barcode, barcode))
           answer += wh->aisle[i]->shelf[ii]->item[ii].N;
  
    return answer;
}

/*
   Count the number of items we have in our warehouse system
*/

int countitems_insystem(WAREHOUSE *wh, int Nwarehouses, char *barcode)
{
   int answer = 0;
   int i;

   for(i=0;i<Nwarehouses;i++)
     answer += countitems(&wh[i], barcode);

   return answer;
}

Going through the entire system would entail four nested loops. So
one is broken out. As is another with the strcmp().

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

#99906

On 20/12/16 11:19, Malcolm McLean wrote:
> On Tuesday, December 20, 2016 at 11:00:49 AM UTC, Richard Heathfield wrote:
>> On 20/12/16 10:52, Malcolm McLean wrote:
>>> On Tuesday, December 20, 2016 at 10:41:23 AM UTC, Richard Heathfield wrote:
>>
>>> i, j, k is a mathematical convention. I prefer i, ii, iii so I
>>> can use j as a secondary counter rather than an inner one.
>>> But I'm idiosyncratic there.
>>
>> Idiosyncrasies can be appropriate in some limited circumstances, but in
>> general they make for code that is less readable, whereas you were
>> touting this particular idiosyncrasy as if it made code /more/ readable.
>> It doesn't.
>>
> My view is that i, ii, iii is more readable because it makes it
> obvious that the Roman numeral represent levels of nesting.

Far better would be to choose identifiers that identify the /meaning/ of 
the nesting.

> However
> i, j, k is more common. So I wouldn't represent my own view as
> something established, or for which there is a consensus.

(a) No, meaningful names are more common --- i, j, k are used in very 
limited circumstances.
(b) You touted your view as being an established view, and now you say 
(quite rightly) that it isn't. It would have been better not to claim it 
in the first place, of course.

> Rule of three is established.

Citation required.

> The clue is that after k comes l,

How is that better than saying what k and l actually mean?

> and programmers who use i,j,k are understandably reluctant to
> go up to l.

Programmers who use meaningful names are understandably reluctant to go 
up to j. I do sometimes use i, but only when there is no possibility 
whatsoever that it could ever, ever mean more than one thing. I use j 
very rarely indeed. In fact, if I get as far as j, I find myself 
thinking that more meaningful names would be sensible.

> I formalised the rule of three and called it "the
> rule of three" but I didn't just invent it. It's a commonplace
> that functions and expressions shouldn't be allowed to go over
> a certain level of complexity.

Citation required.

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

#99916

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

> On Tuesday, December 20, 2016 at 11:00:49 AM UTC, Richard Heathfield wrote:
>> On 20/12/16 10:52, Malcolm McLean wrote:
>> > On Tuesday, December 20, 2016 at 10:41:23 AM UTC, Richard Heathfield wrote:
>> 
>> > i, j, k is a mathematical convention. I prefer i, ii, iii so I
>> > can use j as a secondary counter rather than an inner one.
>> > But I'm idiosyncratic there.
>> 
>> Idiosyncrasies can be appropriate in some limited circumstances, but in 
>> general they make for code that is less readable, whereas you were 
>> touting this particular idiosyncrasy as if it made code /more/ readable. 
>> It doesn't.
>> 
> My view is that i, ii, iii is more readable because it makes it
> obvious that the Roman numeral represent levels of nesting.
<snip>

> int countitems(WAREHOUSE *wh, char *barcode)
> {
>    int i, ii, iii;
>    int answer = 0;
>
>    for(i=0;i<wh->Naisles;i++)
>      for(ii=0;ii<wh->aisle[i].Nshelves;ii++)
>        for(iii=0;iii<wh->aisle[i]->shelf[ii].Nitems;iii++)
>          if(!strcmp(wh->aisle[i]->shelf[ii]->item[iii].barcode, barcode))
>            answer += wh->aisle[i]->shelf[ii]->item[ii].N;
>   
>     return answer;
> }

It's interesting that you have exactly the kind of bug I would expect to
see in this sort of code.  With Richard's more meaningful names I don't
think you'd have made it.

And what happened to the rule of three?  Are saying that omitting the
{}s round single-statement block actually makes the code clearer so
blocks may be more deeply nested?  If so, what's the number in the rule
for these things?

<snip>
-- 
Ben.

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

#99920

On 20/12/16 17:21, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
<snip>

>>    int i, ii, iii;
>>    int answer = 0;
>>
>>    for(i=0;i<wh->Naisles;i++)
>>      for(ii=0;ii<wh->aisle[i].Nshelves;ii++)
>>        for(iii=0;iii<wh->aisle[i]->shelf[ii].Nitems;iii++)
>>          if(!strcmp(wh->aisle[i]->shelf[ii]->item[iii].barcode, barcode))
>>            answer += wh->aisle[i]->shelf[ii]->item[ii].N;
>>
>>     return answer;
>> }
>
> It's interesting that you have exactly the kind of bug I would expect to
> see in this sort of code.

Sharp eyes indeed. (In case other people haven't spotted it, look 
carefully at the most deeply nested statement. I didn't see it either 
until Ben mentioned that there was a bug to find.)

> With Richard's more meaningful names I don't
> think you'd have made it.

Or at least the rest of us would have had a fighting chance of spotting it.

>
> And what happened to the rule of three?

Clearly he isn't bound by it any more than anyone else is.

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

#99978

On 20/12/16 18:49, Richard Heathfield wrote:
> On 20/12/16 17:21, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
> <snip>
> 
>>>    int i, ii, iii;
>>>    int answer = 0;
>>>
>>>    for(i=0;i<wh->Naisles;i++)
>>>      for(ii=0;ii<wh->aisle[i].Nshelves;ii++)
>>>        for(iii=0;iii<wh->aisle[i]->shelf[ii].Nitems;iii++)
>>>          if(!strcmp(wh->aisle[i]->shelf[ii]->item[iii].barcode,
>>> barcode))
>>>            answer += wh->aisle[i]->shelf[ii]->item[ii].N;
>>>
>>>     return answer;
>>> }
>>
>> It's interesting that you have exactly the kind of bug I would expect to
>> see in this sort of code.
> 
> Sharp eyes indeed. (In case other people haven't spotted it, look
> carefully at the most deeply nested statement. I didn't see it either
> until Ben mentioned that there was a bug to find.)

Nor did I.

How is it possible for someone to talk about "making code more
readable", without knowing how to use the biggest key on the keyboard.

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

#100538

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 20/12/16 17:21, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> <snip>
>
>>>    int i, ii, iii;
>>>    int answer = 0;
>>>
>>>    for(i=0;i<wh->Naisles;i++)
>>>      for(ii=0;ii<wh->aisle[i].Nshelves;ii++)
>>>        for(iii=0;iii<wh->aisle[i]->shelf[ii].Nitems;iii++)
>>>          if(!strcmp(wh->aisle[i]->shelf[ii]->item[iii].barcode, barcode))
>>>            answer += wh->aisle[i]->shelf[ii]->item[ii].N;
>>>
>>>     return answer;
>>> }
>>
>> It's interesting that you have exactly the kind of bug I would expect to
>> see in this sort of code.
>
> Sharp eyes indeed.  [...]

I don't need to see the bug to know that the code
fails a code review.

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

#99914

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Rule of three.
>
> Parentheses may have only three levels of nesting.

Balderdash.

[...]

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

#99915

On 20/12/16 17:07, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Rule of three.
>>
>> Parentheses may have only three levels of nesting.
>
> Balderdash.

Citation required.

But hang on, I think I have one here:

5.2.4.1 Translation limits: "63 nesting levels of parenthesized 
expressions within a full expression".

(That's a minimal maximum.)

And of course we were originally talking about braces. From the same 
paragraph: "127 nesting levels of blocks".

(Again, that's a minimal maximum.)

Hypothesis confirmed. Malcolm is indeed talking balderdash.

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

#99917

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/12/16 17:07, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Rule of three.
>>>
>>> Parentheses may have only three levels of nesting.
>>
>> Balderdash.
>
> Citation required.
>
> But hang on, I think I have one here:
>
> 5.2.4.1 Translation limits: "63 nesting levels of parenthesized 
> expressions within a full expression".
[...]
> Hypothesis confirmed. Malcolm is indeed talking balderdash.

To be fair, it's pretty clear that Malcolm wasn't claiming that
the language forbids more than 3 levels of nesting.  His claim is
about some rule outside the language standard, presumably some kind
of stylistic rule.  (Sorry if I'm spoiling the joke.)

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

#99918

On 20/12/16 17:33, Keith Thompson wrote:
> (Sorry if I'm spoiling the joke.)

That's okay. I've been on Usenet for a while now, so I'm used to it.

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

#99919

On Tuesday, December 20, 2016 at 12:33:42 PM UTC-5, Keith Thompson wrote:
> To be fair, it's pretty clear that Malcolm wasn't claiming that
> the language forbids more than 3 levels of nesting.  His claim is
> about some rule outside the language standard, presumably some kind
> of stylistic rule.  (Sorry if I'm spoiling the joke.)

It was evident to everyone.  Well ... almost everyone.  Alright.  I
was evident a preponderance of the people involved.  A weighty heft
of understanding against the frail few of misunderstanding.  Yes.
That is at least close to what it was like.

(Note:  This comes from the man who totally missed Jacob Navia's
subtle humor/sarcasm the other day, and in so doing metaphorically
fell from the sky in a grand display of flames, smoke and periodic
ejectiles, before, again metaphorically, crashing and burning
amongst the rocky outcroppings below ... a metaphorical disaster.)

Yes, I metaphor.  (Can you use "metaphor" as a verb?  Oh well...)
Enjoy the day.  (I wonder how you say that in Latin?  Not "that," but
rather "Enjoy the day."  You understand.  Do you?  Oh well...)

Best regards,
Rick C. Hodgin

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

#99921

In article <lnfulih6lo.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>[...]
>> Rule of three.
>>
>> Parentheses may have only three levels of nesting.
>
>Balderdash.

If Malcolm was your boss, you wouldn't say that.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

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

#99922

On Tuesday, December 20, 2016 at 12:56:57 PM UTC-5, Kenny McCormack wrote:
> In article <lnfulih6lo.fsf@kst-u.example.com>,
> Keith Thompson  <kst-u@mib.org> wrote:
> >Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >[...]
> >> Rule of three.
> >>
> >> Parentheses may have only three levels of nesting.
> >
> >Balderdash.
> 
> If Malcolm was your boss, you wouldn't say that.

Unless .... unless he was switching topics and suggesting (in that
admittedly awkward moment) that they should now begin playing a
recreational game:

    https://images-na.ssl-images-amazon.com/images/I/51678WW56PL.jpg

Then it might be completely appropriate.  Or not.  I don't know. I'd
need some more details of the situation to make a completely solid
analysis other people could rely upon.  I'd say at least a half an
hour of unrestricted access to the players involved so as to question
them under direct inquiry.  And when I say, "players," I don't mean
the people who ultimately may or may not have wound up playing the
Balderdash game, but rather those people who were involved in the
initial discussion which used the word "Balderdash," as indicated
above.

Best regards,
Rick C. Hodgin

PS - There are some people who appreciate my humor.  At least, that's
     what I remember seeing that night in the dream. :-)  Oh well...

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

#99923

On 12/20/16 11:26 PM, Malcolm McLean wrote:
>>
> Rule of three.
>
> Parentheses may have only three levels of nesting.

Why?

> Use of goto for error-handling flow control helps.

..you write spaghetti code.

If you choose to restrict nesting, extract code the would be in an inner 
loop to a function.

> Use i, ii, iii as loop
> counter or i, j, k. If you need iv or l (which looks like a 1)
> then consider breaking out into a subroutine.

This suggestion is horrible: use meaningful names for loop counters as 
you should for any variable.

> If code isn't human-understandable it is far less valuable.

It wont be human-understandable if you follow your suggestions!

-- 
Ian

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

#99899

On 20/12/2016 01:38, DFS wrote:
> This would potentially help a lot.
>
> I had ONE extraneous closing curly bracket } in place in a function, and
> gcc -Wall threw 60+ warnings and errors.
>
> Took me several minutes to find it, and once it was removed I got a 100%
> clean compile
>
> A simple "error: mismatch in opening and closing curly brackets" would
> be nice.

Get hold of a few other compilers and use them when stumped on an error 
message.

gcc has a particular problem with this, as it allows nested functions. 
So a missing } or extra { in a function near the start of a file, means 
it doesn't report an error until the end of the file thousand of lines 
and hundreds of functions later. But there should be a way of turning 
that off.

> Or is this a function that should be in the editor?

That too if it supports it. But that doesn't mean compilers don't need 
to bother with more useful diagnostics.

-- 
Bartc

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

#99941

On 2016-12-20, DFS <nospam@dfs.com> wrote:
> This would potentially help a lot.
>
> I had ONE extraneous closing curly bracket } in place in a function, and 
> gcc -Wall threw 60+ warnings and errors.
>
> Took me several minutes to find it, and once it was removed I got a 100% 
> clean compile

What's the problem? It took you a few minutes this time, and it
will probably take you a few seconds when it happens again because
you have learned from the previous experience.

It's surprising that (see elsethread) so much commotion is caused by
something as futile as an unmatched curly brace. 

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

#100612

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2016-12-20, DFS <nospam@dfs.com> wrote:
>> This would potentially help a lot.
>>
>> I had ONE extraneous closing curly bracket } in place in a function, and
>> gcc -Wall threw 60+ warnings and errors.
>>
>> Took me several minutes to find it, and once it was removed I got a 100%
>> clean compile
>
> What's the problem?  It took you a few minutes this time, and it
> will probably take you a few seconds when it happens again because
> you have learned from the previous experience.
>
> It's surprising that (see elsethread) so much commotion is caused by
> something as futile as an unmatched curly brace.

Wholeheartedly agree.  Software developers sometimes need to be
reminded not to overengineer their solutions.

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

#100041

On 12/19/2016 8:38 PM, DFS wrote:
> This would potentially help a lot.
>
> I had ONE extraneous closing curly bracket } in place in a function, and gcc
> -Wall threw 60+ warnings and errors.
>
> Took me several minutes to find it, and once it was removed I got a 100%
> clean compile
>
> A simple "error: mismatch in opening and closing curly brackets" would be nice.
>
>
> {
>  {
[...]
>  }
> }
>
>
> Or is this a function that should be in the editor?

Many editors have a keystroke to move the cursor to the matching brace. 
However, that only shows you the *actual* matching brace.  There is no way, 
in the general sense, to know where the extra/missing brace should go.

However, I do find the "show matching brace" feature of editors to be very 
useful in tracking down the missing/extra brace.  (Step 1 -- put the cursor 
on the open-brace of a function, press the key, and verify that it goes to 
the function's close brace.)

-- 
Kenneth Brody

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

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

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

csiph-web