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

#73659

On 23/10/2015 22:28, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 23/10/2015 21:42, Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
>>> [...]
>>>> #define SHOWSIZE(A) printf("SIZE: %s: %d bytes\n",#A,sizeof(A));
>>> [...]
>>>
>>> That %d should be %zu.
>>
>> You need to complain to my compiler. Only two C compilers out of 6
>> said anything. The default one I use didn't.
>
> Surely you are the appropriate person to complain if a compiler misses
> an error you'd like to have diagnosed?  (I'm assuming you don't
> mean "I don't care" which was my first reading of what you wrote.)

Well, I care in that the code could crash if given the wrong format 
(perhaps not the example above). I'd quite like it to be diagnosed, but 
don't care enough to dig through the various gcc options for a way to 
turn on the warning (and I would then have to modify my IDE to insert it).

>> (Personally I don't even want to be bothered to have to put in "%d".)
>
> You might like the way Go does it.

Yes, a quick glance suggests it does what has been been proposed here a 
few times, which is to select a default format based on the type of 
whatever is being printed. You don't need to worry about adding long or 
long long modifiers any more either.

Of course an even nicer way, which is what I normally use, is not to 
have to write any format code at all.

-- 
Bartc

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

#73665

Bartc <bc@freeuk.com> writes:

> On 23/10/2015 22:28, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 23/10/2015 21:42, Keith Thompson wrote:
>>>> Bartc <bc@freeuk.com> writes:
>>>> [...]
>>>>> #define SHOWSIZE(A) printf("SIZE: %s: %d bytes\n",#A,sizeof(A));
>>>> [...]
>>>>
>>>> That %d should be %zu.
>>>
>>> You need to complain to my compiler. Only two C compilers out of 6
>>> said anything. The default one I use didn't.
>>
>> Surely you are the appropriate person to complain if a compiler misses
>> an error you'd like to have diagnosed?  (I'm assuming you don't
>> mean "I don't care" which was my first reading of what you wrote.)
>
> Well, I care in that the code could crash if given the wrong format
> (perhaps not the example above). I'd quite like it to be diagnosed,
> but don't care enough to dig through the various gcc options for a way
> to turn on the warning (and I would then have to modify my IDE to
> insert it).

-Wformat

