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

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

fread/fwrite

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

Contents

  fread/fwrite "billcun@nspam.invalid" <billcun@suddenlink.net> - 2012-06-18 13:45 -0700
    Re: fread/fwrite Ian Collins <ian-news@hotmail.com> - 2012-06-19 09:28 +1200
    Re: fread/fwrite Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-18 17:47 -0400
      Re: fread/fwrite billcun@suddenlink.net - 2012-06-18 15:48 -0700
        Re: fread/fwrite Ike Naar <ike@iceland.freeshell.org> - 2012-06-18 23:37 +0000
        Re: fread/fwrite Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-18 21:56 -0400
      Re: fread/fwrite billcun@suddenlink.net - 2012-06-19 04:54 -0700
        Re: fread/fwrite Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-19 09:43 -0400
          Re: fread/fwrite billcun@suddenlink.net - 2012-06-19 09:51 -0700
            Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-20 00:05 -0700
              Re: fread/fwrite James Kuyper <jameskuyper@verizon.net> - 2012-06-20 06:45 -0400
                Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-20 04:20 -0700
                  Re: fread/fwrite tom st denis <tom@iahu.ca> - 2012-06-20 07:54 -0700
              Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 08:13 -0700
                Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-21 00:17 -0700
        Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-19 08:17 -0700
          Re: fread/fwrite Mark Bluemel <mark.bluemel@googlemail.com> - 2012-06-20 01:05 -0700
            Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 08:17 -0700
              Re: fread/fwrite Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-06-20 17:33 +0200
                Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 08:50 -0700
                Re: fread/fwrite James Kuyper <jameskuyper@verizon.net> - 2012-06-21 07:45 -0400
              Re: fread/fwrite Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 18:38 -0400
                Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 15:59 -0700
                  Re: fread/fwrite "BartC" <bc@freeuk.com> - 2012-06-21 00:24 +0100
                  Re: fread/fwrite Ian Collins <ian-news@hotmail.com> - 2012-06-21 11:40 +1200
                    Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-20 16:47 -0700
                      Re: fread/fwrite Ian Collins <ian-news@hotmail.com> - 2012-06-21 11:56 +1200
                        Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-20 17:11 -0700
                          Re: fread/fwrite Ian Collins <ian-news@hotmail.com> - 2012-06-21 12:28 +1200
                            Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-20 17:51 -0700
                        Re: fread/fwrite Kenneth Brody <kenbrody@spamcop.net> - 2012-06-21 15:05 -0400
                          Re: fread/fwrite Ian Collins <ian-news@hotmail.com> - 2012-06-22 07:17 +1200
                            Re: fread/fwrite James Kuyper <jameskuyper@verizon.net> - 2012-06-21 16:01 -0400
                              Re: fread/fwrite Keith Thompson <kst-u@mib.org> - 2012-06-21 15:08 -0700
                                Re: fread/fwrite James Kuyper <jameskuyper@verizon.net> - 2012-06-21 18:36 -0400
                                  Re: fread/fwrite Keith Thompson <kst-u@mib.org> - 2012-06-21 16:49 -0700
                      Re: fread/fwrite Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 01:30 +0100
                        Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-20 17:51 -0700
                          Re: fread/fwrite Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 02:22 +0100
                        Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-22 00:13 -0700
                      Re: fread/fwrite tom st denis <tom@iahu.ca> - 2012-06-21 04:22 -0700
                        Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-22 12:14 -0700
                  Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-21 00:33 -0700
                Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-20 16:27 -0700
              Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-21 00:21 -0700
                Re: fread/fwrite Mark Bluemel <mark.bluemel@googlemail.com> - 2012-06-21 07:17 -0700
                  Re: fread/fwrite nick_keighley_nospam@hotmail.com - 2012-06-22 00:22 -0700
                    Re: fread/fwrite Bill Cunningham <billcun@suddenlink.net> - 2012-06-22 12:17 -0700
    Re: fread/fwrite John Gordon <gordon@panix.com> - 2012-06-18 22:05 +0000
      Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 09:03 -0700
        Re: fread/fwrite John Gordon <gordon@panix.com> - 2012-06-20 16:28 +0000
          Re: fread/fwrite billcun@suddenlink.net - 2012-06-20 09:53 -0700

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

