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

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

Two options of a program to find a track in the list

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

Contents

  Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-22 11:30 -0700
    Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-22 14:44 -0400
      Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:16 -0700
        Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:22 -0700
          Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 10:52 +0100
        Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 09:57 +0100
          Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 02:35 -0700
            Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:59 +0100
              Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:42 -0700
              Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:47 -0700
                Re: Two options of a program to find a track in the list Barry Schwarz <schwarzb@dqel.com> - 2015-10-23 11:02 -0700
                Re: Two options of a program to find a track in the list Geoff <geoff@invalid.invalid> - 2015-10-23 11:24 -0700
          Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 10:39 +0100
            Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:03 +0100
              Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 11:21 +0100
                Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:36 +0100
          Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 02:42 -0700
            Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:10 +0100
          Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:24 -0700
            Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 11:45 +0100
              Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:00 -0700
                Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 17:16 +0100
                  Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:47 -0700
          Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 13:19 +0100
            Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 15:38 +0100
              Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 10:57 -0400
                Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 15:59 +0100
                Re: Two options of a program to find a track in the list David Brown <david.brown@hesbynett.no> - 2015-10-23 17:25 +0200
                  Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 11:55 -0400
                    Re: Two options of a program to find a track in the list Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-23 10:45 -0600
                  Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 16:55 +0100
              Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 17:21 +0100
                Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 17:23 +0100
          Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 12:58 -0700
        Re: Two options of a program to find a track in the list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-23 02:19 -0700
          Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:28 +0100
        Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 11:12 +0100
          Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 13:42 -0700
            Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 22:14 +0100
              Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 22:28 +0100
                Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 22:47 +0100
                  Re: Two options of a program to find a track in the list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-23 23:21 +0100
                    Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-24 01:37 +0100
              Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 14:52 -0700
                Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-23 23:06 +0100
                  Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 16:39 -0700
          Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:26 +0100
            Re: Two options of a program to find a track in the list Bartc <bc@freeuk.com> - 2015-10-24 22:28 +0100
              Re: Two options of a program to find a track in the list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 15:26 -0700
                Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 23:44 +0100
        Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 09:03 -0400
          Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:10 -0700
        Re: Two options of a program to find a track in the list Geoff <geoff@invalid.invalid> - 2015-10-23 11:21 -0700
    Re: Two options of a program to find a track in the list Barry Schwarz <schwarzb@dqel.com> - 2015-10-22 14:50 -0700
      Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:25 -0700
        Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:00 +0100
      Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 01:36 -0700
        Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 10:04 +0100
    Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 03:58 -0700
      Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 12:07 +0100
        Re: Two options of a program to find a track in the list Alla _ <modelling.data@gmail.com> - 2015-10-23 09:28 -0700
          Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-23 18:04 +0100
            Re: Two options of a program to find a track in the list Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-23 13:31 -0400
              Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:21 +0100
        Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 13:45 -0700
          Re: Two options of a program to find a track in the list Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:32 +1300
            Re: Two options of a program to find a track in the list Keith Thompson <kst-u@mib.org> - 2015-10-23 15:33 -0700
          Re: Two options of a program to find a track in the list Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:24 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#73566 — Two options of a program to find a track in the list

Hello!

I do apologize in advance, because this will be 
a long message. 

Trying to get to grips with pointers, and other
basic aspects, I have started one more text book 
named Head First C. 

Below I will post two options that should depict 
the same idea.

1) There is a program suggested by the book and printed
out as an example on using strstr function. 

Surprisingly, the program doesn't work: it
should prompt the user to enter a name of a song,
and then search for this song within an existing list.

The program does prompt for the song title, and nothing more;
it doesn't give any output. 

/ Search through tracks to find the entered one

#include <stdio.h>
#include <string.h>

char all_tracks[][80] = {"I left my heart in Harvard Med School", "Newark, Newark - a wonderful town", "Dancing with a Dork", "From here to maternity", "The girl from Iwo Jima"};
int entries = 5; 

/** They didn't have 'int entries = 5' in the book;
they only use number 5 within a for loop below; 
I believe my appending of a global variable
'int entries' can't ruin the program, can it? **/

void find_track (char search_track[])
{
    int i;
    
    for (i = 0; i < entries; i++)
    {
        if (strstr (all_tracks[i], search_track))
            printf ("Track %i: '%s'\n", i, all_tracks[i]);
    }
}

int main (void)
{
    char search[80];
    
    printf ("Enter your track name: ");
    fgets  (search, 80, stdin);
    
    find_track (search);
    
    return 0;
}

2) To test my understanding of the way strings work,
functions operate, and just for the sake of practice,
I decided to do all this 'manually', based on one of 
the programs I picked up much earlier from Programming 
in C textbook.
My version also doesn't work properly. It prompts for 
the name, but when I enter a name that is in the list,
the program prints out its 'Sorry' message, instead of
displaying the title and its number.

/** Search through tracks to find the entered one **/

#include <stdio.h>
#include <stdbool.h>
#include <string.h>