>>> (Personally I don't even want to be bothered to have to put in "%d".)
>>
>> You might like the way Go does it.
>
> Yes, a quick glance suggests it does what has been been proposed here
> a few times, which is to select a default format based on the type of
> whatever is being printed. You don't need to worry about adding long
> or long long modifiers any more either.
>
> Of course an even nicer way, which is what I normally use, is not to
> have to write any format code at all.

You don't have specify any format string in Go either.

-- 
Ben.

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

#73669

On 23/10/2015 23:21, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 23/10/2015 22:28, Ben Bacarisse wrote:

>>> You might like the way Go does it.
>>
>> Yes, a quick glance suggests it does what has been been proposed here
>> a few times, which is to select a default format based on the type of
>> whatever is being printed. You don't need to worry about adding long
>> or long long modifiers any more either.
>>
>> Of course an even nicer way, which is what I normally use, is not to
>> have to write any format code at all.
>
> You don't have specify any format string in Go either.

You mean using 'fmt.Print'? The first part of those docs mentioned 
format specifiers a lot.

Well, that's how it should be. And there aren't many technical obstacles 
to taking that kind of approach.

It's odd then how much opposition there is in c.l.c to having something 
better than printf. There is a lot of fiddly detail needed even for a 
quick throwaway printf.


-- 
Bartc

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

#73660

Bartc <bc@freeuk.com> writes:
> On 23/10/2015 21:42, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> #define SHOWSIZE(A) printf("SIZE: %s: %d bytes\n",#A,sizeof(A));
>> [...]
>>
>> That %d should be %zu.
>
> You need to complain to my compiler. Only two C compilers out of 6 said 
> anything. The default one I use didn't.

It's likely to "work" if the size doesn't exceed INT_MAX, and if size_t
and int arguments are passed to printf in a sufficiently similar way.

On the other hand, if you use "%zu" it just works (unless you're using
an old runtime library that doesn't support it, and in that case you can
use a cast).

> (Personally I don't even want to be bothered to have to put in "%d".)

Is using the correct format that much worse?

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

#73663

On 23/10/2015 22:52, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 23/10/2015 21:42, Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
>>> [...]
>>>> #define SHOWSIZE(A) printf("SIZE: %s: %d bytes\n",#A,sizeof(A));
>>> [...]
>>>
>>> That %d should be %zu.
>>
>> You need to complain to my compiler. Only two C compilers out of 6 said
>> anything. The default one I use didn't.
>
> It's likely to "work" if the size doesn't exceed INT_MAX, and if size_t
> and int arguments are passed to printf in a sufficiently similar way.

There are problems when size_t is 8 bytes and int is 4 bytes, for 
example, and a further format code follows. The unexpected extra top 4 
bytes of the size_t value will screw up those extra arguments.

> On the other hand, if you use "%zu" it just works (unless you're using
> an old runtime library that doesn't support it, and in that case you can
> use a cast).

Suppose someone puts in an extra %s at the end of the format string, 
without a matching argument. Then remembering all these fancy format 
codes is not going to help. It really needs the compiler to diagnose this.

-- 
Bartc

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

#73668

Bartc <bc@freeuk.com> writes:
> On 23/10/2015 22:52, Keith Thompson wrote:
[...]
>> On the other hand, if you use "%zu" it just works (unless you're using
>> an old runtime library that doesn't support it, and in that case you can
>> use a cast).
>
> Suppose someone puts in an extra %s at the end of the format string,
> without a matching argument. Then remembering all these fancy format
> codes is not going to help. It really needs the compiler to diagnose
> this.

Yes, an extra %s at the end of a format string can cause Bad Things To
Happen.

If that's relevant to using %d vs. %zu for a size_t argument, I don't
see how.  If you're arguing that printf format strings are ugly and
error-prone, I think we're all already aware of that.

gcc warns if you use -Wformat (or -Wall, which includes -Wformat).  (I
usually use -Wall, so I hadn't noticed that it's not enabled by
default.)

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

#73736

On 23/10/15 11:12, Bartc wrote:
> On 23/10/2015 09:16, Alla _ wrote:
>> <snip>
>>
>> 2) Also, I don't understand how
>> sizeof(all_tracks) / sizeof(all_tracks[0]);
>> works with a matrix.
>
> It confuses me too.

Don't give up the day job.

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

#73741

On 24/10/2015 21:26, Richard Heathfield wrote:
> On 23/10/15 11:12, Bartc wrote:
>> On 23/10/2015 09:16, Alla _ wrote:
>>> <snip>
>>>
>>> 2) Also, I don't understand how
>>> sizeof(all_tracks) / sizeof(all_tracks[0]);
>>> works with a matrix.
>>
>> It confuses me too.
>
> Don't give up the day job.