#22371 — fread/fwrite

I want to be sure what these two functions are for. To copy for example 1 2048 size bytes block at a time? I usually use fgetc and fputc. But I would please like for someone if they would to show me an example of these functions.

THX

[toc] | [next] | [standalone]

#22372

On 06/19/12 08:45 AM, billcun@nspam.invalid wrote:
> I want to be sure what these two functions are for. To copy for example 1 2048 size bytes block at a time? I usually use fgetc and fputc. But I would please like for someone if they would to show me an example of these functions.

GIYF.

-- 
Ian Collins

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

#22374

On 6/18/2012 4:45 PM, billcun@nspam.invalid wrote:
 > [... reformatted for line length ...]
 >
> I want to be sure what these two functions are for. To copy for
 > example 1 2048 size bytes block at a time? I usually use fgetc and
> fputc. But I would please like for someone if they would to show me
 > an example of these functions.

     They are "convenience functions" in the sense that you could
use repeated calls to fgetc/fputc (or getc/putc) to do pretty much
the same thing, transferring one byte per call.  Since you transfer
(potentially) many bytes per call fread/fwrite could be a bit faster
than byte-at-a-time loops, but since most CPU's are millions of times
faster than most I/O devices any gains are unlikely to matter.

     Here's a closer look at fread; fwrite is similar.  First,
the declaration (slightly simplified):

	size_t fread(
	    void * ptr,    // where the input data will land
	    size_t size,   // the size of one data element
	    size_t nmemb,  // the number of elements to read
	    FILE * stream  // the source from which they're read
	);

The first likely point of bafflement is this "element" business.
fread/fwrite don't (necessarily) deal in single bytes, but in
units of (potentially) multi-byte items.  To read an array of
forty-two something-or-others, you might use

	fread(array, sizeof array[0], 42, stream);

