This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
RE: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
- From: Pétur Runólfsson <peturr02 at ru dot is>
- To: "Nathan Myers" <ncm-nospam at cantrip dot org>,<libstdc++ at gcc dot gnu dot org>
- Date: Wed, 9 Jul 2003 10:09:41 -0000
- Subject: RE: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
Nathan Myers wrote:
> The type safety argument dictates that we should use a class type
> for std::streamoff containing a 64-bit integer type,
I agree.
> and publicly defining (only!) the operations required in 27.4.3.2,
Those operations seem to be conversion to and from streamsize and
fpos<StateT>, and arithmetic involving fpos<StateT>. That seems
very restrictive. Shouldn't there at least be support for
+m, -m, ++m, m++, --m, m--, m + n, m - n, m += n, m -= n,
m > n, m >= n, m < n, m <= n, m == n, m != n
on streamoff objects m and n?
> Internally we can use undocumented members to extract and set the
> 64-bit value for use with lseek64 or what have you.
traits_type::off_type doesn't need to be streamoff, the behaviour is
implementation defined if it isn't, so it seems those members would
need to be documented.
There must be a simple way to construct streamoff from 64-bit
integers, also on platforms on which streamsize is 32 bits; otherwise
it will be impossible to actually use the large file support.
Example: Seeking to a point 60GB from the beginning of the file:
filebuf fb;
...
long long GB = 1000000000LL;
fb.pubseekoff(60 * GB, ios::beg);
Shouldn't this work?
Petur