Part of my day job used to be trying to make this stuff simpler. (In the 
form of easier coding both for me, and for anyone who used some of my 
applications' scripting languages.)

Obtaining the number of elements in array A had never been more 
complicated for me than writing A.len. Until I started using C, when it 
become necessary to write something along the lines of:

   sizeof(A)/sizeof(A[0])

(Parentheses can be omitted if one remembers; but then, the array name 
won't usually be as simple as 'A'.)

This construct involves two ranks of dimension. In the case of a 2D 
array B, it refers to both the table, and a row. This really doesn't 
help. The size of one of the rows would be, I think: 
sizeof(B[0])/sizeof(B[0][0]);

Others agree with me which is why many languages, including Go, allow 
you to write something like:

   len(A)

(and len(B[0]) for the length of a row of B).

Perhaps the creators of Go should all be fired too!

-- 
Bartc

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

#73743

On Saturday, October 24, 2015 at 10:29:30 PM UTC+1, Bart wrote:
> On 24/10/2015 21:26, Richard Heathfield wrote:
> > On 23/10/15 11:12, Bartc wrote:
> >> On 23/10/2015 09:16, Alla _ wrote:
> >>> <snip>
> >>>
> >>> 2) Also, I don't understand how
> >>> sizeof(all_tracks) / sizeof(all_tracks[0]);
> >>> works with a matrix.
> >>
> >> It confuses me too.
> >
> > Don't give up the day job.
> 
> Part of my day job used to be trying to make this stuff simpler. (In the 
> form of easier coding both for me, and for anyone who used some of my 
> applications' scripting languages.)
> 
> Obtaining the number of elements in array A had never been more 
> complicated for me than writing A.len. Until I started using C, when it 
> become necessary to write something along the lines of:
> 
>    sizeof(A)/sizeof(A[0])
> 
In this case, the question is all_tracks works with a "matrix". That 
makes things a bit tricky. There are lots of reasonable ways of
setting up matrices in C, and it's not obvious whether the expression
is intended to return the number of matrices in matrix stack A, the 
number of elements in matrix A, or the number of rows in matrix A.

It's very confusing, and the real answer is not to write C code like
that. If A is in scope, the other values will also be in scope,
so use them.
 

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

#73744

On 24/10/15 23:26, Malcolm McLean wrote:
> On Saturday, October 24, 2015 at 10:29:30 PM UTC+1, Bart wrote:
>> On 24/10/2015 21:26, Richard Heathfield wrote:
>>> On 23/10/15 11:12, Bartc wrote:
>>>> On 23/10/2015 09:16, Alla _ wrote:
>>>>> <snip>
>>>>>
>>>>> 2) Also, I don't understand how
>>>>> sizeof(all_tracks) / sizeof(all_tracks[0]);
>>>>> works with a matrix.
>>>>
>>>> It confuses me too.
>>>
>>> Don't give up the day job.
>>
>> Part of my day job used to be trying to make this stuff simpler. (In the
>> form of easier coding both for me, and for anyone who used some of my
>> applications' scripting languages.)
>>
>> Obtaining the number of elements in array A had never been more
>> complicated for me than writing A.len. Until I started using C, when it
>> become necessary to write something along the lines of:
>>
>>     sizeof(A)/sizeof(A[0])
>>
> In this case, the question is all_tracks works with a "matrix". That
> makes things a bit tricky.

No, not really. The solution is very simple: when you create an object, 
you know how big it is, so *don't forget*. The sizeof/sizeof idiom is 
fine for fixed-size arrays a la foo[][X]. For dynamically allocated 
arrays, you have to have a number to pass to malloc, so just remember 
that number somewhere. Job done.

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

#73618

On 10/23/2015 4:16 AM, 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?

     For context, the declaration was

	char all_tracks[][80] = { ... initializers ... };

As you'd expect: sizeof(all_tracks) is the number of bytes of memory
devoted to all_tracks.  Also, sizeof(all_tracks[0]) is the number of
bytes devoted to all_tracks[0], that is, it is 80.  Divide the grand
total amount of memory by the amount used for one element, and you
get the number of elements.

     Note: In sizeof(all_tracks) and sizeof(all_tracks[0]), the
parentheses are optional.  I've inserted them just for ease of reading;
they could just as well have been omitted:

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

Use 'em or lose 'em as your taste dictates.  However, when you apply
sizeof to a type name (rather than to an expression), the parentheses
are required:

	int doubleBytes = sizeof double;  // Wrong!
	int doubleBytes = sizeof(double);  // Right.

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

     sizeof has nothing to do with, and no knowledge of, the contents
that may happen to be stored in the object whose size it computes.
All sizeof does is tell you how many bytes are set aside, not what
may or may not be in those bytes.

     For a char[] array that happens to contain a string, it follows
that sizeof must be greater than strlen().  This is because strlen()
stops as soon as it finds the '\0', while sizeof stops for nothing.

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

     I think I've covered this, above.  For emphasis: sizeof reports
*all* the bytes of the object, whether they are part of a string's
"payload" or not.

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

     Because the '\n' is still present in the search string, but
not in the material being searched.  You won't get rid of the '\n'
by any shenanigans with sizeof; you'll need to search for it (the
strchr() function seems a good choice) and then remove it (by which
I actually mean "overwrite it with '\0' so it's no longer part of
the search string").

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

     What they're talking about is:

	char array[42];
	char *ptr = array;
	int n1 = sizeof array;
	int n2 = sizeof ptr;

In each case, sizeof returns the number of bytes for its own
operand.  n1 is therefore 42, but n2 is probably not: On most
machines nowadays, n2 will be 4 or 8, the number of bytes used
for storing a pointer, not the number of bytes in the thing it
happens to point at.

     This can be a trap for the unwary, because of the way C
treats arrays when written as function parameters:

	int func(char array[42]) {
	    return sizeof array;
	}

You might expect this function to return 42, but it almost
certainly will not.  Remember, array arguments are silently
rewritten as pointers, so the function actually looks like

	int func(char *array) {
	    return sizeof array;
	}

... and as with n2 above, you get the number of bytes in a
pointer, not the number of bytes in an array.

> 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? **/

     No.  You're still confused about what a "string" is in C.
It's not a "first-class object" (as in some other languages);
rather, it's just a char[] array with a specific convention for
formatting the contents.  The individual char's of the array
are always there, whether they participate in a string (they're
near the beginning) or not (they're after the '\0').

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

     Perhaps they're using the EVIL gets() function?  Unlike
fgets(), gets() automatically removes the '\n'.  But gets() is
UNSAFE AT ANY SPEED, and any book that encourages you to use it
should be BURNED, preferably under the fanny of its author.

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

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

#73628

<snip>
>      Perhaps they're using the EVIL gets() function?  Unlike
> fgets(), gets() automatically removes the '\n'.  But gets() is
> UNSAFE AT ANY SPEED, and any book that encourages you to use it
> should be BURNED, preferably under the fanny of its author.

no no :) they discourage everyone from ever using gets(), and 
they reason over it; therefore, they use fgets(), and their
program works )

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

#73644

On Fri, 23 Oct 2015 01:16:29 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

>2) Also, I don't understand how 
>sizeof(all_tracks) / sizeof(all_tracks[0]); 
>works with a matrix. 
>
sizeof (all_tracks) yields the size of the array in bytes.
sizeof (all_tracks[0]) yields the size of the zeroth element of the
array.