If one something-or-other occupies ten bytes this will read 420
bytes; if it occupies just one byte this reads 42 bytes.  The main
thing to keep in mind is that it reads 42 something-or-others of
`sizeof array[0]' bytes each.

     Digression: Have you encountered other functions that deal
in "elements" of a specified size instead of directly with bytes?
Sure you have: There's qsort and bsearch, and for that matter calloc:
Each has a pair of arguments that specify an element size and an
element count.  But be alert!  Notice that qsort et al. describe their
elements the other way around: "count followed by size," whereas
fread/fwrite use "size followed by count."  You've heard, perhaps,
of the "cathedral versus bazaar" approaches to system design?  C's
library arose from the bazaar, and is occasionally, er, bizarre.

     Okay, but what difference does it make?  The number of bytes
transferred will be the product of the two arguments, and so will
be the same whichever way you specify them, right?  Yes, but then
there's the matter of the value returned by the function: It's the
number of *elements* transferred, not the number of bytes.  If you
read 42 10-byte elements or 10 42-byte elements you'll read 420
bytes either way, but one fread call will say "You got 42 elements"
and the other will say "You got 10 elements."  Assuming you'll use
the returned value to figure out how many elements your program
should now digest, you'll want to keep size and count straight
lest you wind up reading 10 and trying to process 42, or reading
42 but processing only the first 10!

     One problem with reporting the number of "elements" read or
written is that if you get an I/O error or end-of-file in the
middle of an element it's hard to determine exactly how far you
got.  For example, if you try to read 42 10-byte elements and fread
says you got 16, you can't tell whether you got exactly 16, or 16
plus four bytes of a 17th and then EOF.  A way around this is to use
one as your element size:

	size_t bytes = fread(array, 1, 42 * sizeof array[0], stream);
	size_t count = bytes / sizeof array[0];
	size_t excess = bytes % sizeof array[0];
	if (excess != 0) {
	    // Stopped in mid-element; something's strange.
	    // Maybe use feof(stream) and/or ferror(stream)
	    // and/or perror() to diagnose the problem.
	    ...

     I hope this helps.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22379

On Jun 18, 5:47 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/18/2012 4:45 PM, bill...@nspam.invalid wrote:
>  > [... reformatted for line length ...]
>  >> I want to be sure what these two functions are for. To copy for
>
>  > example 1 2048 size bytes block at a time? I usually use fgetc and> fputc. But I would please like for someone if they would to show me
>
>  > an example of these functions.
>
>      They are "convenience functions" in the sense that you could
> use repeated calls to fgetc/fputc (or getc/putc) to do pretty much
> the same thing, transferring one byte per call.  Since you transfer
> (potentially) many bytes per call fread/fwrite could be a bit faster
> than byte-at-a-time loops, but since most CPU's are millions of times
> faster than most I/O devices any gains are unlikely to matter.
>
>      Here's a closer look at fread; fwrite is similar.  First,
> the declaration (slightly simplified):
>
>         size_t fread(
>             void * ptr,    // where the input data will land
>             size_t size,   // the size of one data element
>             size_t nmemb,  // the number of elements to read
>             FILE * stream  // the source from which they're read
>         );
>
> The first likely point of bafflement is this "element" business.
> fread/fwrite don't (necessarily) deal in single bytes, but in
> units of (potentially) multi-byte items.  To read an array of
> forty-two something-or-others, you might use
>
>         fread(array, sizeof array[0], 42, stream);


   What does sizeof array[0] mean?

> If one something-or-other occupies ten bytes this will read 420
> bytes; if it occupies just one byte this reads 42 bytes.  The main
> thing to keep in mind is that it reads 42 something-or-others of
> `sizeof array[0]' bytes each.
>
>      Digression: Have you encountered other functions that deal
> in "elements" of a specified size instead of directly with bytes?
> Sure you have: There's qsort and bsearch, and for that matter calloc:
> Each has a pair of arguments that specify an element size and an
> element count.  But be alert!  Notice that qsort et al. describe their
> elements the other way around: "count followed by size," whereas
> fread/fwrite use "size followed by count."  You've heard, perhaps,
> of the "cathedral versus bazaar" approaches to system design?  C's
> library arose from the bazaar, and is occasionally, er, bizarre.
>
>      Okay, but what difference does it make?  The number of bytes
> transferred will be the product of the two arguments, and so will
> be the same whichever way you specify them, right?  Yes, but then
> there's the matter of the value returned by the function: It's the
> number of *elements* transferred, not the number of bytes.  If you
> read 42 10-byte elements or 10 42-byte elements you'll read 420
> bytes either way, but one fread call will say "You got 42 elements"
> and the other will say "You got 10 elements."  Assuming you'll use
> the returned value to figure out how many elements your program
> should now digest, you'll want to keep size and count straight
> lest you wind up reading 10 and trying to process 42, or reading
> 42 but processing only the first 10!
>
>      One problem with reporting the number of "elements" read or
> written is that if you get an I/O error or end-of-file in the
> middle of an element it's hard to determine exactly how far you
> got.  For example, if you try to read 42 10-byte elements and fread
> says you got 16, you can't tell whether you got exactly 16, or 16
> plus four bytes of a 17th and then EOF.  A way around this is to use
> one as your element size:
>
>         size_t bytes = fread(array, 1, 42 * sizeof array[0], stream);
>         size_t count = bytes / sizeof array[0];
>         size_t excess = bytes % sizeof array[0];
>         if (excess != 0) {
>             // Stopped in mid-element; something's strange.
>             // Maybe use feof(stream) and/or ferror(stream)
>             // and/or perror() to diagnose the problem.
>             ...
>
>      I hope this helps.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

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

#22382

On 2012-06-18, billcun@suddenlink.net <billcun@suddenlink.net> wrote:
>    What does sizeof array[0] mean?

You've asked this question before (e.g. on 2011-05-28), and received
several answers that explained the whole thing in every detail.
Haven't you learned anything from those answers?

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

#22390

On 6/18/2012 6:48 PM, billcun@suddenlink.net wrote:
>[...]
>     What does sizeof array[0] mean?

     It means "a positive number."

     (An old story has Fred calling some friends at home but hearing
"Hello" from a very young voice.  "Is your father there?"  "No."
"Okay, is your mother there?"  "No."  Um.  "Could you tell them
Fred called?"  "I'm going out soon."  "Okay, could you leave them
a note that Fred called?"  "Okay.  I'll get some paper ...  Okay,
how do you spell Fred?"  Yikes.  "F-R-E-D, got it?"  "Okay.  How do
you make an F?")

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22404

On Jun 18, 5:47 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/18/2012 4:45 PM, bill...@nspam.invalid wrote:
>  > [... reformatted for line length ...]
>  >> I want to be sure what these two functions are for. To copy for
>
>  > example 1 2048 size bytes block at a time? I usually use fgetc and> fputc. But I would please like for someone if they would to show me
>
>  > an example of these functions.
>
>      They are "convenience functions" in the sense that you could
> use repeated calls to fgetc/fputc (or getc/putc) to do pretty much
> the same thing, transferring one byte per call.  Since you transfer
> (potentially) many bytes per call fread/fwrite could be a bit faster
> than byte-at-a-time loops, but since most CPU's are millions of times
> faster than most I/O devices any gains are unlikely to matter.
>
>      Here's a closer look at fread; fwrite is similar.  First,
> the declaration (slightly simplified):
>
>         size_t fread(
>             void * ptr,    // where the input data will land
>             size_t size,   // the size of one data element
>             size_t nmemb,  // the number of elements to read
>             FILE * stream  // the source from which they're read
>         );
>
> The first likely point of bafflement is this "element" business.
> fread/fwrite don't (necessarily) deal in single bytes, but in
> units of (potentially) multi-byte items.  To read an array of
> forty-two something-or-others, you might use
>
>         fread(array, sizeof array[0], 42, stream);
>
> If one something-or-other occupies ten bytes this will read 420
> bytes; if it occupies just one byte this reads 42 bytes.  The main
> thing to keep in mind is that it reads 42 something-or-others of
> `sizeof array[0]' bytes each.
>
>      Digression: Have you encountered other functions that deal
> in "elements" of a specified size instead of directly with bytes?
> Sure you have: There's qsort and bsearch, and for that matter calloc:
> Each has a pair of arguments that specify an element size and an
> element count.  But be alert!  Notice that qsort et al. describe their
> elements the other way around: "count followed by size," whereas
> fread/fwrite use "size followed by count."  You've heard, perhaps,
> of the "cathedral versus bazaar" approaches to system design?  C's
> library arose from the bazaar, and is occasionally, er, bizarre.
>
>      Okay, but what difference does it make?  The number of bytes
> transferred will be the product of the two arguments, and so will
> be the same whichever way you specify them, right?  Yes, but then
> there's the matter of the value returned by the function: It's the
> number of *elements* transferred, not the number of bytes.  If you
> read 42 10-byte elements or 10 42-byte elements you'll read 420
> bytes either way, but one fread call will say "You got 42 elements"
> and the other will say "You got 10 elements."  Assuming you'll use
> the returned value to figure out how many elements your program
> should now digest, you'll want to keep size and count straight
> lest you wind up reading 10 and trying to process 42, or reading
> 42 but processing only the first 10!
>
>      One problem with reporting the number of "elements" read or
> written is that if you get an I/O error or end-of-file in the
> middle of an element it's hard to determine exactly how far you
> got.  For example, if you try to read 42 10-byte elements and fread
> says you got 16, you can't tell whether you got exactly 16, or 16
> plus four bytes of a 17th and then EOF.  A way around this is to use
> one as your element size:
>
>         size_t bytes = fread(array, 1, 42 * sizeof array[0], stream);
>         size_t count = bytes / sizeof array[0];
>         size_t excess = bytes % sizeof array[0];
>         if (excess != 0) {
>             // Stopped in mid-element; something's strange.
>             // Maybe use feof(stream) and/or ferror(stream)
>             // and/or perror() to diagnose the problem.
>             ...
>
>      I hope this helps.
>
  In a way it has because you've introduced me to something new, the
argv[0]. But I don't quite undestand how you would use it. It's so
hard for aspiring amateurs like me who love to code to keep up with
professionals. Would a size of 2048 bytes as a block work or crash
things?

Bill

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

#22409

On 6/19/2012 7:54 AM, billcun@suddenlink.net wrote:
> On Jun 18, 5:47 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> [...]
>>       I hope this helps.
>>
>    In a way it has because you've introduced me to something new, the
> argv[0].  [...]

     Since I never mentioned argv[0], nor even argv, it's hard to
discern the nature of the introduction.

     (Light dawns on Marblehead): Are you "Bill Cunningham," by any
chance?  If so, I've been well and truly taken in.  I apologize to
the group for wasting bandwidth, and will update my filters.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22414

On Jun 19, 9:43 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 6/19/2012 7:54 AM, bill...@suddenlink.net wrote:
>
> > On Jun 18, 5:47 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> >> [...]
> >>       I hope this helps.
>
> >    In a way it has because you've introduced me to something new, the
> > argv[0].  [...]
>
>      Since I never mentioned argv[0], nor even argv, it's hard to
> discern the nature of the introduction.

Sorry. Typo. I meant array[0]

>      (Light dawns on Marblehead): Are you "Bill Cunningham," by any
> chance?

Yes. My ISP's newsserver isn't working for now. I'm going through
google groups for as long as I have to.

If so, I've been well and truly taken in.

If you say so.

 I apologize to
> the group for wasting bandwidth, and will update my filters.

Very well

> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

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

#22425

On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:
> On Jun 19, 9:43 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:

> > >    In a way it has because you've introduced me to something new, the
> > > argv[0].  [...]
> >
> >      Since I never mentioned argv[0], nor even argv, it's hard to
> > discern the nature of the introduction.
> 
> Sorry. Typo. I meant array[0]

in what sense is array[0] "new"? You must have seen an array indexed before!

   int array [10];
   int i;

   for (i = 0; i < 10; i++)
      printf ("%d ", array[i]);

   printf ("\n");

   array[1] = 1;
   array[0] = 0;

are you saying /this/ is new to you?! You have K&R go and read the section on arrays *again*.

<snip>

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

#22431

On 06/20/2012 03:05 AM, nick_keighley_nospam@hotmail.com wrote:
> On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:
>> On Jun 19, 9:43�am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> 
>>>> � �In a way it has because you've introduced me to something new, the
>>>> argv[0]. �[...]
>>>
>>> � � �Since I never mentioned argv[0], nor even argv, it's hard to
>>> discern the nature of the introduction.
>>
>> Sorry. Typo. I meant array[0]
> 
> in what sense is array[0] "new"? You must have seen an array indexed before!

Every occurrence of array[0] in the message he was responding to was as
an operand of a sizeof operator. I remain uncertain whether Bill is
legitimately incapable of understanding anything, or  whether he's a
troll pretending to be such a person,  However, if his learning
disabilities are legitimate, my guess is that he doesn't understand the
key role played by the sizeof operator in those expressions, and
therefore zeroed in on array[0] as "the" peculiar feature that renders
that code beyond his understanding. Based upon past experience, if he's
not a troll, every feature of that code is beyond his ability to
understand - there's nothing special about array[0] in that regard.
-- 
James Kuyper

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

#22432

On Wednesday, June 20, 2012 11:45:33 AM UTC+1, James Kuyper wrote:
> On 06/20/2012 03:05 AM, nick_keighley_nospam@hotmail.com wrote:
> > On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:
> >> On Jun 19, 9:43�am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> >>>> � �In a way it has because you've introduced me to something new, the
> >>>> argv[0]. �[...]
> >>>
> >>> � � �Since I never mentioned argv[0], nor even argv, it's hard to
> >>> discern the nature of the introduction.
> >>
> >> Sorry. Typo. I meant array[0]
> > 
> > in what sense is array[0] "new"? You must have seen an array indexed before!
> 
> Every occurrence of array[0] in the message he was responding to was as
> an operand of a sizeof operator.

I know. But he didn't say "I don't understand what 'sizeof arry[0]' 
means" did he? he tried twice but failed both times. His inabilty to
think clearly is one of his problems.

> I remain uncertain whether Bill is
> legitimately incapable of understanding anything, or  whether he's a
> troll pretending to be such a person,  However, if his learning
> disabilities are legitimate, my guess is that he doesn't understand the
> key role played by the sizeof operator in those expressions, and
> therefore zeroed in on array[0] as "the" peculiar feature that renders
> that code beyond his understanding. Based upon past experience, if he's
> not a troll, every feature of that code is beyond his ability to
> understand - there's nothing special about array[0] in that regard.

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

#22436

On Jun 20, 7:20 am, nick_keighley_nos...@hotmail.com wrote:
> On Wednesday, June 20, 2012 11:45:33 AM UTC+1, James Kuyper wrote:
> > On 06/20/2012 03:05 AM, nick_keighley_nos...@hotmail.com wrote:
> > > On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:
> > >> On Jun 19, 9:43 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> > >>>> In a way it has because you've introduced me to something new, the
> > >>>> argv[0]. [...]
>
> > >>> Since I never mentioned argv[0], nor even argv, it's hard to
> > >>> discern the nature of the introduction.
>
> > >> Sorry. Typo. I meant array[0]
>
> > > in what sense is array[0] "new"? You must have seen an array indexed before!
>
> > Every occurrence of array[0] in the message he was responding to was as
> > an operand of a sizeof operator.
>
> I know. But he didn't say "I don't understand what 'sizeof arry[0]'
> means" did he? he tried twice but failed both times. His inabilty to
> think clearly is one of his problems.

The fact that he's a troll too is one of his problems.

Tom

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

#22437

On Jun 20, 3:05 am, nick_keighley_nos...@hotmail.com wrote:
> On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:
> > On Jun 19, 9:43 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > > >    In a way it has because you've introduced me to something new, the
> > > > argv[0].  [...]
>
> > >      Since I never mentioned argv[0], nor even argv, it's hard to
> > > discern the nature of the introduction.
>
> > Sorry. Typo. I meant array[0]
>
> in what sense is array[0] "new"? You must have seen an array indexed before!

   Oh Ok yes of course. Yes. It was mentioned this was any positive
number. I was confused for a minute. Yeah I know what your talking
about.
>    int array [10];
>    int i;
>
>    for (i = 0; i < 10; i++)
>       printf ("%d ", array[i]);
>
>    printf ("\n");
>
>    array[1] = 1;
>    array[0] = 0;
>
> are you saying /this/ is new to you?! You have K&R go and read the section on arrays *again*.
>
> <snip>

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

#22461

On Wednesday, June 20, 2012 4:13:46 PM UTC+1, Bill Cunningham wrote:
> On Jun 20, 3:05 am, nick_keighley_nos...@hotmail.com wrote:
> > On Tuesday, June 19, 2012 5:51:55 PM UTC+1, (unknown) wrote:

<snip>

> > > Sorry. Typo. I meant array[0]
[was a new concept]

> > in what sense is array[0] "new"? You must have seen an array indexed before!
> 
> Oh Ok yes of course. Yes. It was mentioned this was any positive
> number.

*what* was any positive number? is english your first language? Is zero a positive number in your universe?

<snip>

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

#22412

On Tuesday, June 19, 2012 12:54:40 PM UTC+1, (unknown) wrote:
> On Jun 18, 5:47 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > On 6/18/2012 4:45 PM, bill...@nspam.invalid wrote:

> >  > [... reformatted for line length ...]
> >  >> I want to be sure what these two functions are for. 

[ie. fread() and fwrite()]

fread reads a block of data fwrite writes one. Can't you find this on google?

[...]

> > But I would please like for someone if they would to show me
> >  > an example of these functions.
> >
> >      They are "convenience functions" in the sense that you could
> > use repeated calls to fgetc/fputc (or getc/putc) to do pretty much
> > the same thing, transferring one byte per call.  Since you transfer
> > (potentially) many bytes per call fread/fwrite could be a bit faster
> > than byte-at-a-time loops, but since most CPU's are millions of times
> > faster than most I/O devices any gains are unlikely to matter.
> >
> >      Here's a closer look at fread; fwrite is similar.  First,
> > the declaration (slightly simplified):
> >
> >         size_t fread(
> >             void * ptr,    // where the input data will land
> >             size_t size,   // the size of one data element
> >             size_t nmemb,  // the number of elements to read
> >             FILE * stream  // the source from which they're read
> >         );
> >
> > The first likely point of bafflement is this "element" business.
> > fread/fwrite don't (necessarily) deal in single bytes, but in
> > units of (potentially) multi-byte items.  To read an array of
> > forty-two something-or-others, you might use
> >
> >         fread(array, sizeof array[0], 42, stream);
> >
> > If one something-or-other occupies ten bytes this will read 420
> > bytes; if it occupies just one byte this reads 42 bytes.  The main
> > thing to keep in mind is that it reads 42 something-or-others of
> > `sizeof array[0]' bytes each.
> >
> >      Digression: Have you encountered other functions that deal
> > in "elements" of a specified size instead of directly with bytes?
> > Sure you have: There's qsort and bsearch, and for that matter calloc:
> > Each has a pair of arguments that specify an element size and an
> > element count.  But be alert!  Notice that qsort et al. describe their
> > elements the other way around: "count followed by size," whereas
> > fread/fwrite use "size followed by count."  You've heard, perhaps,
> > of the "cathedral versus bazaar" approaches to system design?  C's
> > library arose from the bazaar, and is occasionally, er, bizarre.
> >
> >      Okay, but what difference does it make?  The number of bytes
> > transferred will be the product of the two arguments, and so will
> > be the same whichever way you specify them, right?  Yes, but then
> > there's the matter of the value returned by the function: It's the
> > number of *elements* transferred, not the number of bytes.  If you
> > read 42 10-byte elements or 10 42-byte elements you'll read 420
> > bytes either way, but one fread call will say "You got 42 elements"
> > and the other will say "You got 10 elements."  Assuming you'll use
> > the returned value to figure out how many elements your program
> > should now digest, you'll want to keep size and count straight
> > lest you wind up reading 10 and trying to process 42, or reading
> > 42 but processing only the first 10!
> >
> >      One problem with reporting the number of "elements" read or
> > written is that if you get an I/O error or end-of-file in the
> > middle of an element it's hard to determine exactly how far you
> > got.  For example, if you try to read 42 10-byte elements and fread
> > says you got 16, you can't tell whether you got exactly 16, or 16
> > plus four bytes of a 17th and then EOF.  A way around this is to use
> > one as your element size:
> >
> >         size_t bytes = fread(array, 1, 42 * sizeof array[0], stream);
> >         size_t count = bytes / sizeof array[0];
> >         size_t excess = bytes % sizeof array[0];
> >         if (excess != 0) {
> >             // Stopped in mid-element; something's strange.
> >             // Maybe use feof(stream) and/or ferror(stream)
> >             // and/or perror() to diagnose the problem.
> >             ...
> >
> >      I hope this helps.
> >
>   In a way it has because you've introduced me to something new, the
> argv[0].

where?

> But I don't quite undestand how you would use it.

did you read what he wrote?

> It's so
> hard for aspiring amateurs like me who love to code to keep up with
> professionals. Would a size of 2048 bytes as a block work or crash
> things?

why would it crash? Is 2048 bytes sensible for the data you're reading?

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

#22429

On Jun 19, 4:17 pm, nick_keighley_nos...@hotmail.com wrote:

> did you read what he wrote?

Why would you expect Bill to do that? He's been around this group long
enough for any regular reader to have some idea of his modus operandi.

I can't decide whether he's a) simply incapable of learning or b) a
subtle troll pretending to be a), though I'm beginning to lean towards
b). Either way, I don't believe there is much point attempting to
teach him.

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

