1

Several topics (see Using C++ filestreams (fstream), how can you determine the size of a file? and C++: Getting incorrect file size) on how to measure a file size compute the difference between the beginning and the end of the file like that :

std::streampos fileSize( const char* filePath ){

    std::streampos fsize = 0;
    std::ifstream file( filePath, std::ios::binary );

    fsize = file.tellg();
    file.seekg( 0, std::ios::end );
    fsize = file.tellg() - fsize;
    file.close();

    return fsize;
}

But instead of opening the file at the beginning, we can open it at the end and just take a measure, like that :

std::streampos fileSize( const char* filePath ){

    std::ifstream file( filePath, std::ios::ate | std::ios::binary );
    std::streampos fsize = file.tellg();
    file.close();

    return fsize;
}

Will it work ? And if not why ?

Community
  • 1
  • 1
Vincent
  • 57,703
  • 61
  • 205
  • 388
  • Just a side note, the calls to `close` are unnecessary. – Seth Carnegie Oct 09 '12 at 01:50
  • Probably would work, not sure it's the best way to get a file size though. – goji Oct 09 '12 at 01:52
  • I usually if I need to get file size just make calls as so: `std::ifstream file( filepath, std::ios::ate | std::ios::binary);` `int fileLength = 0;` `file.seekg(0, std::ios::end);` `fileLength = file.tellg();` `file.seekg(0, std::ios::beg);` `if(fileLength == -1) { //error stuff here}` And so on. I believe the difference in position of stream though, is it's an internal char array, so position 1, could be offset 0. Though, this part I am not positive about – M4rc Oct 09 '12 at 01:52
  • @SethCarnegie : why are the call to close unnecessary ? – Vincent Oct 09 '12 at 01:54
  • Because `ifstream` is an RAII object that closes its file when it is destroyed. – Seth Carnegie Oct 09 '12 at 01:57
  • While using `ate` to get to the end of the file does no harm, keep in mind that seeking to the end of the file and getting the position may not give a particularly meaningful file size in any case -- for example, one a system that translates line endings, the "file size" you get may not correspond to the number of characters you'd get if you read through the file from beginning to end. – Jerry Coffin Oct 09 '12 at 02:14
  • @JerryCoffin: Since the OP included `std::ios::binary`, that shouldn't be an issue; with line ending translation off, the position at EOF should correspond to the logical file size. It may not correspond to the size on disk, given transparent compression, file system block size, sparse files, etc., but it should correspond to the number of bytes you'd need to store the complete file data. I suppose technically the standard doesn't require `tellg` to report a useful value (it's just a reusable marker value), but at least in binary mode, both POSIX systems and Windows report offset in bytes. – ShadowRanger Oct 10 '18 at 17:07
  • @ShadowRanger: Yeah, in practice probably. In theory, binary allows the system to append an arbitrary number of null bytes to the end of the data you write. In practice, systems that did that are mostly horribly obsolete, but the last time checked, the standard still allowed it. – Jerry Coffin Oct 10 '18 at 18:48

1 Answers1

2

It should work just fine. The C++ standard says about std::ios::ate

ate - open and seek to end immediately after opening

There's no reason it would fail when a manual open-then-seek would succeed. And tellg is the same in either case.

Cornstalks
  • 37,137
  • 18
  • 79
  • 144