This way you make the computation independent of the type of the
elements of the array. Since all members of the array must be the same
type, the computation for the zeroth element is the same as for any
other element. Therefore the division is effectively array total size
in bytes divided by the size of the elements comprising the array in
bytes which tells you the number of elements of an array.

This is a very common technique for getting the number of elements of
an array and you should take the time to understand it fully.

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

No. For multi-dimensional arrays you would use sizeof all_tracks[0][0]
to get the total number of elements of the multidimensional array.

Incidentally, there are two usages of sizeof.

sizeof unary-expression
sizeof ( type-name )

Since all_tracks and all_tracks[0] are not types, the parentheses are
optional. If you want to take sizeof (int), the parentheses are
required. Personally, I prefer to always use parentheses to avoid a
compiler error if I forget to use them with a type.

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

#73571

On Thu, 22 Oct 2015 11:30:55 -0700 (PDT), Alla _
<modelling.data@gmail.com> 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. 

Are you sure the book suggested using strstr to find a title match?
While it can be used this way, strstr will return a non-NULL value if
the search string matches ANY PART of the target string.  For example,
searching for "ar" would match either entry 0 or 1 (depending on
whether you search from the top or the bottom).  strcmp is the usual
function to find complete matches.

Consider what would happen if you searched titles "Back to the Future,
Part 2" and "Back to the Future" in that order.  Any attempt to find
the second would always find the first.

<snip>

>/ 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; 
>
>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]);
>    }
>}

-- 
Remove del for email

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

#73586

On Friday, October 23, 2015 at 1:50:16 AM UTC+4, Barry Schwarz wrote:
> On Thu, 22 Oct 2015 11:30:55 -0700 (PDT), Alla _
> <modelling.data@gmail.com> 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. 
> 
> Are you sure the book suggested using strstr to find a title match?
> While it can be used this way, strstr will return a non-NULL value if
> the search string matches ANY PART of the target string.  For example,
> searching for "ar" would match either entry 0 or 1 (depending on
> whether you search from the top or the bottom).  strcmp is the usual
> function to find complete matches.
> 
> Consider what would happen if you searched titles "Back to the Future,
> Part 2" and "Back to the Future" in that order.  Any attempt to find
> the second would always find the first.
> 
> <snip>
> 
> >/ 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; 
> >
> >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]);
> >    }
> >}
> 
> -- 
> Remove del for email