#22438

On Jun 20, 4:05 am, Mark Bluemel <mark.blue...@googlemail.com> wrote:
> On Jun 19, 4:17 pm, nick_keighley_nos...@hotmail.com wrote:
>
> > did you read what he wrote?
>
> Why would you expect Bill to do that? He's been around this group long
> enough for any regular reader to have some idea of his modus operandi.
>
> I can't decide whether he's a) simply incapable of learning or b) a
> subtle troll pretending to be a), though I'm beginning to lean towards
> b). Either way, I don't believe there is much point attempting to
> teach him.

  Things are not *taught* on clc. You do not learn anything. It is a C
social group. I can count on one hand what I've been *taught* on clc.
If you want to learn something on clc the response is generally...
"GIYF" or "I don't do homework." You do not learn C here. You talk
about it or your experience with C. I've learned more about writing C
on private mail groups in 1 month more than years on clc.

B

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

#22439

On 20.06.2012 17:17, billcun@suddenlink.net wrote:

>   Things are not *taught* on clc. You do not learn anything. It is a C
> social group. I can count on one hand what I've been *taught* on clc.
> If you want to learn something on clc the response is generally...
> "GIYF" or "I don't do homework." You do not learn C here. You talk
> about it or your experience with C. I've learned more about writing C
> on private mail groups in 1 month more than years on clc.

