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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

#73759

Elegance for me could mean
that where one see the code
it is easy to read
more than comments
and not leave doubts

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

#73763

On Sunday, October 25, 2015 at 10:26:43 AM UTC, asetof...@gmail.com wrote:
>
> Elegance for me could mean
> that where one see the code
> it is easy to read
> more than comments
> and not leave doubts
>
It's not really the same.

while(ptr)
{
   free(ptr);
   ptr = ptr->next;
}

is elegant, but prohibited in modern C. (It was allowed in the olden
day, when you could access a pointer you had just freed.

while(ptr)
{
  temp = ptr->next;
  free(ptr);
  ptr = temp;
}

is correct but not elegant, because you've introduced a new variable.

void freelist(void *ptr)
{
  if(ptr)
   freelist(ptr->next);
 free(ptr);
}

is correct and elegant but hopelessly inefficient (on typical compilers),
and liable to blow your stack.

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

#73769

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

> On Sunday, October 25, 2015 at 10:26:43 AM UTC, asetof...@gmail.com wrote:
>>
>> Elegance for me could mean
>> that where one see the code
>> it is easy to read
>> more than comments
>> and not leave doubts
>>
> It's not really the same.
>
> while(ptr)
> {
>    free(ptr);
>    ptr = ptr->next;
> }
>
> is elegant, but prohibited in modern C. (It was allowed in the olden
> day, when you could access a pointer you had just freed.

I don't recall any time when relying free leaving the data alone would
be considered elegant.  Even on those systems where it worked, I'd call
it a hack, and hacks are rarely elegant.

(Also worth saying that "modern C", where this is not allowed, means C
for at least the last quarter of a century.)

<snip>
> void freelist(void *ptr)
> {
>   if(ptr)
>    freelist(ptr->next);
>  free(ptr);
> }
>
> is correct

(when the types are corrected)

> and elegant but hopelessly inefficient (on typical compilers),
> and liable to blow your stack.

I wouldn't call it elegant, but elegance is probably too personal to be
worth arguing over.  This:

  void freelist(node *list, node *prev)
  {
       free(prev);
       if (list) freelist(list->next, list);
  }

(called as freelist(l, 0);) has the merit of being efficient (on good
compilers), but I doubt it would pass as elegant in C.

-- 
Ben.

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

#73772

On Sunday, October 25, 2015 at 8:39:05 AM UTC-5, Malcolm McLean wrote:
> is correct but not elegant, because you've introduced a new variable.

There are a lot of cases in C where I find that code needs to update a variable
but use the old value for something that has to occur after the update.  One
operator I've thought would be useful for that (I've thought of the semantics,
but don't know the best syntax) would evaluate the left and right operands
with a sequence point between them, similar to the comma operator, but then
yield the value of the *left* operand.  If the syntax <<,<< were used for that
operator, then free-and-advance code could be:

    ptr = (ptr->next <<,<< free(ptr));

Alternatively, if there were operators that were to the assignment operators
what postfix ++ is to prefix ++ (i.e. change the left operand, but return the
value the left operand had before the change) then the free-and-advance code
could be

    free(ptr :=: ptr->next);

I have no idea what tokens would be good to denote such operators if one
wanted to include them in a future language (while it would have been useful
if C had included such operators, I wouldn't expect them to get added now).
There are a lot of cases where the "change something after yielding the old
value" semantics are useful, but unfortuantely C only provides those
semantics for the very specific cases of ++ and -- even though there are many
cases where they'd be useful for other things as well [e.g. a simple memory-
pool allocator may often have to include something like:

    void *ret = next_alloc;
    next_alloc += new_size;
    return ret;

thus requiring a temporary variable merely to handle the same kind of super-
short-term storage as was needed for the linked-list cleanup code.

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

#73783

supercat@casperkitty.com writes:
> On Sunday, October 25, 2015 at 8:39:05 AM UTC-5, Malcolm McLean wrote:
>> is correct but not elegant, because you've introduced a new variable.
>
> There are a lot of cases in C where I find that code needs to update a
> variable but use the old value for something that has to occur after
> the update.  One operator I've thought would be useful for that (I've
> thought of the semantics, but don't know the best syntax) would
> evaluate the left and right operands with a sequence point between
> them, similar to the comma operator, but then yield the value of the
> *left* operand.
[...]

Perhaps a double comma?

    (x, y)  // evaluates x, evaluates y, yields the result of y
    (x,, y) // evaluates x, evaluates y, yields the result of x

The syntax doesn't suggest the meaning to a reader who isn't already
familiar with it, but that's true of a lot of operator symbols.

I'm not sure it's used often enough to be worth adding to the language,
but there have been times when it would have been handy.

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

#73796

On Sunday, October 25, 2015 at 2:21:40 PM UTC-5, Keith Thompson wrote:
> Perhaps a double comma?
> 
>     (x, y)  // evaluates x, evaluates y, yields the result of y
>     (x,, y) // evaluates x, evaluates y, yields the result of x
> 
> The syntax doesn't suggest the meaning to a reader who isn't already
> familiar with it, but that's true of a lot of operator symbols.
> 
> I'm not sure it's used often enough to be worth adding to the language,
> but there have been times when it would have been handy.

Even though a double comma would generally not be legal (except as part of
a macro invocation) it has a plausible meaning [it would be legal to have
one of the operands of the comma operator be a void expression, and it's
plausible that some compilers might accept an empty expression too as an
extension].  I suggested ":,:" because I don't think that sequence has
any *plausible* meaning in the C language or any existing extensions to it.

I suspect if the operator had existed since 1978, it would probably be used
a lot today; since it didn't people have become accustomed to defining
one-time-use temp variables to get around its absence.

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

#73802

supercat@casperkitty.com writes:
> On Sunday, October 25, 2015 at 2:21:40 PM UTC-5, Keith Thompson wrote:
>> Perhaps a double comma?
>> 
>>     (x, y)  // evaluates x, evaluates y, yields the result of y
>>     (x,, y) // evaluates x, evaluates y, yields the result of x
>> 
>> The syntax doesn't suggest the meaning to a reader who isn't already
>> familiar with it, but that's true of a lot of operator symbols.
>> 
>> I'm not sure it's used often enough to be worth adding to the language,
>> but there have been times when it would have been handy.
>
> Even though a double comma would generally not be legal (except as part of
> a macro invocation) it has a plausible meaning [it would be legal to have
> one of the operands of the comma operator be a void expression, and it's
> plausible that some compilers might accept an empty expression too as an
> extension].  I suggested ":,:" because I don't think that sequence has
> any *plausible* meaning in the C language or any existing extensions to it.

I don't think accepting an empty expression is a plausible extension.

Macros might be an issue, though.

> I suspect if the operator had existed since 1978, it would probably be used
> a lot today; since it didn't people have become accustomed to defining
> one-time-use temp variables to get around its absence.

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

#73815

supercat@casperkitty.com writes:
<snip>
> Alternatively, if there were operators that were to the assignment operators
> what postfix ++ is to prefix ++ (i.e. change the left operand, but return the
> value the left operand had before the change) then the free-and-advance code
> could be
>
>     free(ptr :=: ptr->next);

(I'd use that operator for a swapping assignment, myself.)

> I have no idea what tokens would be good to denote such operators if one
> wanted to include them in a future language

Algol 68C has what it called the displacement operator

  free(ptr :=:= ptr->next);

Since Algol 68C also provided <op>:= forms for assignment, it naturally
also defined <op>:=:= forms so that, to take one example, x +:= 1 and x
+:=:= 1 behaved like C's ++x and x++.

And because plain Algol 68 permits new operators to be defined, it was
not uncommon to see these implemented elsewhere.

I miss them (though I don't like the syntax much).

<snip>
-- 
Ben.

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

#73846

On 26/10/2015 00:58, Ben Bacarisse wrote:
> supercat@casperkitty.com writes:
> <snip>
>> Alternatively, if there were operators that were to the assignment operators
>> what postfix ++ is to prefix ++ (i.e. change the left operand, but return the
>> value the left operand had before the change) then the free-and-advance code
>> could be
>>
>>      free(ptr :=: ptr->next);
>
> (I'd use that operator for a swapping assignment, myself.)

(I use :=: for swap, but don't like it much and prefer just typing 
'swap', either as 'a swap b', or more usually as 'swap(a, b)'. The less 
cryptic the better!)

>> I have no idea what tokens would be good to denote such operators if one
>> wanted to include them in a future language
>
> Algol 68C has what it called the displacement operator
>
>    free(ptr :=:= ptr->next);
>
> Since Algol 68C also provided <op>:= forms for assignment, it naturally
> also defined <op>:=:= forms so that, to take one example, x +:= 1 and x
> +:=:= 1 behaved like C's ++x and x++.

The problem with this idea is coming up with an obvious syntax. ":=:=" 
is one possible operator, "=:=" might be another. It's just doesn't look 
right.

Putting aside the question of syntax, I had a go at implementing it (not 
in C), I used this form (25-10 being the date the idea was posted):

   x := clc2501(a := b)

which, translated to C, would produce something like:

   x = (temp = a, a = b, temp);

which sort of works, but evaluates the left side of the assignment 
twice, so is not ideal. I think proper support is needed deep inside the 
code generator, which makes it harder to implement (well, a lot more 
effort than the 30 minutes I spent).

-- 
Bartc

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

#75577

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

> while(ptr)
> {
>    free(ptr);
>    ptr = ptr->next;
> }
> 
> is elegant, but prohibited in modern C. (It was allowed in the olden
> day, when you could access a pointer you had just freed.

[Citation needed], as so often with these ye-olden-dayes claims.

I know that there were implementations where you could take this gamble
and expect to survive nine times out of ten, certainly on unprotected
OSes like MS-DOS. But even then it was never guaranteed by the
documentation, let alone allowed in any standard.

Richard

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

#75709

Richard Bos wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
>> while(ptr)
>> {
>>     free(ptr);
>>     ptr = ptr->next;
>> }
>>
>> is elegant, but prohibited in modern C. (It was allowed in the olden
>> day, when you could access a pointer you had just freed.
>
> [Citation needed], as so often with these ye-olden-dayes claims.
>
> I know that there were implementations where you could take this gamble
> and expect to survive nine times out of ten, certainly on unprotected
> OSes like MS-DOS.

More than that. SFAIK, it would always work in DOS unless for
some bizarre reason an interrupt could somehow mess it up for you.

> But even then it was never guaranteed by the
> documentation, let alone allowed in any standard.
>

It's VERY VERY BAD! :) If you do this, your code is bad
and you should feel bad :)

> Richard
>

-- 
Les Cargill

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

#75719

On Wed, 2015-11-11, Les Cargill wrote:
> Richard Bos wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>
>>> while(ptr)
>>> {
>>>     free(ptr);
>>>     ptr = ptr->next;
>>> }
>>>
>>> is elegant, but prohibited in modern C. (It was allowed in the olden
>>> day, when you could access a pointer you had just freed.
>>
>> [Citation needed], as so often with these ye-olden-dayes claims.
>>
>> I know that there were implementations where you could take this gamble
>> and expect to survive nine times out of ten, certainly on unprotected
>> OSes like MS-DOS.
>
> More than that. SFAIK, it would always work in DOS unless for
> some bizarre reason an interrupt could somehow mess it up for you.

Yes, of course. Even on something like AmigaDOS with preemptive
multitasking and a shared heap, it would work much more often than
9/10.

But a claim that it was actually an allowed practice /in C/ is still
an interesting one.  Like Richard Bos I would be interested to hear
more.

>> But even then it was never guaranteed by the
>> documentation, let alone allowed in any standard.
>
> It's VERY VERY BAD! :) If you do this, your code is bad
> and you should feel bad :)

Why the sarcasm (if that's what it is)?  I thought we all agreed on at
least this: random memory corruption bugs are a pain and should be
avoided?

A few years back I spent a week or so of late nights due to just this
bug, found by a customer at the other side of the world. I had already
fixed it[0] for the next release, but proving it was the same bug,
doing the paperwork etc was still a lot of work.

/Jorgen

[0] I didn't introduce it.  I may not have found it myself, either: it
    may have been one of a few bugs we found using static analysis
    tools.

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#75739

Jorgen Grahn wrote:
> On Wed, 2015-11-11, Les Cargill wrote:
>> Richard Bos wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>
>>>> while(ptr)
>>>> {
>>>>      free(ptr);
>>>>      ptr = ptr->next;
>>>> }
>>>>
>>>> is elegant, but prohibited in modern C. (It was allowed in the olden
>>>> day, when you could access a pointer you had just freed.
>>>
>>> [Citation needed], as so often with these ye-olden-dayes claims.
>>>
>>> I know that there were implementations where you could take this gamble
>>> and expect to survive nine times out of ten, certainly on unprotected
>>> OSes like MS-DOS.
>>
>> More than that. SFAIK, it would always work in DOS unless for
>> some bizarre reason an interrupt could somehow mess it up for you.
>
> Yes, of course. Even on something like AmigaDOS with preemptive
> multitasking and a shared heap, it would work much more often than
> 9/10.
>
> But a claim that it was actually an allowed practice /in C/ is still
> an interesting one.  Like Richard Bos I would be interested to hear
> more.
>
>>> But even then it was never guaranteed by the
>>> documentation, let alone allowed in any standard.
>>
>> It's VERY VERY BAD! :) If you do this, your code is bad
>> and you should feel bad :)
>
> Why the sarcasm (if that's what it is)?

It's based on a reference - "The music is bad and you should feel bad"
from a fine episode of Futurama.

I forget where I saw it applied to code first. It's more or
less an attempt at humor but it's probably too complicated.
Dying is easy; comedy is hard.

Here: The joke is bad and I should feel bad. :)

Of course you shouldn't feel bad. But I find it fun to think of
certain code idioms as "sinful" when they cause insidious and hard
to find bugs.

> I thought we all agreed on at
> least this: random memory corruption bugs are a pain and should be
> avoided?
>

Yessir. That's the context of my remark.


> A few years back I spent a week or so of late nights due to just this
> bug, found by a customer at the other side of the world. I had already
> fixed it[0] for the next release, but proving it was the same bug,
> doing the paperwork etc was still a lot of work.
>

Right. It's bizarre how time-sensitive defects are.


> /Jorgen
>
> [0] I didn't introduce it.  I may not have found it myself, either: it
>      may have been one of a few bugs we found using static analysis
>      tools.
>

-- 
Les Cargill

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

#75715

On Tue, 10 Nov 2015 15:17:15 GMT, raltbos@xs4all.nl (Richard Bos)
wrote:

>Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
>> while(ptr)
>> {
>>    free(ptr);
>>    ptr = ptr->next;
>> }
>> 
>> is elegant, but prohibited in modern C. (It was allowed in the olden
>> day, when you could access a pointer you had just freed.
>
>[Citation needed], as so often with these ye-olden-dayes claims.
>
>I know that there were implementations where you could take this gamble
>and expect to survive nine times out of ten, certainly on unprotected
>OSes like MS-DOS. But even then it was never guaranteed by the
>documentation, let alone allowed in any standard.


I worked on one (probably more than one) heap manger in ye-olden-dayes
where this would not have worked if next was too near the beginning of
the structure pointer to by ptr.  The free would use the beginning of
the (now free) block for linkage into the freelist.

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

#74089

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Sat, 2015-10-24, Tim Rentsch wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
> ...
>
>>> Another way of looking at it:
>>>
>>>     int
>>>     at_start_of_word( const char *s, int k ) {
>>>         char ch = s[k];
>>>         char prev = k ? s[k-1] : '\0';
>>>         return alphabetic(ch) && !alphabetic(prev);
>>>     }
>>>
>>> I.e. inventing a previous character if there isn't one, and
>>> optimizing for clarity of that last expression.
>>
>> Verbal nit:  you say "clarity" but I think a more apt word here
>> is "simplicity".  The return expression is certainly simpler than
>> the one I wrote, but whether it is more clear is a subjective
>> question.
>
> What I wanted to say was that I liked how the code boiled down to
> "this character is a letter and the previous wasn't".  I'm not sure
> "simplicity" /or/ "clarity" is the right word ...

Ah.  With this added explanation, what I think you're trying to
say is something like "more closely reflects how I conceptualize
the problem (or a solution)".  So it isn't just a property of the
text, but how well the text expresses your thinking.  Am I
reading you right or did I misunderstand something?

> And yes, I know this is to a large part subjective.

Any property that depends on human comprehension is, to some
degree, subjective.  My point above is that some properties may be
defined so that they do not depend on human comprehension, which
allows them to be less subjective or even not subjective at all.

>>> I often refactor by introducing intermediates like that.  In
>>> general, I think people are too reluctant to do it -- it's almost
>>> as if they feel there's a cost associated with variables, but not
>>> with code.
>>
>> I'm not averse to introducing single-use temporaries when/where I
>> think they help;  sometimes they do, sometimes they don't, and
>> sometimes breaking things down makes things worse rather than
>> better.
>
> Yes.
>
> But there are extremes which I've encountered fairly often when
> maintaining code.  Not small functions like the one above, but long
> ones, where the same expression is repeated over and over again.
> Introducing a well-named temporary there is a very cheap and effective
> refactoring step.

I distinguish between expressions whose value is used once and
expressions whose value is used more than once.  My comment above
is only about the used-once kind (and I won't say more about the
other kind except to say I expect we are largely in agreement,
based on your above elaboration).

>> Personally I don't think the single-expression return I
>> wrote above is too much to be read in a single line, but I know
>> that different people have different threholds.  Assuming for the
>> sake of discussion we have decided to introduce temporaries along
>> the lines of the above, I still don't like the way it's written,
>> partly because of the slightly sneaky way that 'prev' is set/used.
>
> Yeah, that didn't feel quite right, although I could motivate it as
> "the imaginary character before the string".

I understand the motivation, and to some extent agree with it.
In effect what you are doing is making use of a common conceptual
idiom.  This idiom is (generically) one that is useful to know,
because it comes up often enough to be worthwhile.  Unfortunately
it is hard to express in a way that conveys what is intended to
someone who isn't familiar with (or doesn't notice) the idiom,
because there is to some degree a fabrication involved.  That's
not to say it shouldn't be used, only that code that does so
often requires more care in its writing.

>> Furthermore, as long as we're going to the trouble of putting in
>> names, maybe we can choose some that do a little more work.  How
>> about this:
>>
>>     int
>>     at_start_of_word( const char *s, int k ) {
>>         int this_alpha     =   alphabetic( s[k] );
>>         int not_last_alpha =   k == 0  ||  ! alphabetic( s[k-1] );
>>         return  this_alpha  &&  not_last_alpha;
>>     }
>>
>> Not the first writing that would occur to me, but not one I
>> would object to either.
>
> I would prefer "previous" to "last", and I'd avoid "not" in the
> names:
>
>     int
>     at_start_of_word( const char *s, int k ) {
>         int this_alpha = alphabetic( s[k] );
>         int prev_alpha = k > 0 && alphabetic( s[k-1] );
>         return this_alpha && !prev_alpha;
>     }
>
> I'm not nitpicking now, or trying to win anyone over.

I love that last sentence.  Here are responses intended in the
same spirit (and hopefully successfully).

For writing careful English, I think "previous" is a bit better
than "last" in this situation (although "preceding" seems better
than both).  In writing code, "last" and "previous" seem close
enough so either is okay.  Different considerations apply in the
two circumstances (ie, writing code and writing English).  As a
general rule I eschew shortenings like "prev", and since "last"
matched how I think of the algorithm (going through the string
from left to right), that's what got used.

About the "not_" - I agree the name is awkward.  But I wouldn't
want to just drop it, for similar reasons to my earlier reaction
to "prev":  the name prev_alpha (or previous_alphabetic) seems
like it is just a little bit misleading, and I really try to
avoid writing code that misleads the reader.  Choosing a good
name here is difficult.  Perhaps this:

    int imagined_preceding_character_is_alphabetic =
        k > 0 && alphabetic( s[k-1] );

This name isn't one I'd be likely to use but it does illustrate
the problem of the name choice here.

For amusement is an alternate writing of the function body, one I
expect will please no one :)

    return  alphabetic( s[k] )  &&  ! alphabetic( k > 0 ? s[k-1] : ' ' );

Even though this is not (IMO) how the code should be written, I
think it's useful to explore different alternatives, which may
suggest other ideas or improvements.

> It's just that it's interesting to compare different
> preferences.  I believe many of them can change as you work
> with other programmers, but some things are hardwired in our
> brains, perhaps from when we learned how to read, or from
> birth.

My experience has been (and continues to be) that comparing
preferences is not nearly as useful as discussing the
underlying reasoning and explanations for those preferences.

IMO your last sentence is undoubtedly true, but the interesting
question is Which ones are which?  I think different people make
very different assumptions about the answers to that question.

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

#73229

On Sat, 10 Oct 2015 10:28:18 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

>Hello!
>
>I would be grateful for the help on the following issue.
>Before posting my question, I would like to mention that 
>I do understand that wordy explanations are irksome, and 
>I do try to escape those, though not this time. In attempt
>to express my thoughts I did produce a lengthy explanation.
>Thank you for your patience!

You are working too many projects simultaneously.  The purpose of the
exercises should not be to see how many you can do at once or how
quickly you can do them.  It should be to understand the concepts that
each is emphasizing and apply that understanding to the next exercise.

<snip>

>My question is regarding the following part:
>
>for (i = 0; string[i] != '\0'; i++)
>        if (alphabetic (string [i]))
>        {
>            if (look_for_word)
>            {
>                word_count++;
>                look_for_word = false;
>            }
>        }
>
>/** Quote from the book: 
>
>If the character is alphabetic, the look_for_word 
>flag is tested to determine if you are in the process of looking for 
>a new word. If you are, the value of word_count is incremented by 1, 
>and the flag is set to false, indicating that you are no longer looking
>for the start of a new word.
>     
>If the character is alphabetic and the look_for_word flag is false, this
>means that you are currently scanning inside a word. In such a case, 
>the loop is continued with the next character in the string. **/
>     
>This all is not clear to me. I have a different interpretation of
>that part of code.
>
>The main part that confuses me is how word_count works (I see it adding
>adds up characters, but not words): 

It is not adding characters at all.  Nowhere does it add 'a' to 'b'.
It counts occurrences of a particular condition.  Does it help if you
think of it as counting the number of characters that are the first
character in a word.  Since every word must have exactly one first
character and each such character is the start of a new word, the two
concepts are equivalent.

>1) how does look_for_word technically indicate if I am, or am not, looking 
>for a new word? does it do so by scanning every letter of the word, 
>i.e. string[i], until it hits a blank space, or any other non-alphabatic character, which sets result of aplhabetic() function to false?

look_for_word is a simple bool variable.  As you note, it indicates
what state your program is in.  It does no processing by itself.  It
cannot scan anything or call a function such as alphabetic.

>     For example: let's take the phrase 'app new'
>     
>     for (i = 0; string[i] != '\0'; i++)
>        if (alphabetic (string [i]))
>        {
>            if (look_for_word)
>            {
>                word_count++;
>                look_for_word = false;
>            }
>        }
>     
>     The above part should, if I understand it correctly (well, I don't! :)),
>     do the following:
>     
>     1) before the for loop starts the look_for_word is set to true;
>     
>     2) then i = 0 is 'a' is tested, and it is alphabatic, thus the
>     program enters the outer if condition;
>     
>     3) as soon as the character 'a' is discerned as an alphabetical one,
>     the inner if condition starts; I don't understand the meaning of
>     this condition: does (look_for_word) have no value as a condition, 
>     and acts only as a "signal" that this flag will get a value later? 

The entire question makes no sense.  look_for_word is just a simple
variable.  It either has a value (as a result of initialization or
assignment) or its value is indeterminate.  Since you assigned it a
value before the for loop, the latter does not apply.  In the if
statement, that value is used to determine whether you are looking for
the start of a new word or not.  In the assignment statement, its
previous value is irrelevant.  No matter what that value was, it will
be set the value of the right hand expression (in this case false).

>     the value true has been initially assigned to this flag, and 
>     has not been changed before this inner if condition; hence it's value 
>     is still true when the program enters this inner if condition; confusing.

So you understand it has a value.  Why do you ask if it has no value?
     
>     4) as the program detected the character 'a' as an alphabatical one,
>     word_count++ means that the word_count variable's value is not incremented

I assume that is a typo and you did not mean "not".

>     by one and has a value of 1 and look_for_word is set to false, because we
>     are inside the word now. 
>     
>     5) the program now moves to the second character i = 1 which is 'p'; the 
>     test shows that it is the alphabatical one.
>     
>     6) when the program starts working with 'p' character, the inner 
>     if  condition (look_for_word) is false, because it was set to false 
>     in the previous round.
>     
>     7) given word_count is within the for loop, it should be incremented 
>     with  each alphabatical character, but not with each word, and thus, 
>     when the program is done working with 'p', word_cound should be equal 
>     to 2. I know that the code works as it should, but I don't see how.