Thank you for this explanation. 
As I have written, yes, they do use strstr, the whole program
is exactly the one typed in from the book. 

This is why I have tried to produce my own version, 
which is more important for me now, because it could help
me to work on functions, char array and matrixes. But 
my one doesn't work as well (it is posted in the original text)

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

#73589

On 23/10/15 09:25, Alla _ wrote:
> On Friday, October 23, 2015 at 1:50:16 AM UTC+4, Barry Schwarz wrote:
>> On Thu, 22 Oct 2015 11:30:55 -0700 (PDT), Alla _
>> <modelling.data@gmail.com> wrote:
>>
<snip>

>>>
>>> 1) There is a program suggested by the book and printed
>>> out as an example on using strstr function.
>>
>> Are you sure the book suggested using strstr to find a title match?

<snip>

> Thank you for this explanation.
> As I have written, yes, they do use strstr, the whole program
> is exactly the one typed in from the book.

Yeah, strstr is correct. Barry didn't think this one through.

By using strstr, you are getting results for all strings that match your 
search string. That way, you don't have to type the whole title in order 
to find the match. (Barry: think grep!)

Therefore, you should print *all* matching titles, not just the first 
one you find.

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

#73587

<snip>
I have just tried to use strcmp. I am so
confused with all these strings, etc :) 

// 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;

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

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

Here is the output:

./strstrpage85A
Enter your track name: Dancing with a Dork
Track 0: 'I left my heart in Harvard Med School'
Track 1: 'Newark, Newark - a wonderful town'
Track 2: 'Dancing with a Dork'
Track 3: 'From here to maternity'
Track 4: 'The girl from Iwo Jima'

Instead of returning the number and the name of only
one track, the program respectfully informed me about
numbers and names of all tracks. 

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

#73590

On 23/10/15 09:36, Alla _ wrote:
<snip>
>          if (strcmp (all_tracks[i], search_track))
>              printf ("Track %i: '%s'\n", i, all_tracks[i]);
>      }
> }


Look up strcmp. What is its purpose? What is it supposed to tell you? 
And how does it tell you that?

That is, what does the return value *mean*?

Answer that, and you'll see why you get hits on every title (whereas you 
ought to be getting no hits whatsoever, because you're searching for 
something that can't possibly be there).

Your problem is that you have so many problems all mixed up together, 
because you've been learning too fast from an inadequate book and from 
comp.lang.c people who are trying to make you go faster rather than slower.

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

#73609

I have cleared my bugs in this program, but it
still returns incorrect result.

Enter your track name: I left my heart in Harvard Med School
Sorry, your track is not on the list


// 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, sizeof(search_track), 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;
        }
        
    }
}

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

#73610

On 23/10/15 11:58, Alla _ wrote:
> I have cleared my bugs in this program, but it
> still returns incorrect result.
>
> Enter your track name: I left my heart in Harvard Med School
> Sorry, your track is not on the list
>
>
> // Search through tracks to find the entered one
>
> #include <stdio.h>
> #include <stdbool.h>
> #include <string.h>
>
> /** Create two global variables;

We'll have that conversation another time. :-)

  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"};

I suggest instead:

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"
};

(You need to learn to take these tips on board as you go along. It will 
save everyone, including you, some time.)

> int entries_number = 5;

Better (but not perfect):

int entries_number = sizeof all_tracks / sizeof all_tracks[0];

That way, if you later decide to make your array bigger by adding 
another initialiser, you won't have to remember to change the 5 to a 6.

> /** 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, sizeof(search_track), 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]

j has not been given a value. Even if it had been, you're trying to 
compare a single character with an array, which is like comparing iced 
buns with the Suez crisis - it just doesn't work.

To compare strings, use strcmp.

To find a substring (which is what you ought to be doing), use strstr.

And remember that your input will have a newline character on it, so 
you'll have to remove that before searching. I have already shown you 
how to do this.

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

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

csiph-web