My clc-experience seems to differ greatly from yours. For every question
I've asked so far here I've promptly received numerous, very verbose and
detailled and competent responses that hit the nail right on the head.
Always with included references for further reading (i.e. not only THAT
something is the way it is, but also WHY and where I can read more about
it). I really like this newsgroup.

Best regards,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

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

#22440

On Jun 20, 11:33 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:

> My clc-experience seems to differ greatly from yours. For every question
> I've asked so far here I've promptly received numerous, very verbose and
> detailled and competent responses that hit the nail right on the head.
> Always with included references for further reading (i.e. not only THAT
> something is the way it is, but also WHY and where I can read more about
> it). I really like this newsgroup.
>
> Best regards,
> Johannes

 Hello John,

Wow. Keep up the good work if it works for you. I have garnered
questions from tutorials such as on linked lists. I brought some
things up here and received numerous responses. The main one is "GIYF"
and then "Do your own homework" and "try comp.programming or another
NG"(concerning linked lists) I have *NEVER* got a good explanation. At
best some clues or told to read C FAQs. clc is a very rude and blunt
NG and that's its nature I have been warned and I can handle that. I
have found personally Beej's guides to be very informative and learned
about dereferencing too. I am beginning to learn pointers and write in
structs and pointer members. *No* thanks to clc but another source. In
a month very helpful people took me step by step. My suspicion is that
clc is full or professional programmers that don't have the time or
patience to work with amateurs like me anyway and there may be other
hobbyists here too. I code in C for fun. I mainly lurk and find my
experience to be somewhat if not particularly normal. Good Luck

B

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

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

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

csiph-web