The fact that the increment statement is in the loop is only half the
story.  The statement is also inside the compound if statement.  Since
the if evaluates to false, none of statements that make up the
compound statement are executed.  If they were executed without regard
to the test in the if statement, that test would serve no purpose.

>     And so on, until the code reaches a blank space between app and new; 
>     the count is terminated, and starts when the next alphabatical character
>     is found.

Any non-alphabetic character will mark the end of a word and your
program will change from "in the middle of a word" to "looking for a
new word".

>     Here is the table they use for demonstration in the book. I don't see how 
>     word_count gets these values; I added my erroneous numbers to show how I 
>     see that part of the code.
>         
>     i    string[i]  word_count  look_for_word       my word_count
>                        0         true                    0
>     0        'a'       1         false                   1
>     1        'p'       1         false                   2

Why did you increment your word_count when look_for_word is false?  Is
your real problem that yo don't understand what the difference is when
an if test evaluates to true or false?

>     2        'p'       1         false                   3
>     3        ' '       1         true                    nothing

Once a variable has a value, it will retain that value for the rest of
its life unless you assign it a new value.  Your word_count cannot go
from 3 to nothing (and even worse, it cannot go from nothing to 4 by
virtue of an increment).  If it truly was indeterminate, incrementing
it would lead to undefined behavior.

