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

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

Program to count words, issues with an if condition within a for loop

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

Contents

  Program to count words, issues with an if condition within a for loop Alla _ <modelling.data@gmail.com> - 2015-10-10 10:28 -0700
    Re: Program to count words, issues with an if condition within a for loop Stephen Fisher <sfisher@panix.com> - 2015-10-10 18:53 +0000
      Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-10 22:23 +0200
        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-10 23:13 +0200
      Re: Operating Systems in Teaching Bartc <bc@freeuk.com> - 2015-10-10 22:04 +0100
        Re: Operating Systems in Teaching Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 14:12 -0700
          Re: Operating Systems in Teaching Bartc <bc@freeuk.com> - 2015-10-10 22:30 +0100
        Re: Operating Systems in Teaching Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-10 18:25 -0400
        Re: Operating Systems in Teaching Bartc <bc@freeuk.com> - 2015-10-11 15:02 +0100
          Re: Operating Systems in Teaching Bartc <bc@freeuk.com> - 2015-10-11 16:39 +0100
          Re: Operating Systems in Teaching Melzzzzz <mel@zzzzz.com> - 2015-10-11 17:50 +0200
          Re: Operating Systems in Teaching "Osmium" <r124c4u102@comcast.net> - 2015-10-11 11:29 -0500
            Re: Operating Systems in Teaching "Osmium" <r124c4u102@comcast.net> - 2015-10-11 11:48 -0500
            Re: Operating Systems in Teaching Bartc <bc@freeuk.com> - 2015-10-11 18:18 +0100
              Re: Operating Systems in Teaching "Osmium" <r124c4u102@comcast.net> - 2015-10-11 12:46 -0500
                Re: Operating Systems in Teaching Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-11 13:57 -0400
    Re: Program to count words, issues with an if condition within a for loop Ian Collins <ian-news@hotmail.com> - 2015-10-11 10:21 +1300
      Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 14:55 -0700
        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 00:35 +0200
        Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 00:01 +0100
          Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 16:21 -0700
            Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 01:24 +0100
              Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 17:56 -0700
                Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 03:17 +0200
                  Re: Program to count words, issues with an if condition within a   for loop Ian Collins <ian-news@hotmail.com> - 2015-10-11 14:43 +1300
                  Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 00:19 -0700
                    Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 11:02 +0100
                      Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 03:47 -0700
                        Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 16:05 +0100
                        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 17:38 +0200
                          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 18:49 +0200
                            Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 12:37 -0700
                              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 21:56 +0200
                                Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 13:34 -0700
                                  Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-12 10:11 +0200
                              Re: Program to count words, issues with an if condition within a for loop Geoff <geoff@invalid.invalid> - 2015-10-11 12:59 -0700
                        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 19:15 +0200
                    Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 12:48 +0200
                      Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 03:59 -0700
                        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 13:30 +0200
                          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 14:19 +0200
                            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 14:48 +0200
                              Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 12:20 -0700
                        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 13:49 +0200
                          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 13:55 +0200
            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 02:40 +0200
        Re: Program to count words, issues with an if condition within a for loop Ian Collins <ian-news@hotmail.com> - 2015-10-11 14:40 +1300
    Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-10 22:29 +0100
      Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 00:22 +0200
        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 00:57 +0200
        Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 00:46 +0100
          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 02:23 +0200
            Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 01:28 +0100
              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 04:21 +0200
                Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 04:32 +0200
                Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-11 11:06 +0100
            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-11 02:55 +0200
            Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:36 -0700
              Re: Program to count words, issues with an if condition within a for loop Geoff <geoff@invalid.invalid> - 2015-10-15 14:37 -0700
      Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-10-11 10:15 +0000
        Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-12 10:37 +0200
          Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-12 11:08 +0200
            Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-14 16:27 +0200
              Re: Program to count words, issues with an if condition within a for loop Tonton Th <tTh@nowhere.invalid> - 2015-10-14 14:28 +0000
              Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-14 16:36 +0200
                Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-14 16:40 +0200
                Re: Program to count words, issues with an if condition within a for loop Rosario19 <Ros@invalid.invalid> - 2015-10-14 16:49 +0200
        Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 14:09 -0700
          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-16 12:49 +0200
            Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 14:28 -0700
              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 02:03 +0200
                Re: Program to count words, issues with an if condition within a   for loop Ian Collins <ian-news@hotmail.com> - 2015-10-20 13:13 +1300
                Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 20:07 -0700
                  Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 14:30 +0200
                    Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 15:08 +0200
                Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-24 12:18 -0700
              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 03:03 +0200
                Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-24 12:21 -0700
                  Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-25 15:16 +0100
                    Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-27 22:29 -0700
    Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-10-11 10:26 +0000
      Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-11 14:09 -0700
        Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:36 +0000
          Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-14 10:23 -0700
            Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-10-20 16:06 +0000
      Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-12 00:19 +0200
        Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-11 17:53 -0700
          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-12 04:15 +0200
    Re: Program to count words, issues with an if condition within a for loop Alla _ <modelling.data@gmail.com> - 2015-10-13 08:44 -0700
      Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-14 07:27 +0200
        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-14 08:53 +0200
          Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 11:13 +0100
            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-14 12:35 +0200
            Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:08 +0100
              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-14 18:11 +0200
      Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-16 04:58 -0700
        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-16 15:07 +0200
          Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-16 23:50 +0200
            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-17 00:06 +0200
              Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-16 15:30 -0700
          Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 13:45 -0700
            Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 02:40 +0200
              Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-24 12:47 -0700
                Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-25 15:36 +0100
                  Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-27 22:37 -0700
                Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-25 15:52 +0100
                  Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-25 19:10 +0100
                    Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-25 19:17 +0100
                    Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-27 23:05 -0700
                      Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-28 03:59 -0700
                        Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-29 14:04 +0100
                      Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-29 01:07 +0100
                        Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:31 -0700
                  Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-27 22:48 -0700
            Re: Program to count words, issues with an if condition within a for loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 08:55 +0000
              Re: Program to count words, issues with an if condition within a for loop regis <regis.barbanchon@free.fr> - 2015-10-20 13:52 +0200
              Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-24 14:04 -0700
                Re: Program to count words, issues with an if condition within a for loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-25 06:44 +0000
                  Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-10-25 09:09 +0000
                    Re: Program to count words, issues with an if condition within a for loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-25 10:12 +0000
                      Re: Program to count words, issues with an if condition within a for loop asetofsymbols@gmail.com - 2015-10-25 03:26 -0700
                        Re: Program to count words, issues with an if condition within a for loop Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-25 06:38 -0700
                          Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-25 15:23 +0000
                          Re: Program to count words, issues with an if condition within a for loop supercat@casperkitty.com - 2015-10-25 10:54 -0700
                            Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-25 12:21 -0700
                              Re: Program to count words, issues with an if condition within a for loop supercat@casperkitty.com - 2015-10-25 14:16 -0700
                                Re: Program to count words, issues with an if condition within a for loop Keith Thompson <kst-u@mib.org> - 2015-10-25 14:52 -0700
                            Re: Program to count words, issues with an if condition within a for loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 00:58 +0000
                              Re: Program to count words, issues with an if condition within a for loop Bartc <bc@freeuk.com> - 2015-10-26 11:50 +0000
                          Re: Program to count words, issues with an if condition within a for loop raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:17 +0000
                            Re: Program to count words, issues with an if condition within a for loop Les Cargill <lcargill99@comcast.com> - 2015-11-10 19:27 -0600
                              Re: Program to count words, issues with an if condition within a for loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-11 07:39 +0000
                                Re: Program to count words, issues with an if condition within a for loop Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:22 -0600
                            Re: Program to count words, issues with an if condition within a for loop Robert Wessel <robertwessel2@yahoo.com> - 2015-11-11 00:37 -0600
                  Re: Program to count words, issues with an if condition within a for loop Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 08:52 -0700
    Re: Program to count words, issues with an if condition within a for loop Barry Schwarz <schwarzb@dqel.com> - 2015-10-18 12:31 -0700
      Re: Program to count words, issues with an if condition within a for loop asetofsymbols@gmail.com - 2015-10-18 15:28 -0700
        Re: Program to count words, issues with an if condition within a for loop Ian Collins <ian-news@hotmail.com> - 2015-10-19 11:40 +1300
          Re: Program to count words, issues with an if condition within a for loop asetofsymbols@gmail.com - 2015-10-18 20:41 -0700
          Re: Program to count words, issues with an if condition within a for loop asetofsymbols@gmail.com - 2015-10-18 20:44 -0700

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