/** Create two global variables; one - to store all existing tracks;
 second - to store the number of tracks **/

char all_tracks[][80] = {"I left my heart in Harvard Med School", "Newark, Newark - a wonderful town", "Dancing with a Dork", "From here to maternity", "The girl from Iwo Jima"};
int entries_number = 5;

/** Prototypes of two functions used in the main function **/
bool equal_strings (char search_track[]);
int lookup_track (char name_entered[]);

int main (void)
{
    char search_track[80]; /** for the track named by the user **/
    int entry;
    
    printf ("Enter your track name: ");
    fgets  (search_track, 79, stdin);
    
    entry = lookup_track (search_track);
    
    if (entry != -1)
        printf ("%s\n", all_tracks[entry]); /** entry should equal the number of 
                                             the 'row' where the track is located **/
    else
        printf ("Sorry, your track is not on the list\n");
    
    return 0;
}

bool equal_strings (char search_track[])
{
    int i, j;
    bool are_equal;
    
    for (i = 0; i < entries_number; i++) /** for each 'row', i.e. number of the track **/
    {
        /** see if every characters (in each 'column') of the track to find is equal to
         every character of any of the existing tracks **/
        
        while (search_track[j] = all_tracks[j] && search_track[j] != '\0' && all_tracks[j] != '\0')
              j++;
        
        if (search_track[j] == '\0' && all_tracks[j] == '\0')
              are_equal = true;
        else
              are_equal = false;
    }
    return are_equal;
}

int lookup_track (char name_entered[])
{
    int i, j, length;
    
    for (i = 0; i < entries_number; i++)
    {
        length = strlen(all_tracks[i]);
        
        for (j = 0; j < length; j++)
        {
            if (equal_strings (name_entered))
                return i; /** return i, not j, because I need the number of the "row",
                           i.e. the track number **/
            return -1;
        }
        
    }
}

Thank you so much!

[toc] | [next] | [standalone]

#73567

On 10/22/2015 2:30 PM, Alla _ wrote:
> Hello!
>
> I do apologize in advance, because this will be
> a long message.
>
> Trying to get to grips with pointers, and other
> basic aspects, I have started one more text book
> named Head First C.
>
> Below I will post two options that should depict
> the same idea.
>
> 1) There is a program suggested by the book and printed
> out as an example on using strstr function.
>
> Surprisingly, the program doesn't work: it
> should prompt the user to enter a name of a song,
> and then search for this song within an existing list.
>
> The program does prompt for the song title, and nothing more;
> it doesn't give any output.
>
> / Search through tracks to find the entered one
>
> #include <stdio.h>
> #include <string.h>
>
> char all_tracks[][80] = {"I left my heart in Harvard Med School", "Newark, Newark - a wonderful town", "Dancing with a Dork", "From here to maternity", "The girl from Iwo Jima"};
> int entries = 5;
>
> /** They didn't have 'int entries = 5' in the book;
> they only use number 5 within a for loop below;
> I believe my appending of a global variable
> 'int entries' can't ruin the program, can it? **/

     No.  There are other possibilities, but this is all right.
One possible improvement:

	int entries = sizeof(all_tracks) / sizeof(all_tracks[0]);

... thus letting the compiler count the number of array elements
for you, instead of doing it yourself (and perhaps getting it
wrong when somebody interrupts you in mid-count).

> void find_track (char search_track[])
> {
>      int i;
>
>      for (i = 0; i < entries; i++)
>      {
>          if (strstr (all_tracks[i], search_track))
>              printf ("Track %i: '%s'\n", i, all_tracks[i]);
>      }
> }
>
> int main (void)
> {
>      char search[80];
>
>      printf ("Enter your track name: ");
>      fgets  (search, 80, stdin);
>
>      find_track (search);
>
>      return 0;
> }
>
> 2) To test my understanding of the way strings work,
> functions operate, and just for the sake of practice,
> I decided to do all this 'manually', based on one of
> the programs I picked up much earlier from Programming
> in C textbook.
> My version also doesn't work properly. It prompts for
> the name, but when I enter a name that is in the list,
> the program prints out its 'Sorry' message, instead of
> displaying the title and its number.

     Almost certainly, this is because what you typed is not
found in any of the track titles.

     "But I typed it EXACTLY right, I checked it THREE times,
I'm SURE it's there!"

     ... and I'm pretty sure it's not.  fgets() stores all the
characters you type (if they fit), including the '\n' at the
end of the line.  Is there a '\n' anywhere in the program's list
of tracks?  No, there is not -- and therefore, nothing matches.

     Your mission (should you decide to accept it): Find the '\n'
