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

ifstream

P: n/a
ifstream ifs;
ifs.open("whatever.bin", ios::in | ios::binary);

How to set flag above so that if "whatever.bin" file missing, rather than
create a new file named "whatever.bin", but providing a way to detect the
error?

ifs.read((char *)p, 4);

Does each "read()" call above read only in bytes? Is it possible to
directly read in ints? Like ifs.read((int *)p, 1);

ifs.read((char *)p, 16);

How to obtain 4 ints out of p pointing to 16 bytes?

Thanks!
Jul 22 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
"Dart" <da******@dickto.com> wrote...
ifstream ifs;
ifs.open("whatever.bin", ios::in | ios::binary);

How to set flag above so that if "whatever.bin" file missing, rather than
create a new file named "whatever.bin", but providing a way to detect the
error?
Since you use 'ios::in', it shouldn't create. Why would it?

The Standard says that 'open' can set 'failbit', so after an attempt
to open a file, check if it has been in fact open:

if (ifs.is_open())
...

ifs.read((char *)p, 4);

Does each "read()" call above read only in bytes? Is it possible to
directly read in ints? Like ifs.read((int *)p, 1);
No, the low-level I/O works only in chars.

ifs.read((char *)p, 16);

How to obtain 4 ints out of p pointing to 16 bytes?


Often you can simply reinterpret_cast the pointer to treat your 'p'
as an array of ints. It's not portable, of course, use at your own
risk.

Victor
Jul 22 '05 #2

P: n/a
Dart wrote:
ifstream ifs;
ifs.open("whatever.bin", ios::in | ios::binary);
If portability (of the data files) is a concern you should consider
doing formatted input and output instead (with << and >>).
How to set flag above so that if "whatever.bin" file missing, rather than
create a new file named "whatever.bin", but providing a way to detect the
error?
On my system the behaviour is already what you're asking for. I can't
attest to the portability of this, as the standard just says that the
file is opened "as if" by calling fopen, and my documentation for fopen
isn't clear on this point.
ifs.read((char *)p, 4);

Does each "read()" call above read only in bytes?
Yes.
Is it possible to directly read in ints? Like ifs.read((int *)p, 1);
It depends what you mean by directly. Here's an idea:

template <typename T>
std::istream & read_natively (std::istream & stream, T & var)
{
char * mem = reinterpret_cast <char *> (& var);
return stream.read (mem, sizeof var);
}

// ...

int x;
if (read_natively (ifs, x)) /* ... */;
ifs.read((char *)p, 16);

How to obtain 4 ints out of p pointing to 16 bytes?


int a [4];
read_natively (ifs, a); // might not work on broken old compilers

--
Regards,
Buster.
Jul 22 '05 #3

P: n/a
Victor Bazarov <v.********@comAcast.net> wrote in message news:du2fc.32356>
ifs.read((char *)p, 16);

How to obtain 4 ints out of p pointing to 16 bytes?


Often you can simply reinterpret_cast the pointer to treat your 'p'
as an array of ints. It's not portable, of course, use at your own
risk.

Victor

Is this going to work?

int arr[4];
arr = reinterpret_cast<int *>(p);

Thanks!
Jul 22 '05 #4

P: n/a
Dart wrote:

Is this going to work?

int arr[4];
arr = reinterpret_cast<int *>(p);


Of course not. You can't assign to an array.

int *ip = reinterpret_cast<int *>(p);

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #5

P: n/a
Dart wrote:
Is this going to work?

int arr[4];
arr = reinterpret_cast<int *>(p);


No, it's a syntax error. Your compiler would have told you this
if you had taken a minute to try. What was it you wanted to do?

--
Regards,
Buster.
Jul 22 '05 #6

P: n/a
"Buster" <no***@nowhere.com> wrote in message
news:c5**********@newsg3.svr.pol.co.uk...

If portability (of the data files) is a concern you should consider
doing formatted input and output instead (with << and >>).


Are you talking of the big endian and little endian thing?

13 = 0000 1101

may be stored as

0000 1101
1011 0000

Jul 22 '05 #7

P: n/a

"Siemel Naran" <Si*********@REMOVE.att.net> wrote in message
news:EM********************@bgtnsc04-news.ops.worldnet.att.net...
"Buster" <no***@nowhere.com> wrote in message
news:c5**********@newsg3.svr.pol.co.uk...

If portability (of the data files) is a concern you should consider
doing formatted input and output instead (with << and >>).


Are you talking of the big endian and little endian thing?

13 = 0000 1101

may be stored as

0000 1101
1011 0000


Big endian, little endian is just one example of the way in which binary I/O
is completely non-portable between different systems.

john
Jul 22 '05 #8

P: n/a
John Harrison wrote:

Big endian, little endian is just one example of the way in which binary I/O
is completely non-portable between different systems.


Depends a lot on how you use it. There are hundreds of binary file
formats in common use that are portable to most common systems.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #9

P: n/a

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:Vy*****************@newsread2.news.pas.earthl ink.net...
John Harrison wrote:

Big endian, little endian is just one example of the way in which binary I/O is completely non-portable between different systems.


Depends a lot on how you use it. There are hundreds of binary file
formats in common use that are portable to most common systems.


That's the 'in the real world' answer, which is fair comment. I was giving
the 'C++ standard' answer which says that binary I/O is non portable.

john
Jul 22 '05 #10

P: n/a
John Harrison wrote:

That's the 'in the real world' answer, which is fair comment. I was giving
the 'C++ standard' answer which says that binary I/O is non portable.


Honestly, I'm not sure I understand why. The only really hard problem I
see is the possibility of CHAR_BIT > 8. Other problems I can think of
are hard, but not impossible (like floating point values -- you can
choose a standard format, but translating to and from it could be quite
tricky, and precision may be lost).

Would you care to explain your take on it?

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #11

P: n/a

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:Vg*****************@newsread1.news.pas.earthl ink.net...
John Harrison wrote:

That's the 'in the real world' answer, which is fair comment. I was giving the 'C++ standard' answer which says that binary I/O is non portable.


Honestly, I'm not sure I understand why. The only really hard problem I
see is the possibility of CHAR_BIT > 8. Other problems I can think of
are hard, but not impossible (like floating point values -- you can
choose a standard format, but translating to and from it could be quite
tricky, and precision may be lost).

Would you care to explain your take on it?


On what? The decision of the C++ standards committee to say that binary I/O
is non-portable? I would imagine that they just didn't want to constrain
implementations of C++. For instance with floating point formats, you would
either have to force every one to use a particular format internally or to
use different formats internally and convert on input or output. The first
is obviously a non-starter with the different floating point hardware out
there, and the second rather defeats the purpose of binary I/O which is
maximum efficiency without regard for anything else. If you are going to do
conversions then you might as well convert to text.

At least that's my take on it.

john
Jul 22 '05 #12

P: n/a
John Harrison wrote:

On what? The decision of the C++ standards committee to say that binary I/O
is non-portable?
Could you indicate where they say that? I'd like to take a look at it.
I would imagine that they just didn't want to constrain
implementations of C++. For instance with floating point formats, you would
either have to force every one to use a particular format internally or to
use different formats internally and convert on input or output. The first
is obviously a non-starter with the different floating point hardware out
there, and the second rather defeats the purpose of binary I/O which is
maximum efficiency without regard for anything else. If you are going to do
conversions then you might as well convert to text.

At least that's my take on it.


Fair enough. Though it's certainly possible that one might want to read
and/or write files in one of the many already-in-use binary formats.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #13

P: n/a
Kevin Goodsell wrote:
John Harrison wrote:

That's the 'in the real world' answer, which is fair comment. I was
giving the 'C++ standard' answer which says that binary I/O is non
portable.


Honestly, I'm not sure I understand why. The only really hard problem
I see is the possibility of CHAR_BIT > 8. Other problems I can think
of are hard, but not impossible (like floating point values -- you can
choose a standard format, but translating to and from it could be
quite tricky, and precision may be lost).


Another problem is that on one system, int might be 16 bit, on another
32 bit, and on the third 24 bit. Then there could be alingment
problems, writing something to disk with another alignment than would
be needed when read in again.

Jul 22 '05 #14

P: n/a
Rolf Magnus wrote:
Another problem is that on one system, int might be 16 bit, on another
32 bit, and on the third 24 bit. Then there could be alingment
problems, writing something to disk with another alignment than would
be needed when read in again.


This shouldn't be a problem if it's done properly, though. The file
format dictates the size of the field and the byte order -- just read in
that many bytes into a byte array, then shift and add those bytes into
your variable as needed (just make sure you choose a type that's large
enough).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #15

P: n/a

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:%I*****************@newsread2.news.pas.earthl ink.net...
John Harrison wrote:

On what? The decision of the C++ standards committee to say that binary I/O is non-portable?


Could you indicate where they say that? I'd like to take a look at it.


I'm not sure that they do say it in so many words. I think you'd have to
cross reference several sections to work it out. If anyone else knows better
I'd also be interested.

john
Jul 22 '05 #16

P: n/a
Kevin Goodsell <us*********************@neverbox.com> wrote in message
news:ID*****************@newsread2.news.pas.earthl ink.net...
Dart wrote:

Is this going to work?

int arr[4];
arr = reinterpret_cast<int *>(p);


Of course not. You can't assign to an array.

int *ip = reinterpret_cast<int *>(p);

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.


The test program is:

char a[4];
a[0] = 0x12;
a[1] = 0x34;
a[2] = 0x56;
a[3] = 0x67;

int* intp = reinterpret_cast<int *>(a);
cout << hex << intp;

The output is: 0012FED4.

Why 0x12, 0x34, 0x56, 0x67 not displayed?

When declaring an array, whatever_array[N], is it always that all elements
in the array are consecutive in memory?
Jul 22 '05 #17

P: n/a
"Dart" <da******@dickto.com> wrote in message
news:uVnfc.25944$K_.670908@bgtnsc05-
The test program is:

char a[4];
a[0] = 0x12;
a[1] = 0x34;
a[2] = 0x56;
a[3] = 0x67;

int* intp = reinterpret_cast<int *>(a);
cout << hex << intp;
Note this is disaster if sizeof(int) is more than 4 bytes. There are some 8
byte machines out there.
The output is: 0012FED4.

Why 0x12, 0x34, 0x56, 0x67 not displayed?
You're printing the address of the pointer. Probably you meant to use *intp
cout << hex << *intp;
I'm using Borland 6, AMD, Windows ME. My result is with *intp is
"67563412". Would this be big endian or little endian?
When declaring an array, whatever_array[N], is it always that all elements
in the array are consecutive in memory?


Yes.
Jul 22 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.