-- 
Remove del for email

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

#73248

What about this? 
u32 inNow, inPrec, k;

for(i=0, inPrec=0; k=str[i]; ++i){
     inNow=isalpha(k);
     if(inNow && !inPrec) ++contWrd;
     inPrec=inNow;               
    }

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

#73251

asetofsymbols@gmail.com wrote:
> What about this?

What about what?

Please quote correctly with context.

-- 
Ian Collins

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

#73260

I wrote:
What about this? 
u32 inNow, inPrec, k; 

for(i=0, inPrec=0; k=str[i]; ++i){ 
     inNow=isalpha(k); 
     if(inNow && !inPrec) ++contWrd; 
     inPrec=inNow;               
    } 
----------
At 12:40 AM  Ian Collins wrote:
asetof...@gmail.com wrote: 
> What about this? 

What about what? 

Please quote correctly with context. 

-- 
Ian Collins
-------------------------
What about this function:
/* Count words of 's'
   return 0xFFFFFFFF For error
   return 0..0xFFFFFFFE For
       words number in 's'
*/
u32 WordsCount(u8* s){
u32 inNow, inPrec, k, i, cntWrd;

if(s==0) return 0xFFFFFFFF;

cntWrd=0;
for(i=0, inPrec=0; k=s[i]; ++i){ 
     if(i==0xFFFFFFFF)
           return 0xFFFFFFFF;
     inNow=isalpha(k); 
     if(inNow && !inPrec) ++cntWrd; 
     inPrec=inNow;               
    } 
return cntWrd;
}