that fgets() stored in `search', and get rid of it before trying
to match against the track titles.

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

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

#73584

<snip>

Thank you for your reply. I have few questions.

I.  sizeof(all_tracks) / sizeof(all_tracks[0]);

how does sizeof work with all_tracks, which have a matrix form? 

1) I know that sizeof computes the amount of bytes, 
and includes a terminating null character; hence, when
it returns, for example, 9, it means that there are 8 
characters + the null character. How does 9 fits into 
later computations; does the machine understand that 
the length (the amount) of entries is actually 8 characters
 + the null character?

2) Also, I don't understand how 
sizeof(all_tracks) / sizeof(all_tracks[0]); 
works with a matrix. 

'Sizeof (all_tracks)' - does this pick up all rows, 
thus taking into account only the first bracket (i-th part) 
of all_tracks [] []? 

Wouldn't 'sizeof(all_tracks[0])' return the number of 
characters (which is the number of columns) in this 
particular first row all_tracks[0]?

II. " ... and I'm pretty sure it's not.  fgets() stores all the 
characters you type (if they fit), including the '\n' at the 
end of the line.  Is there a '\n' anywhere in the program's list 
of tracks?  No, there is not -- and therefore, nothing matches. 

     Your mission (should you decide to accept it): Find the '\n' 
that fgets() stored in `search', and get rid of it before trying 
to match against the track titles."

This is amazing, and interesting. I see what you mean.

I've tried to put sizeof(search) instead of 80 in
fgets  (search, 80, stdin); same result:

Allas-MacBook-Pro:headfirst Alla$ ./strstrpage85A
Enter your track name: Dancing with a Dork

And nothing more comes out of this program.

1) They say in the book that "if you are passing a 
pointer to fgets(), do not use sizeof, but enter 
the size you want", because sizeof pointer will be 
always 4 or 8 (by storing only the address of a pointer
itself, and not the address it refers to). Although I do 
not pass a pointer to fgets in this case, I use an integer
instead of sizeof, as they do it in the book. 

But, in case I do pass a pointer and need to use an integer 
in fgets, or I just decide to use an integer, do you think
that using the following might work?

char search[80];
    
    printf ("Enter your track name: ");
    fgets  (search, 80, stdin);
    
    find_track (search [i-1]); 

/** when passing search into find_track function, I subtracted
 the last character that fgets() stores, i.e. supposedly '\n', 
is it correct? **/ 

2) Interestingly enough they do not have any such problem
in the book - neither do they mention it, nor does it 
effect their code, which I reproduced word for word. I 
wonder if this '\n' is the issue in my case, although 
it does sound plausible.  

Thank you!

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

#73585

