Re: iostream and files larger than 4GB
On Jul 21, 8:39 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Robert Kochem wrote:
I am relative new to C++ regarding it's functions and
libraries. I need to access files larger than 4GB which is
AFAIK not possible with the STL iostream - at least not if
using a 32 bit compiler. iostream was my favorite as my code
has to work on files as well as memory buffers...
Have you actually tried and failed, or is that only your
speculation?
It's really implementation defined. I know that some
implementations do have this restriction.
Could somebody please help me what functions/classes are the
best in this case?
BTW: I am currently using Visual C++ 2008 on Win32, but if
possible I want to write my code as "portable as possible".
AFAIK, even standard C Library functions like fread and fseek
should work with large files.
According to what or who? The standards (both C and C++) are
really very, very vague about this (intentionally). I think
about all you can portably count on is that you can read
anything you can write. If the library doesn't allow writing
files with more than some upper limit of characters, then
there's no reason to assume that it can read them.
=46rom a quality of implementation point of view, of course, one
would expect that the library not introduce additional
restrictions not present in the OS. But backwards compatibility
issues sometimes pose problems: changing the size of off_t on a
Posix implementation breaks binary compatibility, for example.
So libc.so (the dynamic object which contains the system API and
the basic C library under Solaris) must stick with 32 bit file
offsets, or existing binaries will cease to work. And if
libc.so uses a 32 bit file offset, then any new code which links
against it must, too. So by default, fopen uses a 32 bit file
offset, and only allows access to the first 4 GB of a file, at
least in programs compiled in 32 bit mode. I don't know how
Windows handles this, but I'd be surprised if they didn't
encounter the same problems, at least to some degree.
The obvious solution would be to have three models, instead of
two: a pure 32 bit mode for legacy code, a 32 bit mode with 64
bit file offsets for new 32 bit code, and a 64 bit mode. On the
other hand, even coping with two different models on the same
machine can be confusing enough.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34