reading data from a file

J

John Smith

I want to read data from a file and assign it to a dynamically
allocated array. I don't know the number of data in advance. My
approach has been to read the file twice, the first time to
determine its size, the second for the actual assignment. Is
there a more efficient way?
 
I

Ico

John Smith said:
I want to read data from a file and assign it to a dynamically
allocated array. I don't know the number of data in advance. My
approach has been to read the file twice, the first time to
determine its size, the second for the actual assignment. Is
there a more efficient way?

Open the file with fopen(), seek to the end with fseek(), get the
current position with ftell(). This position is the size of the file.
Allocate the buffer, go back to the beginning of the file with rewind()
or fseek(), and use fread() to read the file into the buffer.
Don't forget to add error checking where needed.
 
F

Flash Gordon

John said:
I want to read data from a file and assign it to a dynamically allocated
array. I don't know the number of data in advance. My approach has been
to read the file twice, the first time to determine its size, the second
for the actual assignment. Is there a more efficient way?

That depends on what is efficient on your implementation. One possible
way to to use realloc to increase the space allocated as you read the
file, however you have to decide on an appropriate resizing algorithm,
since growing it one byte at a time is unlikely to be efficient.
 
V

Vladimir S. Oka

Ico said:
Open the file with fopen(), seek to the end with fseek(), get the
current position with ftell(). This position is the size of the file.
Allocate the buffer, go back to the beginning of the file with
rewind() or fseek(), and use fread() to read the file into the buffer.

This seems to refer to the case where the whole file is sucked into the
memory at once. Following may be a better/more flexible idea.

Presumably, data in the file is organised in some sort of records. You
can read one record at a time, get its size (if you know their size in
advance, so much the better), allocate the memory you need, and store
the record into the newly allocated memory. This approach would also
allow you to have file with records of variable size. Your dynamically
allocated array would in fact be an array of pointers to dynamically
allocated memory for individual elements. Some would call it a
collection. ;-)
Don't forget to add error checking where needed.

This, of course, is mandatory! ;-)

Cheers

Vladimir
 
F

Flash Gordon

Ico said:
Open the file with fopen(), seek to the end with fseek(),

To quote from the standard, "A binary stream need not
meaningfully support fseek calls with a whence value of SEEK_END." So
that part of your suggestion is not portable if this is a binary file.
> get the
current position with ftell().

The, quoting from the section of the standard defining ftell we have,
"For a text stream, its file position indicator contains unspecified
information, usable by the fseek..." so on a text stream it may not be
the file size, it is just some number fseek can use.
> This position is the size of the file.

So your suggestion is not guaranteed to work for either binary or text
streams.
Allocate the buffer, go back to the beginning of the file with rewind()
or fseek(), and use fread() to read the file into the buffer.
Don't forget to add error checking where needed.

I seriously think the realloc method is better in terms of portability.
It will also then cope with any non-seekable stream, such as named pipes
on systems that support such things.
 
J

Jordan Abel

To quote from the standard, "A binary stream need not
meaningfully support fseek calls with a whence value of SEEK_END." So
that part of your suggestion is not portable if this is a binary file.

does a text stream need to? you can't seek at all on stdout/stdin on
some implementations
 
F

Flash Gordon

Jordan said:
does a text stream need to? you can't seek at all on stdout/stdin on
some implementations

<snip>

The call is allowed to fail, as with any library call, and is likely to
fail if used on stdio/stdout. However, the quote I gave reads to me that
even if a binary stream is seekable you can't rely on being able to seek
to its end.

There have been several discussions on here about finding a files size
where all this has been mentioned before. I was just pointing out two
parts of the standard which explicitly make what was suggested non-portable.
 
I

Ico

Flash Gordon said:
To quote from the standard, "A binary stream need not
meaningfully support fseek calls with a whence value of SEEK_END." So
that part of your suggestion is not portable if this is a binary file.

I wasn't aware of that.
The, quoting from the section of the standard defining ftell we have,
"For a text stream, its file position indicator contains unspecified
information, usable by the fseek..." so on a text stream it may not be
the file size, it is just some number fseek can use.

And didn't know that either.

Thanks for pointing that out, yet another educational moment for me on
c.l.c.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top