On Friday, October 23, 2015 at 12:16:39 PM UTC+4, Alla _ wrote:
> <snip>
> 
> Thank you for your reply. I have few questions.
> 
> I.  sizeof(all_tracks) / sizeof(all_tracks[0]);
> 
> how does sizeof work with all_tracks, which have a matrix form? 
> 
> 1) I know that sizeof computes the amount of bytes, 
> and includes a terminating null character; hence, when
> it returns, for example, 9, it means that there are 8 
> characters + the null character. How does 9 fits into 
> later computations; does the machine understand that 
> the length (the amount) of entries is actually 8 characters
>  + the null character?
> 
> 2) Also, I don't understand how 
> sizeof(all_tracks) / sizeof(all_tracks[0]); 
> works with a matrix. 
> 
> 'Sizeof (all_tracks)' - does this pick up all rows, 
> thus taking into account only the first bracket (i-th part) 
> of all_tracks [] []? 
> 
> Wouldn't 'sizeof(all_tracks[0])' return the number of 
> characters (which is the number of columns) in this 
> particular first row all_tracks[0]?
> 
> II. " ... and I'm pretty sure it's not.  fgets() stores all the 
> characters you type (if they fit), including the '\n' at the 
> end of the line.  Is there a '\n' anywhere in the program's list 
> of tracks?  No, there is not -- and therefore, nothing matches. 
> 
>      Your mission (should you decide to accept it): Find the '\n' 
> that fgets() stored in `search', and get rid of it before trying 
> to match against the track titles."
> 
> This is amazing, and interesting. I see what you mean.
> 
> I've tried to put sizeof(search) instead of 80 in
> fgets  (search, 80, stdin); same result:
> 
> Allas-MacBook-Pro:headfirst Alla$ ./strstrpage85A
> Enter your track name: Dancing with a Dork
> 
> And nothing more comes out of this program.
> 
> 1) They say in the book that "if you are passing a 
> pointer to fgets(), do not use sizeof, but enter 
> the size you want", because sizeof pointer will be 
> always 4 or 8 (by storing only the address of a pointer
> itself, and not the address it refers to). Although I do 
> not pass a pointer to fgets in this case, I use an integer
> instead of sizeof, as they do it in the book. 
> 
> But, in case I do pass a pointer and need to use an integer 
> in fgets, or I just decide to use an integer, do you think
> that using the following might work?
> 
> char search[80];
>     
>     printf ("Enter your track name: ");
>     fgets  (search, 80, stdin);
>     
>     find_track (search [i-1]); 
> 
> /** when passing search into find_track function, I subtracted
>  the last character that fgets() stores, i.e. supposedly '\n', 
> is it correct? **/ 
> 
> 2) Interestingly enough they do not have any such problem
> in the book - neither do they mention it, nor does it 
> effect their code, which I reproduced word for word. I 
> wonder if this '\n' is the issue in my case, although 
> it does sound plausible.  
> 
> Thank you!


I have just tried to use the
find_track (search [i-1]); 

And have the following messages.
When I compile the program, I get a warning:

strstrpage85A.c: In function 'main':
strstrpage85A.c:28: warning: passing argument 1 of 'find_track' makes pointer from integer without a cast

If I understand it correctly (if it is what is written), then
[i-1] turns search[i-1] to a pointer. Why and how?

Then, I get a segmentation error:

Allas-MacBook-Pro:headfirst Alla$ ./strstrpage85A
Enter your track name: Dancing with a Dork
Segmentation fault: 11

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

#73596

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

> On Friday, October 23, 2015 at 12:16:39 PM UTC+4, Alla _ wrote:
<snip>
>> char search[80];
>>     
>>     printf ("Enter your track name: ");
>>     fgets  (search, 80, stdin);
>>     
>>     find_track (search [i-1]); 
<snip>
> I have just tried to use the
> find_track (search [i-1]); 
>
> And have the following messages.
> When I compile the program, I get a warning:
>
> strstrpage85A.c: In function 'main':
> strstrpage85A.c:28: warning: passing argument 1 of 'find_track' makes
> pointer from integer without a cast
>
> If I understand it correctly (if it is what is written), then
> [i-1] turns search[i-1] to a pointer. Why and how?

'search' is an array name.  In most situations it will be converted into
a pointer -- in this case a pointer to char.  search[i-1] indexes that
pointer to get a specific char.  C considers char to be an integer type
(characters are just small-valued integers) so the message is telling
you you passed something integer-like (a char) where something
pointer-like (a char *) was expected.

> Then, I get a segmentation error:
>
> Allas-MacBook-Pro:headfirst Alla$ ./strstrpage85A
> Enter your track name: Dancing with a Dork
> Segmentation fault: 11

That's good.  It means the program tried to access some part of the
memory that it does not have permission to access.  That often happens
when you take a small integer and force the machine to think of it as an
address (i.e. as a pointer).  You are not always fortunate enough to get
a segmentation fault -- sometimes the integer looks like a proper
address, and the program carries on, creating chaos by fiddling with
parts of the memory you never intended it to access.  Those errors (and
you will make many -- we all do) are very much harder to track down.

-- 
Ben.

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

#73588

On 23/10/15 09:16, Alla _ wrote:
> <snip>
>
> Thank you for your reply. I have few questions.
>
> I.  sizeof(all_tracks) / sizeof(all_tracks[0]);

The parentheses are superfluous and serve no purpose at all.

sizeof all_tracks / sizeof all_tracks[0]

works just fine.

> how does sizeof work with all_tracks, which have a matrix form?

sizeof is an operator that yields the size, in bytes, of its operand. It 
works on any object, whether an array or otherwise.

When you divide the size of an array (in bytes) by the size of one 
element of that array (in bytes), you get the number of elements in the 
array.

> 1) I know that sizeof computes the amount of bytes,
> and includes a terminating null character;

Well, it includes the whole object. It doesn't care what value that 
object has. Null terminating characters are irrelevant to sizeof.

If you have

char foo[32] = "Hello.";

strlen(foo) will give you a result of 6, but sizeof foo will give you a 
result of 32.

> hence, when
> it returns, for example, 9, it means that there are 8
> characters + the null character.

No, it means that the object is 9 bytes in size. Whether it is populated 
with an eight-character string with a ninth character as the null, or a 
two-character string with a terminating null, or even nine characters 
without a terminating null, is of no consequence to sizeof.

> How does 9 fits into
> later computations; does the machine understand that
> the length (the amount) of entries is actually 8 characters
>   + the null character?

It doesn't. If it matters to you, you remember it (in an object):

size_t arraysize = sizeof array / sizeof array[0];

and then use arraysize in later computations.

>
> 2) Also, I don't understand how
> sizeof(all_tracks) / sizeof(all_tracks[0]);
> works with a matrix.

Consider a simple example:

unsigned long myarray[17];

size_t arraysize = sizeof myarray;

Probably gives 4 * 17 = 68 bytes, although it might give 8 * 17 = 136 
bytes on some systems.

size_t elementsize = sizeof myarray[0];

Probably gives 4, but it might give 8 on some systems. Whichever it is 
will be consistent with the previous answer.

arraysize / elementsize will always be 17 (for this example).

>
> 'Sizeof (all_tracks)' - does this pick up all rows,
> thus taking into account only the first bracket (i-th part)
> of all_tracks [] []?

It gives the size of the whole array, in bytes.

> Wouldn't 'sizeof(all_tracks[0])' return the number of
> characters (which is the number of columns) in this
> particular first row all_tracks[0]?

It would give the size of one element of the array.

You seem to think that sizeof cares about how long your strings are. It 
doesn't. It only cares about how much space has been allocated for the 
array.

>
> II. " ... and I'm pretty sure it's not.  fgets() stores all the
> characters you type (if they fit), including the '\n' at the
> end of the line.  Is there a '\n' anywhere in the program's list
> of tracks?  No, there is not -- and therefore, nothing matches.
>
>       Your mission (should you decide to accept it): Find the '\n'
> that fgets() stored in `search', and get rid of it before trying
> to match against the track titles."
>
> This is amazing, and interesting. I see what you mean.
>
> I've tried to put sizeof(search) instead of 80 in
> fgets  (search, 80, stdin); same result:

Better:

if(fgets(search, sizeof search, stdin) != NULL)

fgets will never write more characters into search than you tell it it 
can. This will always include a null character. If there is room, it 
will also include a newline character (because you typed one when you 
hit ENTER). So if there isn't a newline character, it wouldn't fit, 
which means there's more data to process from that input line.

If there *is* a newline character and your internal data doesn't include 
newlines (often the case), you need to remove it. You can do so in this way:

#include <string.h>
void terminate_at_newline(char *s)
{
   if(s != NULL)
   {
     char *t = strchr(s, '\n');
     if(t != NULL)
     {
       *t = '\0';
     }
   }
}

> 1) They say in the book that "if you are passing a
> pointer to fgets(), do not use sizeof, but enter
> the size you want",

Well, what /else/ are you going to pass to fgets (in its first 
parameter)? What the book means is that, if you do something like this:

char *mybuf = malloc(mysize);

sizeof mybuf will give, not mysize, but the size of the pointer 
('mybuf'). In such a situation, you would want to pass mysize, not 
sizeof mybuf.

> But, in case I do pass a pointer and need to use an integer
> in fgets, or I just decide to use an integer, do you think
> that using the following might work?
>
> char search[80];
>
>      printf ("Enter your track name: ");
>      fgets  (search, 80, stdin);

Well, search is an array, so sizeof will work just fine. The problem 
with 80 is that, if you later change your array to:

char search[60];

and forget to update the fgets call appropriately, you run the risk of a 
buffer overrun. That's why we use sizeof.

>      find_track (search [i-1]);
>
> /** when passing search into find_track function, I subtracted
>   the last character that fgets() stores, i.e. supposedly '\n',
> is it correct? **/

No. Your i value is an 'entries' number, not a string length. The 
question betrays complete confusion about what your program is doing. 
(Sorry, but it's true.)

If I'd been your teacher, you would not be asking the question, because 
you wouldn't have got this far without fully understanding everything 
that had gone before.

>
> 2) Interestingly enough they do not have any such problem
> in the book - neither do they mention it, nor does it
> effect their code, which I reproduced word for word. I
> wonder if this '\n' is the issue in my case, although
> it does sound plausible.

'\n' isn't an issue. It's a tool, and a very useful one. It tells us 
useful information about where a line's data ends. We need to use that 
information, and then (where appropriate) remove the newline from the 
computer's internal image of that data.

Build up from first principles.

A text file comprises 1 or more lines (some would argue for 0 or more).

A line comprises 0 or more characters followed by a newline character. 
(That is, each line contains exactly one newline character, which is at 
the end.)

When you are reading a line, you don't know in advance how long it will 
be, so you keep reading until you hit a newline character. When (as now) 
you're learning, the easiest way to do this is to make your input buffer 
*way* bigger than the longest line in your test data. (Later, you would 
need to learn to be more thorough.)

Having read an entire line into memory (which you can check by looking 
for the newline character), you don't need the newline any more, so you 
can remove it (as shown earlier in this article), so that your 
comparisons of that line with your internal dictionary stand a chance of 
succeeding.

By the way, did you find the bug in this line?

while (search_track[j] = all_tracks[j] && search_track[j] != '\0' && 
all_tracks[j] != '\0')

If not, it's worth your while to slow down a little and take a closer 
look at that line of code. Hint: one of your operators is wrong.

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

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

#73593

<snip>
Thank you very much for your reply. Please, take a look 
at my question below. Please, read till the end, because,
hopefully, I have reached some understanding.

"When you divide the size of an array (in bytes) by the size of one 
element of that array (in bytes), you get the number of elements in the 
array."

Yes. This what causes my confusion. The array 'all_tracks'
is a matrix by its structure: there are 5 rows, i.e. 5 tracks, and 
variable amount of columns in each row, because each name
has a different number of characters in it. Therefore, 