#72603

On Sun, 11 Oct 2015 10:15:10 GMT, (Richard Bos) wrote:
>Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>   int word_count = 0;
>>   for (int i = 0; string[i]; i++)
>>      word_count += alphabetic(string[i]) && !alphabetic(string[i+1]);
>>   return word_count;
>> 
>> Now about 99% of people here will consider this to be the most appalling
>> code!
>
>Not at all, I've seen much worse. This is only slightly appalling, and
>can easily be fixed like this:
>
>  int word_count = 0;
>
>  for (int i = 0; string[i]; i++)
>    if (alphabetic(string[i]) && !alphabetic(string[i+1])
>      word_count++;
>
>  return word_count;

there is one call of alphabetic(string[i+1]) more 
in the loop...

#define  F  for
u32  i, pc, p, WordCont;
// " aaa "   "a  aa"  "aa   aa"
//      *      *
WordCont=0;
F(i=0, pc=0; s[i]!=0; ++i)
   {p=alphabetic(s[i]);
    if(pc && !p ) ++WordCont;
    pc=p;
   }


>Add braces as you prefer (I might add them for the for loop, though in
>this case I probably wouldn't - for that, though, I'd _insist_ on the
>extra blank lines), and you have the perfect counter.
>
>Richard

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

#72605

On Mon, 12 Oct 2015 10:37:20 +0200, Rosario19 wrote:


>#define  F  for
>u32  i, pc, p, WordCont;
>// " aaa "   "a  aa"  "aa   aa"
>//      *      *
>WordCont=0;
>F(i=0, pc=0; s[i]!=0; ++i)
>   {p=alphabetic(s[i]);
>    if(pc && !p ) ++WordCont;
>    pc=p;
>   }

i forget:
if(pc) ++WordCont;

out the loop...

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

#72834

On Mon, 12 Oct 2015 11:08:44 +0200, Rosario19 wrote:
>>#define  F  for
>>u32  i, pc, p, WordCont;
>>// " aaa "   "a  aa"  "aa   aa"
>>//      *      *
>>WordCont=0;
>>F(i=0, pc=0; s[i]!=0; ++i)
>>   {p=alphabetic(s[i]);
>>    if(pc && !p ) ++WordCont;
>>    pc=p;
>>   }
>
>i forget:
>if(pc) ++WordCont;
>
>out the loop...

#define  F  for
#defome  R  return

u32  WordCount(u8*  s)
{u32  i, pc, p, c, k;
// " aaa "   "a  aa"  "aa   aa"
//      *      *
 F(c=0, pc=0, i=0 ; (k=s[i])!=0; ++i)
   {p=alphabetic(k);
    if(pc && !p ) ++c;
    pc=p;
   }
 if(pc) ++c;
 R  c;
}

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

#72835

On 2015-10-14, Rosario19 <Ros@invalid.invalid> wrote:

>>out the loop...
>
> #define  F  for
> #defome  R  return

  #define WTF "What the fuck ?"

-- 
------ http://la.buvette.org/photos/myrys/20ans/fx/mvavrg.avi ------

        I'm <tth> on freenode. Film at 11, take your popcorn.

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

#72836

On Wed, 14 Oct 2015 16:27:31 +0200, Rosario19 wrote:

#define  F  for
#defome  R  return

/* 
 return (u32)-1= 0xFFFFFFFF for error
 or the word count in s
*/
u32  WordCount(u8*  s)
{u32  i, pc, p, c, k;
// " aaa "   "a  aa"  "aa   aa"
//      *      *
 if(s==0)         R -1;
 F(c=0, pc=0, i=0 ; (k=s[i])!=0; ++i)
   {if(i==-1)     R -1;
    p=alphabetic(k);
    if(pc && !p ) 
       {if(c==-1) R -1;
        ++c;
       }
    pc=p;
   }
 if(pc){if(c==-1) R -1;
        ++c;
       }
 R  c;
}

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

#72837

On Wed, 14 Oct 2015 16:36:37 +0200, Rosario19  wrote:
>On Wed, 14 Oct 2015 16:27:31 +0200, Rosario19 wrote:
>
>#define  F  for
>#defome  R  return
>
>/* 
> return (u32)-1= 0xFFFFFFFF for error
> or the word count in s
>*/
>u32  WordCount(u8*  s)
>{u32  i, pc, p, c, k;
>// " aaa "   "a  aa"  "aa   aa"
>//      *      *
> if(s==0)         R -1;
> F(c=0, pc=0, i=0 ; (k=s[i])!=0; ++i)
>   {if(i==-1)     R -1;
>    p=alphabetic(k);
>    if(pc && !p ) 
>       {if(c==-1) R -1;
>        ++c;
>       }
>    pc=p;
>   }
> if(pc){if(c==-1) R -1;
>        ++c;
>       }
> R  c;
>}
>

i don't know if that compile
but i know here all make the error
to think function can not fail, not have the error condition

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

#72840

On Wed, 14 Oct 2015 16:36:37 +0200, Rosario19 wrote:

>On Wed, 14 Oct 2015 16:27:31 +0200, Rosario19 wrote:
>
>#define  F  for
>#defome  R  return
>
>/* 
> return (u32)-1= 0xFFFFFFFF for error
> or the word count in s
>*/
>u32  WordCount(u8*  s)
>{u32  i, pc, p, c, k;
>// " aaa "   "a  aa"  "aa   aa"
>//      *      *
> if(s==0)         R -1;
> F(c=0, pc=0, i=0 ; (k=s[i])!=0; ++i)
>   {if(i==-1)     R -1;
>    p=alphabetic(k);
>    if(pc && !p ) 
>       {if(c==-1) R -1;
>        ++c;
>       }
>    pc=p;
>   }
> if(pc){if(c==-1) R -1;
>        ++c;
>       }
> R  c;
>}
>

because i>c i think it is ok below
#define  F  for
#defome  R  return

/* 
 return (u32)-1= 0xFFFFFFFF for error
 or the word count in s
*/
u32  WordCount(u8*  s)
{u32  i, pc, p, c, k;
// " aaa "   "a  aa"  "aa   aa"
//      *      *
 if(s==0)     R (u32)-1;
 F(c=0, pc=0, i=0 ; (k=s[i])!=0; ++i)
   {if(i==-1) R (u32)-1;
    p=alphabetic(k);
    if(pc && !p ) ++c;
    pc=p;
   }
 if(pc) ++c;
       
 R  c;
}

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

#72992

raltbos@xs4all.nl (Richard Bos) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>   int word_count = 0;
>>   for (int i = 0; string[i]; i++)
>>      word_count += alphabetic(string[i]) && !alphabetic(string[i+1]);
>>   return word_count;
>>
>> Now about 99% of people here will consider this to be the most appalling
>> code!
>
> Not at all, I've seen much worse.  This is only slightly appalling, and
> can easily be fixed like this:
>
>   int word_count = 0;
>
>   for (int i = 0; string[i]; i++)
>     if (alphabetic(string[i]) && !alphabetic(string[i+1])
>       word_count++;
>
>   return word_count;
>
> Add braces as you prefer [snip elaboration]

I agree the earlier version could use some improving, but IMO the
suggested re-write makes things worse rather than better.  Taking
the same lexical/brace style, I suggest this:

   int word_count = 0;

   for (int i = 0; string[i]; i++)
      word_count += at_end_of_word( string, i );

   return word_count;


or perhaps this (depending on unknown external factors):


   int word_count = 0;

   for (char *p = string; *p; p++)
      word_count += points_to_end_of_word( p );

   return word_count;


(And now I am preparing myself for the expected civil and
charitable replies... :)

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

#73020

On 10/15/15 23:09, Tim Rentsch wrote:
>> >
>> >Not at all, I've seen much worse.  This is only slightly appalling, and
>> >can easily be fixed like this:
>> >
>> >   int word_count = 0;
>> >
>> >   for (int i = 0; string[i]; i++)
>> >     if (alphabetic(string[i]) && !alphabetic(string[i+1])
>> >       word_count++;
>> >
>> >   return word_count;
>> >
>> >Add braces as you prefer [snip elaboration]
> I agree the earlier version could use some improving, but IMO the
> suggested re-write makes things worse rather than better.  Taking
> the same lexical/brace style, I suggest this:
>
>     int word_count = 0;
>
>     for (int i = 0; string[i]; i++)
>        word_count += at_end_of_word( string, i );
>
>     return word_count;
>
>
> or perhaps this (depending on unknown external factors):
>
>
>     int word_count = 0;
>
>     for (char *p = string; *p; p++)
>        word_count += points_to_end_of_word( p );
>
>     return word_count;
>
>
> (And now I am preparing myself for the expected civil and
> charitable replies...:)

Extracting the Boolean expression to a predicate function
revealing its goal is indeed an excellent refactoring.

My only remark here is about naming and internal consistency:
Here we have 3 predicates names:
   bool alphabetic (...);
   bool at_end_of_word (...);
   bool points_to_end_of_word(...);

* The first two have their verbs missing,
while the third has it verb present,
and used with right mood and tense for a predicated
(indicative, present).

* All three miss the subject of the verb.

Therefore:
   bool char_is_alphabetic (...);
   bool string_index_is_at_end_of_word (...);
   bool substring_points_to_end_of_word(...);
(the name of the subject of the last one is debatable,
and I would probably not use the last signature)

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

#73345

regis <regis.barbanchon@free.fr> writes:

> On 10/15/15 23:09, Tim Rentsch wrote:
>
>>>> Not at all, I've seen much worse.  This is only slightly appalling, and
>>>> can easily be fixed like this:
>>>>
>>>>   int word_count = 0;
>>>>
>>>>   for (int i = 0; string[i]; i++)
>>>>     if (alphabetic(string[i]) && !alphabetic(string[i+1])
>>>>       word_count++;
>>>>
>>>>   return word_count;
>>>>
>>>> Add braces as you prefer [snip elaboration]
>>
>> I agree the earlier version could use some improving, but IMO the
>> suggested re-write makes things worse rather than better.  Taking
>> the same lexical/brace style, I suggest this:
>>
>>     int word_count = 0;
>>
>>     for (int i = 0; string[i]; i++)
>>        word_count += at_end_of_word( string, i );
>>
>>     return word_count;
>>
>>
>> or perhaps this (depending on unknown external factors):
>>
>>
>>     int word_count = 0;
>>
>>     for (char *p = string; *p; p++)
>>        word_count += points_to_end_of_word( p );
>>
>>     return word_count;
>>
>>
>> (And now I am preparing myself for the expected civil and
>> charitable replies...:)
>
> Extracting the Boolean expression to a predicate function
> revealing its goal is indeed an excellent refactoring.

Thank you, I think so too.

> My only remark here is about naming and internal consistency:
> Here we have 3 predicates names:
>   bool alphabetic (...);
>   bool at_end_of_word (...);
>   bool points_to_end_of_word(...);
>
> * The first two have their verbs missing,
> while the third has it verb present,
> and used with right mood and tense for a predicated
> (indicative, present).
>
> * All three miss the subject of the verb.
>
> Therefore:
>   bool char_is_alphabetic (...);
>   bool string_index_is_at_end_of_word (...);
>   bool substring_points_to_end_of_word(...);
> (the name of the subject of the last one is debatable,
> and I would probably not use the last signature)

Yes, I read similar comments in another posting of yours.  Please
allow me to offer an opposing view.

First, about verbs.  Insisting on always including a verb is
overly dogmatic.  An adjective or adjectival phrase may easily
be understood to include some form of "to be" without writing
the verb.  A problem with putting in words like "is" before
"at_end_of_word" is that the "is" doesn't really add any useful
information.  If something doesn't add useful information, in
most cases there is no reason to include it.  I don't mind
seeing "is..." as part of a function name, but I don't think
it should be required either.

Second, about subject.  Every function call has an implicit
subject, which is its arguments.  What sort of thing a function
is operating on should be inferrable from the type(s) of its
argument(s).  A caller should already know what sorts of things
a function will be operating on, since after all the caller has
to supply the arguments, which already have a type in the
caller's context.  Replicating this kind of information at
every call site not only is not helpful, it's harmful:  it forces
callers to write, and read, information which in most cases they
already know.  Doing this can help comprehension during initial
reading, but for the large majority of the lifecycle developers
aren't operating in that initial mode but a more acclimated mode
where the redundant information just slows them down.  In some
unusual cases adding a subject to a function name is helpful -
but that should be viewed as the exception, not the rule.

Incidentally, regarding your last comment - in C the word
is type, not signature.  Other languages have signatures;
what C has is types.

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

#73363

On 10/19/15 23:28, Tim Rentsch wrote:

> Second, about subject.  Every function call has an implicit
> subject, which is its arguments.  What sort of thing a function
> is operating on should be inferrable from the type(s) of its
> argument(s).  A caller should already know what sorts of things
> a function will be operating on, since after all the caller has
> to supply the arguments, which already have a type in the
> caller's context.  Replicating this kind of information at
> every call site not only is not helpful, it's harmful:  it forces
> callers to write, and read, information which in most cases they
> already know.  Doing this can help comprehension during initial
> reading, but for the large majority of the lifecycle developers
> aren't operating in that initial mode but a more acclimated mode
> where the redundant information just slows them down.  In some
> unusual cases adding a subject to a function name is helpful -
> but that should be viewed as the exception, not the rule.

typedef struct Fridge Fridge;
typedef struct Box Box;

bool is_full (Fridge const * fridge);
bool is_full (Box const * box);
==> error: conflicting types for 'is_full'

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

#73364 — Re: Program to count words, issues with an if condition within a for loop

regis wrote:
> On 10/19/15 23:28, Tim Rentsch wrote:
>
>> Second, about subject.  Every function call has an implicit
>> subject, which is its arguments.  What sort of thing a function
>> is operating on should be inferrable from the type(s) of its
>> argument(s).  A caller should already know what sorts of things
>> a function will be operating on, since after all the caller has
>> to supply the arguments, which already have a type in the
>> caller's context.  Replicating this kind of information at
>> every call site not only is not helpful, it's harmful:  it forces
>> callers to write, and read, information which in most cases they
>> already know.  Doing this can help comprehension during initial
>> reading, but for the large majority of the lifecycle developers
>> aren't operating in that initial mode but a more acclimated mode
>> where the redundant information just slows them down.  In some
>> unusual cases adding a subject to a function name is helpful -
>> but that should be viewed as the exception, not the rule.
>
> typedef struct Fridge Fridge;
> typedef struct Box Box;
>
> bool is_full (Fridge const * fridge);
> bool is_full (Box const * box);
> ==> error: conflicting types for 'is_full'

Maybe Tim really does want C to be more like C++ :)

-- 
Ian Collins

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

#73372

On Tuesday, October 20, 2015 at 1:04:01 AM UTC+1, regis wrote:
> > In some
> > unusual cases adding a subject to a function name is helpful -
> > but that should be viewed as the exception, not the rule.
> 
> typedef struct Fridge Fridge;
> typedef struct Box Box;
> 
> bool is_full (Fridge const * fridge);
> bool is_full (Box const * box);
> ==> error: conflicting types for 'is_full'
>
So it partly depends on the scope.

You can't export the symbol is_full from a module named "fridge".
But it's perfectly reasonable as a static function within that
module, obviously is_full in fridge.c refers to the fridge.

Then C isn't one of those languages which is mainly about writing
trivial little access and data reformatting functions. If there's
an "Nitems" member in struct fridge, normally C will just read it
and compare to zero. 
Often functions do several things. For example, the purpose of
the fridge module may be to calculate the ideal temperature of the
fridge, given contents. So when we remove items, the temperature
is recalculated. But of course removing the last item is a special 
case. So we'd want to return a new temperature for the normal
case, but also a flag to alert us to the special case. We've also
got to consider what happens if we try to remove an item that doesn't
exist - for the sake of argument, it's been decided by someone else
that we need to pass up an error flag. So in fact we need three
returns from the same function.

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

#73396

On 10/20/15 05:07, Malcolm McLean wrote:
> On Tuesday, October 20, 2015 at 1:04:01 AM UTC+1, regis wrote:
>>> In some
>>> unusual cases adding a subject to a function name is helpful -
>>> but that should be viewed as the exception, not the rule.
>>
>> typedef struct Fridge Fridge;
>> typedef struct Box Box;
>>
>> bool is_full (Fridge const * fridge);
>> bool is_full (Box const * box);
>> ==> error: conflicting types for 'is_full'
>>
> So it partly depends on the scope.
>
> You can't export the symbol is_full from a module named "fridge".
> But it's perfectly reasonable as a static function within that
> module, obviously is_full in fridge.c refers to the fridge.

fridge_is_full() and box_is_full() are typically the functions that will 
go in their public interface.

in fact, you'll prolly have somewhere stuff along the lines:

if ( ! fridge_is_full (f))
   fridge_add_box (f, box);

> Then C isn't one of those languages which is mainly about writing
> trivial little access and data reformatting functions.
> If there's an "Nitems" member in struct fridge, normally C will
> just read it and compare to zero.

you meant fridge_is_empty() here i guess...
but why do you make this assumption ?

bool fridge_is_empty(fridge const * f) {...}
could be any of:

return f->itemsCount == 0;

return f->beersCount + f->eggsCount == 0;

return fridge_door_is_empty (f->door)
   &&   fridge_crisper_is_empty (f->crisper)
   &&   fridge_freezer_is_empty (f->freezer)
   &&   fridge_shelves_are_empty (f->shelves);
}

the last one show you that even if *_is_empty() are static,
there might be several ones inside same module.
So even in this case, sloppy naming simply does not scale up.

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

#73400

On 10/20/15 14:30, regis wrote:
> On 10/20/15 05:07, Malcolm McLean wrote:
>> On Tuesday, October 20, 2015 at 1:04:01 AM UTC+1, regis wrote:
>>>> In some
>>>> unusual cases adding a subject to a function name is helpful -
>>>> but that should be viewed as the exception, not the rule.
>>>
>>> typedef struct Fridge Fridge;
>>> typedef struct Box Box;
>>>
>>> bool is_full (Fridge const * fridge);
>>> bool is_full (Box const * box);
>>> ==> error: conflicting types for 'is_full'
>>>
>> So it partly depends on the scope.
>>
>> You can't export the symbol is_full from a module named "fridge".
>> But it's perfectly reasonable as a static function within that
>> module, obviously is_full in fridge.c refers to the fridge.
>
> fridge_is_full() and box_is_full() are typically the functions that will
> go in their public interface.
>
> in fact, you'll prolly have somewhere stuff along the lines:
>
> if ( ! fridge_is_full (f))
>    fridge_add_box (f, box);
>
>> Then C isn't one of those languages which is mainly about writing
>> trivial little access and data reformatting functions.
>> If there's an "Nitems" member in struct fridge, normally C will
>> just read it and compare to zero.
>
> you meant fridge_is_empty() here i guess...
> but why do you make this assumption ?
>
> bool fridge_is_empty(fridge const * f) {...}
> could be any of:
>
> return f->itemsCount == 0;
>
> return f->beersCount + f->eggsCount == 0;
>
> return fridge_door_is_empty (f->door)
>    &&   fridge_crisper_is_empty (f->crisper)
>    &&   fridge_freezer_is_empty (f->freezer)
>    &&   fridge_shelves_are_empty (f->shelves);
> }
>
> the last one show you that even if *_is_empty() are static,
> there might be several ones inside same module.
> So even in this case, sloppy naming simply does not scale up.

Also, fridge_shelves_are_empty() prolly does not even hide
a simple expression, but something along the lines...

{
   for (int k= 0; k < fridge_shelves_count (shelves); k++) {
     FridgeShelf const * shelf= fridge_shelves_get (k);
     if ( ! fridge_shelf_is_empty  (shelf)) return false;
   }
   return true;
}

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

#73724

regis <regis.barbanchon@free.fr> writes:

> On 10/19/15 23:28, Tim Rentsch wrote:
>
>> Second, about subject.  Every function call has an implicit
>> subject, which is its arguments.  What sort of thing a function
>> is operating on should be inferrable from the type(s) of its
>> argument(s).  A caller should already know what sorts of things
>> a function will be operating on, since after all the caller has
>> to supply the arguments, which already have a type in the
>> caller's context.  Replicating this kind of information at
>> every call site not only is not helpful, it's harmful:  it forces
>> callers to write, and read, information which in most cases they
>> already know.  Doing this can help comprehension during initial
>> reading, but for the large majority of the lifecycle developers
>> aren't operating in that initial mode but a more acclimated mode
>> where the redundant information just slows them down.  In some
>> unusual cases adding a subject to a function name is helpful -
>> but that should be viewed as the exception, not the rule.
>
> typedef struct Fridge Fridge;
> typedef struct Box Box;
>
> bool is_full (Fridge const * fridge);
> bool is_full (Box const * box);
> ==> error: conflicting types for 'is_full'

This is a separate issue, having to do with scoping.

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

#73366

On 10/19/15 23:28, Tim Rentsch wrote:
> First, about verbs.  Insisting on always including a verb is
> overly dogmatic.  An adjective or adjectival phrase may easily
> be understood to include some form of "to be" without writing
> the verb.  A problem with putting in words like "is" before
> "at_end_of_word" is that the "is" doesn't really add any useful
> information.  If something doesn't add useful information, in
> most cases there is no reason to include it.  I don't mind
> seeing "is..." as part of a function name, but I don't think
> it should be required either.

what could be:
   int century_year (int year);
in a world where predicates are allowed to have implict verbs ?

It could stand for the predicate:
   int year_is_century_year (int year) { return year % 100 == 0; }
or it could stand for the function:
    int year_to_century_year (int year) { return year - year % 100; }

In a world where predicates always have verbs,
it can only be the second case.

Now, there's more. Even if we know we have a predicate without verb:
   int common_century_year (int year);

it could be:
   int year_is_common_century_year (int year) {
     return year_is_century_year (year) && year % 400 != 0;
   }

but it could be:
   int century_year_is_common (int year) {
      assert (year_is_century_year (year);
      return year % 400 != 0;
   }

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

#73725

regis <regis.barbanchon@free.fr> writes:

> On 10/19/15 23:28, Tim Rentsch wrote:
>> First, about verbs.  Insisting on always including a verb is
>> overly dogmatic.  An adjective or adjectival phrase may easily
>> be understood to include some form of "to be" without writing
>> the verb.  A problem with putting in words like "is" before
>> "at_end_of_word" is that the "is" doesn't really add any useful
>> information.  If something doesn't add useful information, in
>> most cases there is no reason to include it.  I don't mind
>> seeing "is..." as part of a function name, but I don't think
>> it should be required either.
>
> what could be:
>   int century_year (int year);
> in a world where predicates are allowed to have implict verbs ?

The phrase "century_year" is not an adjective or adjectival
phrase.

> Now, there's more.  Even if we know we have a predicate without verb:
>   int common_century_year (int year);

Neither is "common_century_year".

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

#73764

On 10/24/15 21:21, Tim Rentsch wrote:
> regis <regis.barbanchon@free.fr> writes:
>
>> On 10/19/15 23:28, Tim Rentsch wrote:
>>> First, about verbs.  Insisting on always including a verb is
>>> overly dogmatic.  An adjective or adjectival phrase may easily
>>> be understood to include some form of "to be" without writing
>>> the verb.  A problem with putting in words like "is" before
>>> "at_end_of_word" is that the "is" doesn't really add any useful
>>> information.  If something doesn't add useful information, in
>>> most cases there is no reason to include it.  I don't mind
>>> seeing "is..." as part of a function name, but I don't think
>>> it should be required either.
>>
>> what could be:
>>    int century_year (int year);
>> in a world where predicates are allowed to have implict verbs ?
>
> The phrase "century_year" is not an adjective or adjectival
> phrase.
>
>> Now, there's more.  Even if we know we have a predicate without verb:
>>    int common_century_year (int year);
>
> Neither is "common_century_year".
>

in other word you say isalpha() should be shortened alpha()
because it is adjectival but isdigit() should not be shortened digit() 
because digit is a noun ?

there's no reason to distinguish predicates of the form 
(subject_)verb_adjective,  (subject_)verb_noun, ...

and by the way, since these two functions miss their subject
and take an int as arg, you cannot derive that the character should
be encoded as an unsigned char, neither by the name nor by the type
of the arg. Also, Expliciting a subject would have prevented the design 
error to include EOF as a valid arg.

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

#74034

regis <regis.barbanchon@free.fr> writes:

> On 10/24/15 21:21, Tim Rentsch wrote:
>> regis <regis.barbanchon@free.fr> writes:
>>
>>> On 10/19/15 23:28, Tim Rentsch wrote:
>>>> First, about verbs.  Insisting on always including a verb is
>>>> overly dogmatic.  An adjective or adjectival phrase may easily
>>>> be understood to include some form of "to be" without writing
>>>> the verb.  A problem with putting in words like "is" before
>>>> "at_end_of_word" is that the "is" doesn't really add any useful
>>>> information.  If something doesn't add useful information, in
>>>> most cases there is no reason to include it.  I don't mind
>>>> seeing "is..." as part of a function name, but I don't think
>>>> it should be required either.
>>>
>>> what could be:
>>>    int century_year (int year);
>>> in a world where predicates are allowed to have implict verbs ?
>>
>> The phrase "century_year" is not an adjective or adjectival
>> phrase.
>>
>>> Now, there's more.  Even if we know we have a predicate
>>> without verb:
>>>    int common_century_year (int year);
>>
>> Neither is "common_century_year".
>
> in other word you say isalpha() should be shortened alpha()
> because it is adjectival but isdigit() should not be shortened digit()
> because digit is a noun ?
>
> there's no reason to distinguish predicates of the form
> (subject_)verb_adjective,  (subject_)verb_noun, ...

Sure there is.  For adjectives, by far the most common case is
some form of "to be", and as such needn't be included in most
cases.  For nouns or noun phrases, it could be a function,
property or attribute; or the object of a transitive verb; or
playing an adjective-like role with a "to be" type verb.  The
first type of noun usage is akin to a possessive, eg, "John's
height", which has no verb at all;  the second type needs a
transitive verb;  the third type needs a form of "to be", to
differentiate it from the first type.  Obviously adjectives and
nouns have different usage patterns, which motivates their
being treated differently.


> and by the way, since these two functions miss their subject
> and take an int as arg, you cannot derive that the character should
> be encoded as an unsigned char, neither by the name nor by the type
> of the arg.

That just means the parameter type name was poorly choosen.

> Also, Expliciting a subject would have prevented the
> design error to include EOF as a valid arg.

This claim is not IMO even remotely credible.

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

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

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

csiph-web