where u8 is unsigned char 8 bit
and   u32 is unsigned 32 bit

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

#73261

I wrote:
What about this? 
u32 inNow, inPrec, k; 

for(i=0, inPrec=0; k=str[i]; ++i){ 
     inNow=isalpha(k); 
     if(inNow && !inPrec) ++contWrd; 
     inPrec=inNow;               
    } 
----------
At 12:40 AM  Ian Collins wrote:
asetof...@gmail.com wrote: 
> What about this? 

What about what? 

Please quote correctly with context. 

-- 
Ian Collins
-------------------------
What about this function:
/* Count words of 's'
   return 0xFFFFFFFF For error
   return 0..0xFFFFFFFE For
       words number in 's'
*/
u32 WordsCount(u8* s){
u32 inNow, inPrec, k, i, cntWrd;

if(s==0) return 0xFFFFFFFF;

cntWrd=0;
for(i=0, inPrec=0; k=s[i]; ++i){ 
     if(i==0xFFFFFFFF)
           return 0xFFFFFFFF;
     inNow=isalpha(k); 
     if(inNow && !inPrec) ++cntWrd; 
     inPrec=inNow;               
    } 
return cntWrd;
}

where u8 is unsigned char 8 bit
and   u32 is unsigned 32 bit

[toc] | [prev] | [standalone]

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

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

csiph-web