1)	does 'sizeof all_tracks[0]' computes, in bytes, how much
space all characters, i.e. all columns in row 0, occupy? 
2)	does 'sizeof all_tracks' compute the amount of space that all
5 tracks, including all characters in their names, occupy? 

If so (but obviously I am wrong, and don't yet understand the way
it works), then dividing 'sizeof all_tracks' by 'sizeof all_tracks[0]' can't
yield a correct result - each track occupies different space
because of the different number of characters in them. 

It would, of course, yield a correct result, if 'sizeof all_tracks[0]' 
produced the size of only one (first) character of the string, which is 
char in this case, and occupies 1 byte. 

This is why I don't understand how sizeof works with matrices.
 
On the other hand, I have just realized, does it means that 
'sizeof all_tracks[0]' equals not to the first row, but to the first
character, which is 'I' ? Hence, 'sizeof all_tracks' is divided by 
the size of one character, which is 1 byte. Is this correct?

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

#73597

On 23/10/15 10:35, Alla _ wrote:
> <snip>
> Thank you very much for your reply. Please, take a look
> at my question below. Please, read till the end, because,
> hopefully, I have reached some understanding.
>
> "When you divide the size of an array (in bytes) by the size of one
> element of that array (in bytes), you get the number of elements in the
> array."
>
> Yes. This what causes my confusion. The array 'all_tracks'
> is a matrix by its structure: there are 5 rows, i.e. 5 tracks, and
> variable amount of columns in each row,

No, you have an array of five 80-element arrays. That not every element 
is used is irrelevant - each of your five arrays has space for 80 
characters.

Thus:

sizeof all_tracks is 5 * 80 * 1 = 400
sizeof all_tracks[0] is 80 * 1 = 80
sizeof all_tracks / sizeof all_tracks[0] is 400 / 80 = 5

> because each name
> has a different number of characters in it.

But each has the /space/ for 80 characters, even though you're not using 
all that space.

<snip>

> On the other hand, I have just realized, does it means that
> 'sizeof all_tracks[0]' equals not to the first row, but to the first
> character, which is 'I' ?

No, all_tracks is an array of five 80-character arrays. all_tracks[0] is 
the first of those 80-character arrays, and so its size is 80 
characters. Since a character (char) is defined to be 1 byte in size, 
and since 80 * 1 is 80, sizeof all_tracks[0] is 80.


> Hence, 'sizeof all_tracks' is divided by
> the size of one character,

No, in the expression

sizeof all_tracks / sizeof all_tracks[0]

the size of the five-element array (size 5 * 80 = 400) is divided by the 
size of its first element (an 80-element array), yielding a result of 5 
(the number of elements in the all_tracks array).

> which is 1 byte. Is this correct?

Well, that bit is, yes! Characters are 1 byte in size, by definition, 
and a byte (in C) is defined to be at least 8 bits wide.

It might help for you to see your array written like this:
char all_tracks[][80] =
{
   "I left my heart in Harvard Med School",
   "Newark, Newark - a wonderful town",
   "Dancing with a Dork",
   "From here to maternity",
   "The girl from Iwo Jima"
};

This makes it clearer that you have five elements.

I'm going to show you how the array is organised by displaying it in a 
rather different way (thus breaking the C syntax - this is just an 
illustration, not code!).

For the sake of brevity, I'm going to use 40 rather than 80 but the 
principle is the same. I'll replace the quotes with | and indicate a 
null terminating character using @, and an unused character using _:

char all_tracks[][40] =
{
   |I left my heart in Harvard Med School@__|,
   |Newark, Newark - a wonderful town@______|,
   |Dancing with a Dork@____________________|,
   |From here to maternity@_________________|,
   |The girl from Iwo Jima@_________________|
};

Does that make things a little clearer?

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

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

#73605

<snip> 
Thank you very much. I understand it now. 
Such a relief - at least this bit is clear :)

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

#73608

> It might help for you to see your array written like this:
> char all_tracks[][80] =
> {
>    "I left my heart in Harvard Med School",
>    "Newark, Newark - a wonderful town",
>    "Dancing with a Dork",
>    "From here to maternity",
>    "The girl from Iwo Jima"
> };
> 
This was also among my questions. I wanted to write
all tracks in the list-like manner, as you did here. 
I did so, but then when the compiler got upset with my
code, I decided to put all tracks in one line, thinking
that '\n\ might be confusing for the machine.

Then I found the notion of carriage return \r;
tried it; didn't work for an obvious reason of 
incorrect usage and, yet again, misunderstanding;
quit it for now, because, as you and Ben have mentioned,
I am missing ground understanding and getting inundated 
with different, though interesting and useful, features. 

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

#73642

On Fri, 23 Oct 2015 03:47:42 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

