By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,171 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

Problem with ofstream::seekp

P: n/a
Hi all!

I'm using ofstream and seekp to write a file. The problem is I have to
write a very big file, more than 4 Gb, but the streamoff that I have to
pass to seekp isn't a 64 bit int (it's a long int) so I can't use it!
Is it normal or there is some workaround for this?

Thank you

Sep 26 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
I'm going to explain better:

I have to write a big file to disk. I used ofstream and something like

int dim = 1024 * 1024;
ch = new char[dim];
os.write(ch,dim);

Then I had to use seekp to find the position of a certain buffer,
because I receive packets with the buffer to write, the lenght of the
buffer and the offset from the beginning of the file.
The problem is that the file could be bigger than 4 Gb, so when I use
seekp I get an error, or better it doesnt work. For example

long long int big = (long long int)5 * 1024 * 1024 * 1024;
os.seekp(big,ios_base::beg);
cout << os.tellp();

The output of this piece of code is -1!!!!!

Is there a way to use seekp with 64 bit integers?
If not, I think I'll have to try to use os.open(filename,
ios_base::ate) (it gets me to the end of file rigth??), but first I
wanted to try seekp, because I wouldn't have to save a non aligned
packet in memory...

Thank you for your help!

Paolo

Sep 27 '06 #2

P: n/a
Paolo wrote:
I'm going to explain better:

I have to write a big file to disk. I used ofstream and something
like

int dim = 1024 * 1024;
ch = new char[dim];
os.write(ch,dim);

Then I had to use seekp to find the position of a certain buffer,
because I receive packets with the buffer to write, the lenght of
the
buffer and the offset from the beginning of the file.
The problem is that the file could be bigger than 4 Gb, so when I
use
seekp I get an error, or better it doesnt work. For example

long long int big = (long long int)5 * 1024 * 1024 * 1024;
os.seekp(big,ios_base::beg);
cout << os.tellp();

The output of this piece of code is -1!!!!!
That indicates a failure.
Is there a way to use seekp with 64 bit integers?
Only on systems that has a 64 bit long. The long long type isn't (yet)
part of the C++ standard, so the library can't really use it.
If not, I think I'll have to try to use os.open(filename,
ios_base::ate) (it gets me to the end of file rigth??), but first I
wanted to try seekp, because I wouldn't have to save a non aligned
packet in memory...
How large is the file really? Is it *much* larger that 4 GB? If not,
you could perhaps divide your offset into a few separate seeks, moving
4 GB at a time. Or seek from ios_base::cur, or ios_base::end?
Bo Persson
Sep 27 '06 #3

P: n/a

Bo Persson ha scritto:
Paolo wrote:
I'm going to explain better:

I have to write a big file to disk. I used ofstream and something
like

int dim = 1024 * 1024;
ch = new char[dim];
os.write(ch,dim);

Then I had to use seekp to find the position of a certain buffer,
because I receive packets with the buffer to write, the lenght of
the
buffer and the offset from the beginning of the file.
The problem is that the file could be bigger than 4 Gb, so when I
use
seekp I get an error, or better it doesnt work. For example

long long int big = (long long int)5 * 1024 * 1024 * 1024;
os.seekp(big,ios_base::beg);
cout << os.tellp();

The output of this piece of code is -1!!!!!

That indicates a failure.
Is there a way to use seekp with 64 bit integers?

Only on systems that has a 64 bit long. The long long type isn't (yet)
part of the C++ standard, so the library can't really use it.
If not, I think I'll have to try to use os.open(filename,
ios_base::ate) (it gets me to the end of file rigth??), but first I
wanted to try seekp, because I wouldn't have to save a non aligned
packet in memory...

How large is the file really? Is it *much* larger that 4 GB? If not,
you could perhaps divide your offset into a few separate seeks, moving
4 GB at a time. Or seek from ios_base::cur, or ios_base::end?
Bo Persson
Thank you fr your answer. The file could be much bigger than 4 Gb,
maybe twice or three times. I think I'll use a 32 bit int for offset,
and another one to check if it'sin the first 4 Gb, the second one and
so on. This way I will have tha same result as using 64 bit integers.
Thank you for your clarification about seekp!

Bye

Paolo

Sep 27 '06 #4

P: n/a

Bo Persson ha scritto:
Paolo wrote:
I'm going to explain better:

I have to write a big file to disk. I used ofstream and something
like

int dim = 1024 * 1024;
ch = new char[dim];
os.write(ch,dim);

Then I had to use seekp to find the position of a certain buffer,
because I receive packets with the buffer to write, the lenght of
the
buffer and the offset from the beginning of the file.
The problem is that the file could be bigger than 4 Gb, so when I
use
seekp I get an error, or better it doesnt work. For example

long long int big = (long long int)5 * 1024 * 1024 * 1024;
os.seekp(big,ios_base::beg);
cout << os.tellp();

The output of this piece of code is -1!!!!!

That indicates a failure.
Is there a way to use seekp with 64 bit integers?

Only on systems that has a 64 bit long. The long long type isn't (yet)
part of the C++ standard, so the library can't really use it.
If not, I think I'll have to try to use os.open(filename,
ios_base::ate) (it gets me to the end of file rigth??), but first I
wanted to try seekp, because I wouldn't have to save a non aligned
packet in memory...

How large is the file really? Is it *much* larger that 4 GB? If not,
you could perhaps divide your offset into a few separate seeks, moving
4 GB at a time. Or seek from ios_base::cur, or ios_base::end?
Bo Persson
Thank you for your answer. The file could be much bigger than 4 Gb,
maybe twice or three times. Thank you for your answer anyway, I'll try
ios_base::app!

Bye

Paolo

Sep 27 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.