I once made a script in C to receive a file name as argument in *argv and using fopen i would read each char until EOF. At the same time i would be calculating its size using sums.
I cant remeber how much i would sum for each char i read, but that method was very ineficient and slow.
Are there better examples of how to do it?
ftell() is a standard function that will tell you the position from the beginning of a file. The fseek() function has an option to set the fileposition relative to the end of the file, so combining those two will tell you how long the file is without reading any of the content.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Another (not portable) solution: if you're on a *nix machine, the stat() function
call can get some low-level information about the the file, including its size in bytes.
If the file is a symbolic link st_size gives the length in bytes of the path name contained in the sym. linkCode:#include<stdio.h> #include<sys/stat.h> int main(int argc, char **argv){ struct stat stbuf; if(stat(argv[1], &stbuf)==0) printf("-I- File size in bytes: %ld\n", stbuf.st_size); return 0; }
I think there's an equivalent function call in MSWin, but since this is not a
standard C function YMMV, depending upon what you're using
hope it helps
There's also a stat() function on Windows.Originally Posted by gradstudent
I would think that passing the file pointer to a strlen like function would be pretty efficient and fast if you are tallying up all the pointers to char. Double check sizeof(char) for your system though.
sizeof(char) is always one.
1) that wouldn't work.
2) sizeof(char) is always 1. Always.
Last edited by King Mir; 06-11-2008 at 02:35 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
That would give you a warning in C and if you ignore it, most likely a crash to undefined behavior. In C++, it would never compile.
Late response:
Hmm not sure where you all were going with what I said. But tallying up all the chars within a file or string will give you it's size in bytes. The below should work, so maybe my wording of what I was trying to explain was off a bit.
Code:: /*continue to read in file*/ while (*filePointer++) { length++; } return length; : :
This works for a string and indeed, what most strlen implementations do, but it won't work for a file whose type is FILE*.
Besides, it's also a very inefficient method for finding the size of a file.
"type is FILE*." Ok, ok.
Thanks
FILE is a struct. How do you propose to use that as a boolean expression?
That's impossible in C, so what you propose won't compile.
Not to mention FILE is not an array, so trying to walk it using ++ would be undefined behavior.
It would work on char*, char[], but not FILE*.
Actually, I wouldn't want to guarantee that FILE is NOT an array - in many systems it would be. The problem with using ++ on a file-pointer, however, is that the struct FILE is not a known type in the application side, it's only known in the C-library side of the code (it's called an opaque pointer - it's a pointer to a struct, but you never "look inside it").
Being an opaque pointer means that there's no way to use ++ on it, since the compiler is not able to figure out how much forward it should jump.
And of course, even if we could "walk" the list of FILE structs, the code would definitely not tell you how big the file is - it would return some random value that is completely and utterly unrelated to the size of the file itself.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That's the closest thing I know of to a portable solution except that..... it doesn't work portably. With some operating systems or disk drivers, the call of fseek() can fail without returning any error code, after which the return from ftell() is unpredictable.
This method also relies on an assumption that a file size cannot exceed the maximum value that is representable in a long int, which is not true with some recent compilers or target platforms.
I can't think of a reasonable solution to that one. Although I predict that this would also not work reliably for other fseek-related operations, so wouldn't that filesystem/disk driver be "black-flagged"?
In this case, the solution is to use the fgetpos/fsetpos functions, that take a "fpos_t" type - this type should be correctly sized for any file-size that the OS supports if the C library implementation is done correctly. Unfortunately, fgetpos/fsetpos are not standard functions, but exist in both Linux and MS runtime libraries at the very least.This method also relies on an assumption that a file size cannot exceed the maximum value that is representable in a long int, which is not true with some recent compilers or target platforms.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