>
>> It might help for you to see your array written like this:
>> char all_tracks[][80] =
>> {
>>    "I left my heart in Harvard Med School",
>>    "Newark, Newark - a wonderful town",
>>    "Dancing with a Dork",
>>    "From here to maternity",
>>    "The girl from Iwo Jima"
>> };
>> 
>This was also among my questions. I wanted to write
>all tracks in the list-like manner, as you did here. 
>I did so, but then when the compiler got upset with my
>code, I decided to put all tracks in one line, thinking
>that '\n\ might be confusing for the machine.

Ignoring quoted string literals for the moment, in terms of syntax
within your source code, white space is ignored by the compiler.
Space, tab, carriage return, and new line are all white space.  (Look
up the isspace function in your reference.)  That is why statements
and declarations must be terminated with a semicolon.

Thus, all of the following c statements are equivalent:

#1   x=y;
#2   x = y;
#3   x                         =                             y;
#4   x= /*there is a tab character here*/ y;
#5   x =
                    y;
#6   x
           =
                    y;
>
>Then I found the notion of carriage return \r;
>tried it; didn't work for an obvious reason of 
>incorrect usage and, yet again, misunderstanding;
>quit it for now, because, as you and Ben have mentioned,
>I am missing ground understanding and getting inundated 
>with different, though interesting and useful, features. 

As several of us have tried to point out, you are trying to run before
you can walk.

-- 
Remove del for email

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

#73645

On Fri, 23 Oct 2015 03:47:42 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

>I decided to put all tracks in one line, thinking
>that '\n\ might be confusing for the machine.

You can never confuse the machine. 
The machine can always confuse you. :)

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

#73594

Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> [...] If it matters to you, you remember it (in an object):
>
> size_t arraysize = sizeof array / sizeof array[0];

Just a quick point: that's not a good name because it confuses two
possible meanings of 'size': size in bytes and a less technical meaning
of size in terms of the number of elements.

I know you just have to pick a name out of thin air when there is no
surrounding program, but in this particular case, where the question is
all about the 'sizeof' various objects, it seems worth pointing out.

<snip>
> If I'd been your teacher, you would not be asking the question,
> because you wouldn't have got this far without fully understanding
> everything that had gone before.

And, since I'm already replying...  That may be your preference, but I
think you should also ask if it is shared by the student.  Some students
want to move on without fully understanding everything (usually because
they get bored otherwise) and they hope (and often find) that things
fall into place.  Others don't, of course, but I don't think there's a
hard and fast rule that's good for everyone.  (All this assumes the
luxury of one-to-one tuition.  In a class, you can never suit everyone
in terms of pace.)

<snip>
-- 
Ben.

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

#73598

On 23/10/15 10:39, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>> [...] If it matters to you, you remember it (in an object):
>>
>> size_t arraysize = sizeof array / sizeof array[0];
>
> Just a quick point: that's not a good name because it confuses two
> possible meanings of 'size': size in bytes and a less technical meaning
> of size in terms of the number of elements.
>
> I know you just have to pick a name out of thin air when there is no
> surrounding program, but in this particular case, where the question is
> all about the 'sizeof' various objects, it seems worth pointing out.

Yep, I'll buy that. number_of_elements would have been better (but still 
not perfect).

>
> <snip>
>> If I'd been your teacher, you would not be asking the question,
>> because you wouldn't have got this far without fully understanding
>> everything that had gone before.
>
> And, since I'm already replying...  That may be your preference, but I
> think you should also ask if it is shared by the student.

The proof of the pudding is in the articles. Alla is showing every sign 
of having learned too much too fast, as lots of different concepts are 
being mixed up together in bizarre ways.

<snip>

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

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

#73602

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

> On 23/10/15 10:39, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
>>> If I'd been your teacher, you would not be asking the question,
>>> because you wouldn't have got this far without fully understanding
>>> everything that had gone before.
>>
>> And, since I'm already replying...  That may be your preference, but I
>> think you should also ask if it is shared by the student.
>
> The proof of the pudding is in the articles. Alla is showing every
> sign of having learned too much too fast, as lots of different
> concepts are being mixed up together in bizarre ways.

Yes, that seems likely, but someone learning too fast can be slowed down
without requiring that they fully understand everything that has gone
before.  I was commenting on what looked to me to be a extremist
position!

-- 
Ben.

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

#73604

On 23/10/15 11:21, Ben Bacarisse wrote:

<snip>

> I was commenting on what looked to me to be a extremist
> position!

Extremist positions are the only kind worth holding. :-)

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

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

#73595

> If I'd been your teacher, you would not be asking the question, because 
> you wouldn't have got this far without fully understanding everything 
> that had gone before.
> 
I haven't yet studied all the rest of this message,
but I would like to answer this statement. You are absolutely
right, as usual. Being flustered by lack of understanding of 
ground principles (my post on pointers was the last drop :), 
I have found one more book, and started reading and coding all
over again in hope, still scant one, to reach deeper understanding.

