std::ios::binary?

[Stephen Howe]

I suspect there are "political" reasons things turned out the way they

did.
I really don't know how much of a performance hit it would be if certain
platforms had to do some extra endian shuffling. I do believe the lack of
real binary I/O in the Standard Library is an unexpected inconvenience.

Your beliefs are wrong. There is real binary I/O.
That is what the read() & write() member functions if istream and ostream
are for.

Stroustrup bluntly states that binary I/O is beyond the scope of C++
Standard, and beyond the scope of TC++PL(SE). §21.2.1

NO HE DOES NOT !!!!
You are misquoting . He says

"It is possible to define streams for which the physical I/O is not done in
terms of characters. However, such streams are beyond the scope of the C++
standard and beyond the scope of this book (21.10[15]) "

He is not talking abour binary I/O.

Stephen Howe

 

[Stephen Howe]

Get

yourself a copy of Java I/O, and read it. Consider what that is like for
the average 18 to 24-year-old trying cs major. Forget that you've been
doing this stuff for so ling that you can writhe hello worl in assebler
without looking anything up.

Frankly, you look like a complete moron to this newsgroup.
That may sound unkind but it is the honest truth.
To me, you seem just like Peter Olcott.
He was indulged in comp.lang.c++.moderated and comp.theory.
At one point he claimed to have overthrown the Halting Problem and Alan
Turing was wrong.
Check out thread
http://groups-beta.google.com/group...Halting+Problem&rnum=7&hl=en#513de627b7a574f3
where he admits his crack-pottery

But here in comp.lang.c++, ..., who do you think you are advising?
No doubt you will be advising P. J. Plauger that he should attend some ISO C
and C++ committee meetings or advising Stroustrup or Andrew Koenig that they
need to improve their knowledge on C when they have been on standardisation
committees measured in decades. You just look plain foolish.

Stephen Howe

 

[Stephen Howe]

Not in Unix, and not in Windows. However a binary file can contain any

And they call it a "standard"? :/

Yup. Implementions can vary a lot from embedded devices to PCs to minis to
mainframes.
Both the C and C++ standards give a lot of implementation freedom for
compilers
And that is why both languages have been very successful and will continue
to be so.

Sorry, I forgot one important point.
$ls -l binio-3.3.5
-rwxr-xr-x 1 hattons users 40830 2005-07-28 06:22 binio-3.3.5

###### note the file size above, and the second output value below:

$./binio-3.3.5 binio-3.3.5
read 40034bytes of data
read 40830bytes of data