Didn't work yet, did it? ))) 

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

#73599

On 23/10/15 10:42, Alla _ wrote:
>
>> If I'd been your teacher, you would not be asking the question, because
>> you wouldn't have got this far without fully understanding everything
>> that had gone before.
>>
> I haven't yet studied all the rest of this message,
> but I would like to answer this statement. You are absolutely
> right, as usual. Being flustered by lack of understanding of
> ground principles (my post on pointers was the last drop :),
> I have found one more book, and started reading and coding all
> over again in hope, still scant one, to reach deeper understanding.
>
> Didn't work yet, did it? )))

You'll get there. You're stubborn enough and you're bright enough. Now 
it's just a matter of finding the right path through the quagmire.

It's no good - I'm going to have to write a C tutorial, aren't I? Yes, 
there's nothing this world needs more than Yet Another C Tutorial.

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

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

#73603

<snip>

I am trying to understand the logic and meaning 
of this code. One line is not clear to me:

#include <string.h> 

void terminate_at_newline(char *s) 

/** char *s is a pointer to some char variable, 
the address in memory of that
char variable; using this address I can access the 
value of that variable and change it,
if needed **/

{ 
   if(s != NULL) /** take into account all characters 
except the null character, '\0'**/
                          
   { 
     char *t = strchr(s, '\n');  /** declare a pointer 't' 
that finds and points to the address (location) of a character 
's' if this character is '\n' **/

     if(t != NULL)  /** I don't understand this one; I read 
'if 't' isn't Null' as 't' being any character but null; 
how can 't' point at null, or at any other character, if 't' 
points at the ENTER character, i.e. '\n'? **/
     { 
       *t = '\0';  /** if 't' is not NULL, the value at the 
address 't' points to should be assigned the NULL value **/
     } 
   } 
} 

"By the way, did you find the bug in this line?

while (search_track[j] = all_tracks[j] && search_track[j] != '\0' &&
all_tracks[j] != '\0')

If not, it's worth your while to slow down a little and take a closer
look at that line of code. Hint: one of your operators is wrong."

Yes! :) while (search_track[j] = all_tracks[j]... 
Should be while (search_track[j] == all_tracks[j]..

I had the same issue with all if statements in the program,
spotted and corrected them, but didn't yet notice that while condition
was also buggy :) Thank you!

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

#73606

On 23/10/15 11:24, Alla _ wrote:
> <snip>
>
> I am trying to understand the logic and meaning
> of this code. One line is not clear to me:

Okay.

> #include <string.h>
>
> void terminate_at_newline(char *s)
>
> /** char *s is a pointer to some char variable,

Right. And, since (in a string) chars occupy contiguous positions in 
memory, you can also access the chars that follow that one (if you're 
careful).

> the address in memory of that
> char variable; using this address I can access the
> value of that variable and change it,
> if needed **/

Right.

>
> {
>     if(s != NULL) /** take into account all characters
> except the null character, '\0'**/

No. NULL is a pointer value. It means "guaranteed not to point at any 
object". We must never de-reference NULL - that is, never do '*NULL'.

The code is checking to ensure that you have /not/ passed such a pointer 
value to this function because, if you have, this function can't do 
anything sensible with it.

This is what we were talking about a few days ago - protecting your code 
against invalid inputs.

>
>     {
>       char *t = strchr(s, '\n');  /** declare a pointer 't'
> that finds and points to the address (location) of a character
> 's' if this character is '\n' **/

Almost. s points to the first character in a string: for example, the 
'H' in "Hello, world!\n".

strchr starts searching at that first character, and keeps searching 
until it finds either the character you're looking for ('\n') or a null 
character. If it finds the null character first, it returns a null 
POINTER, not the null character! But if it finds the '\n' first, it 
returns a pointer to that '\n' character.

>
>       if(t != NULL)  /** I don't understand this one; I read
> 'if 't' isn't Null' as 't' being any character but null;

No, t is a pointer. if(t != NULL) is checking that strstr actually found 
the newline (because, if it did, t won't be NULL).

> how can 't' point at null, or at any other character, if 't'
> points at the ENTER character, i.e. '\n'? **/

Well, if it does point at '\n', it won't be NULL. But if there wasn't a 
'\n' character to point at, it will be NULL. Note that we spell the 
special pointer value NULL in capital letters, which helps us to 
distinguish it from another use of the word, as in "null terminating 
character".

'\0' is the null terminating character. NULL is a pointer value, not a 
character.

>       {
>         *t = '\0';  /** if 't' is not NULL, the value at the
> address 't' points to should be assigned the NULL value **/

Almost. If t is not a null pointer (i.e. NULL), then the value at the 
address t points to should be assigned the value of a null terminating 
character.

I realise that this is an unfortunate situation - that the word "null" 
should be used in two such very different situations and for very 
different reasons - but that's life.

<snip>

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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web