As I understand things, when I do `file.rdbuf() >> oss' I am getting a raw
stream.

Yeah, so?

So is it the case that ios::binary may still not produce real binary
streams?

It will.

That is, the stream could still act in some ways like a text
stream, e.g., eof?

No. It is text mode you have to watch out for that is OS-specific.
Binary mode is simple.

Stephen Howe

 

[Alf P. Steinbach]

* Stephen Howe:

Frankly, you look like a complete moron to this newsgroup.
That may sound unkind but it is the honest truth.
To me, you seem just like Peter Olcott.
He was indulged in comp.lang.c++.moderated and comp.theory.
At one point he claimed to have overthrown the Halting Problem and Alan
Turing was wrong.
Check out thread
http://groups-beta.google.com/group...Halting+Problem&rnum=7&hl=en#513de627b7a574f3
where he admits his crack-pottery

But here in comp.lang.c++, ..., who do you think you are advising?
No doubt you will be advising P. J. Plauger that he should attend some ISO C
and C++ committee meetings or advising Stroustrup or Andrew Koenig that they
need to improve their knowledge on C when they have been on standardisation
committees measured in decades. You just look plain foolish.

That was uncalled for, Stephen. All this name-calling and
appeal-to-authority (which I don't think the authorities in question would
agree with!) etc. indicates that somewhere in this thread, and I don't care
to check, you have run out of arguments. An apology of about the same size
and intensity would be the right thing to do.

 

[P.J. Plauger]

* P.J. Plauger:

That's news to me. Exactly how does one do that in C++? Or, if it is an
operating system matter, in Windows (where it matters most, although Mac
is
also problematic in this regard)?

Take your favorite command interpreter and have it open files
in binary mode. How you present the standard streams to a
process you spawn (via system or exec) is system specific,
but it's straightforward. Just don't ask me for a good command
line notation for binary files -- I got grossed out somewhere
around 2>&1.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steven T. Hatton]

That was uncalled for, Stephen. All this name-calling and
appeal-to-authority (which I don't think the authorities in question would
agree with!) etc. indicates that somewhere in this thread, and I don't
care
to check, you have run out of arguments. An apology of about the same
size and intensity would be the right thing to do.

What I want to know is whether the Jerry Schwartz who designed the C++ I/O
is the same one who has recently been working on the Java memory model.

 

[Alf P. Steinbach]

* P.J. Plauger:

Take your favorite command interpreter and have it open files
in binary mode. How you present the standard streams to a
process you spawn (via system or exec) is system specific,
but it's straightforward. Just don't ask me for a good command
line notation for binary files -- I got grossed out somewhere
around 2>&1.

I'm sorry, that won't work, and is not very meaningful.

First, because the text-mode mangling & destruction of the data stream is
internal to the C++ libraries.

I.e. it can be there no matter what.

Second, because in e.g. Windows and Unix there's no such thing as having the
command interpreter opening the standard streams in binary mode or text mode
when running a program, and there's correspondingly no information about
that passed to the program, so it's not that I won't ask you for the
details: there are no such details. I think perhaps you're remembering
something about FTP command interpreters. FTP file transfer doesn't apply.

Third, because even if a C++ implementation did support an extension to set
the openmode of the standard streams (as I recall MSVC does support this,
but not any convention for passing openmode information into the program),
that would not be standard C++, and the point was about standard C++, not
what one can achieve using language/library extensions or assembly language.

Cheers,

- Alf

 

[Dietmar Kuehl]

I don't believe I can use iterators over a
non-text file reliably because they will detect content as EOF.

Nope, they don't. The problem is that you are doing text formatted
I/O with your choice of iterators. You want to use different
iterators:

copy(istream_iterator<unsigned char>(file)
, istream_iterator<unsigned char>()
, back_inserter(data));

This should read

std::copy(std::istreambuf_iterator<char>(file),
std::istreambuf_iterator<char>(),
std::back_inserter(data));

with a suitable definition of 'data'. Dump the ill-advised use of
'unsigned char' in this context and use 'istream*buf*_iterator'.
Actually, I guess that P.J.Plauger missed that you used the wrong
iterator class in this reply.

 

[Dietmar Kuehl]

You can't and you shouldn't. Actually, you would be well advised
to read the documentation of classes before guessing about their
semantics: if at all, you want to use 'gptr()' as your starting
point because the sequence [eback(), gptr()) consists of already
processed characters (... and your wrong use clearly shows that
you had no inkling about what you are doing).

No, it doesn't. You should operate on top of the stream buffer
abstraction, not within. Maybe you should at least try to
understand what the classes and functions are about and for.

 

[Dietmar Kuehl]

What I want to know is whether the Jerry Schwartz who designed the C++ I/O
is the same one who has recently been working on the Java memory model.

I don't know for sure but I consider it likely.

 

[Dietmar Kuehl]

http://www.cafeaulait.org/books/javaio/

How can C++ I/O be more like that without breaking it?

You mean, how can C++ abandon its easy to use I/O library in favor
of crap? Well, I prefer to stick with the current C++ I/O...

I want a clear and
easy way to create a std::vector<unsigned char> v(begin, end);

std::ifstream in("file", std::ios_base::binary);
std::vector<unsigned char> v((std::istreambuf_iterator<char>(in)),
std::istreambuf_iterator<char>());

Big deal.

 

[Steven T. Hatton]

You mean, how can C++ abandon its easy to use I/O library in favor
of crap? Well, I prefer to stick with the current C++ I/O...


std::ifstream in("file", std::ios_base::binary);
std::vector<unsigned char> v((std::istreambuf_iterator<char>(in)),
std::istreambuf_iterator<char>());

Big deal.

Won't that eat whitespaces?

 

[Steven T. Hatton]

You're presuming that you have to use unsigned char to transmit
binary date. While in principle you can make a perverse implementation
of C that corrupts char data and still conforms, in the real world
that doesn't happen. Just do the obvious with an ifstream opened in
binary mode and it'll work fine.

Actually that wasn't _my_ assumption. It's what someone else sugested I do.
I'm fairly well convinced that my original approach is completely viable.
That is to use std::stringstream and std::string. Especially since I plan
of parseing the object file. I just took this tangent because it bothered
me that I didn't know how to work with this stuff as well as I should.

 

[Steven T. Hatton]

I suspect you don't understand how istream_iterators work. They know
nothing of content, they just call on operator>>() to handle the
formatting.

Yes. That is corret. That part I understood.

How would an istream_iterator<MyType> know what values were
supposed to correspond to end-of-file? More prosaically, there's no such
character as EOF, so even an istream_iterator<char> would find it
difficult to interpret content as end-of-file. What really happens is
that they go into the end-of-file state when the underlying stream's
eof() becomes true, not when they see any particular content.

Again. That wasn't in question. It was simply easier to state it as I did.
Since not of the objects in question have eyes, none of them can actually
"see".

(Well, technically it shouldn't, but the reason is that ifstream is a

Did you try it?

I certainly did.

 

[Alf P. Steinbach]

* Steven T. Hatton:

Won't that eat whitespaces?

Read Dietmar's previous reply.

Anyway, the things that can be done easily, like the above, are of the
variety "error handling omitted", and it's not like what seems like an easy
way when presented to you is easy to come by when you don't already know it.

The popularity in certain circles seems to stem from the _complexity_, how
hard it is to use, and how it allows one to employ all sorts of "clever"
tricks to combat the inefficiency and unsafety, and how there is a whole
package of terminology mostly only understood by the converts, allowing easy
recognition of fellow believers and -- of course -- of unbelievers.

So, when Dietmar characterizes alternatives to the standard library's i/o
facilities as "crap", that should IMO be considered as an emotional
utterance from a believer to an agnostic who just possibly may be converted
to the one true faith, and whose rash, random questioning should be stopped
before it lands on some less easily handled or diverted topic.

Like, say, exceptions, or like, say, undefined behavior of input
conversions, or like, say, the inability to copy standard input to standard
output exactly, which is rather basic. Not to mention two-phase
initialization and other such ugliness in the internal design. Happily,
many practicing C++ programmers can choose whatever works or make it from
scratch, but students seldom can -- and that means we're putting them off.

 

[Steven T. Hatton]

(sample snipped for brevity)

The code works. It does not work as you expected, because your
expectations are wrong. You are doing default formatted stream input and
expcting a result according to different rules.

Try to unset skipws flag, for example.

That's what I always want with my sound files, and image files! Who needs a
bunch of white space anyway? They call _that_ binary? A big ol'
stream.set_unformatted_binary(), would have saved me a lot of time.
Thanks.

 

[Ian]

<quote>
streambuf: The Stream Buffer Classes
excerpted from pages 84-109 of Standard C++ IOStreams and Locales,
by Angelika Langer and Klaus Kreft

© 2000 by Addison Wesley Longman Inc.
Reproduced by permission of Addison Wesley Longman. All rights reserved.

You might wonder why on earth we devote 10+ pages of our book to the guts of
stream buffers, which seem to be nothing more than an implementation detail
of the IOStreams library. For an answer, let us quote Jerry Schwarz, the
"inventor" of IOStreams (quote taken from the foreword):

"A major goal in my original design was that it be extensible in
interesting ways. In particular, in the stream library the streambuf class
was an implementation detail, but in the iostream library I intended it to
be a usable class in its own right. I was hoping for the promulgation of
many streambufs with varied functionality. I wrote a few myself, but almost
no one else did. I answered many more questions of the form "how do I make
my numbers look like this" than "how do I write a streambuf". And textbook
authors also tended to ignore streambufs. Apparently they did not share my
view that the architecture of the input/output library was an interesting
case study."
</quote>

Spend some time with streambufs, get to know them well and maybe
implement one or two.

They are fun and very useful when understood.

Ian

 

[Steven T. Hatton]

The reasons probably are: some people must write and standarize it.
Compiler and library writers must implement it. And probably the people
that can benefit from it will keep prefering other languages instead of
C++ after all.

Technically speaking, it is not the perview of compiler writers, but rather
the library implementors. Yes, they are often one in the same. After you
posted, I began thinking about why there hasn't been as much contribution
as one might expect to something as important as the C++ Standard Library.
There /are/ several freely available I/O libraries for various kinds. Some
of them look very nice, and from experience with software that uses them,
some of the are very reliable, and powerful. The problem, I suspect, is
the licensing conflicts with the conditions of the C++ Standard.

But you can write, or initiate a project to write, such libraries and
propose it for inclusion in the standard.

Actually, what probably should be done is a much more difficult task. That
is to identify the abstract interfaces which effectively capture the common
aspects of the vast majority of existing, and probable implementation of
any given design domain such as local harddrive I/O. Also worth
considering is the further abstraction of the different I/O interfaces such
as harddrive, IPC, network, in order to create a baseclass for all I/O
instances. I'm really not talking about the existing std::ios_base, or
basic_ios. They may prove to provide some element of that interface, but I
am considering starting from tabular rasa.

These should be interfaces, sans data, or implemented functions.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

That's what I always want with my sound files, and image files! Who needs
a bunch of white space anyway? They call _that_ binary?

So do you think that the codes of whitespace characters are not binary?
Binary, as ther people say in this thread several times, is related only to
new line conventions and end of file detection. You have mixed the concept
of text/binary mode with the formatted/unformatted input, and you blame the
language for that?

A big ol' stream.set_unformatted_binary(), would have saved me a lot of
time.

Learning the ways the language already has to do things instead of expecting
that ways more likely to you are written will save you a lot more.

 

[Richard Herring]

Yes. That is corret. That part I understood.

It certainly didn't read that way. EOF is a macro, eof() is a member
function, end-of-file is a state, so your "EOF" is possibly ambiguous.

Again. That wasn't in question.

"iterators [...] will detect content" certainly suggested that you
thought istream_iterators detect content.

It was simply easier to state it as I did.

Easier for you... but since it's wrong, it requires more work on the
part of other people to clear up the misconceptions lest other readers
of this thread get the wrong message.

Since not of the objects in question have eyes, none of them can actually
"see".

It's a metaphor. If you have trouble with that, feel free to substitute
some periphrastic verbiage that expresses it more technically.

Metaphor aside, neither streams in binary mode, nor operator >>, nor
istream_iterators, use content to determine end of file.