std::ios::binary?

[Steven T. Hatton]

Steven T. Hatton wrote:

Well, I _am_ interested because I am (was) under the impression that
std::cout.rdbuf() would give me raw data. but now, it seems as if it
might
kill spiders, or something like that. The standard streams may actually
be bad examples since they are very OS specific.

How 'bout this?

#include <fstream>
#include <iostream>

using namespace std;

int main(int argc, char* argv[]) {
if(argc < 3) { cerr<<"in_file_name out_file_name"<< endl; return -1; }

ifstream ifs(argv[1],ios::binary);
if(!ifs) { cerr<<" failed to open input file: "<<argv[1]<<endl; return
-1; }

ofstream ofs(argv[2],ios::binary);
if(!ofs) { cerr<<" failed to open output file: "<<argv[2]<<endl; return
-1; }
ofs << ifs.rdbuf();
}

 

[Alf P. Steinbach]

* Steven T. Hatton:

Well, I _am_ interested because I am (was) under the impression that
std::cout.rdbuf() would give me raw data. but now, it seems as if it might
kill spiders [control characters], or something like that.

It does.

The standard streams may actually be bad examples since they are very
OS specific.

The OS specificity is common to all streams; the standard streams are not
special in this regard and do no special processing, have special features
etc., except there's no standard C++ way, AFAIK, to turn off their standard
C++ stream objects' trashing of the data.

 

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

Also, for example, in a Windows text file Ctrl Z denotes end-of-file.
That's useful for including a short descriptive text snippet at the start
of a binary file, but I suspect it was originally a misunderstanding of
the Unix shell command to send the current line immediately (which for an
empty line means zero bytes, which in Unix indicates end-of-file).
So in text mode in Windows, a Ctrl Z might be translated to end-of-file
on input.

The ctrl-z convention in ms-dos is inherited from cp/m operating systems,
they used such convention because they not stored the exact length of the
file, only the number of sectors used. Mark the end with an special
character was the easier solution.

But the ctl-z was not required. If the text file size was a multiple of the
sector size, inserting the eof mark was not required to avoid wasting 1
sector (dozens of GiB disks were not very popular on small systemes those
days ;-) ).

 

[P.J. Plauger]

* P.J. Plauger:

* Alf P. Steinbach

* P.J. Plauger:

Interestingly the C++ iostream utilities are so extremely badly
designed that you can't make a simple copy-standard-input-to-
standard-output-exactly program using only the standard C++
library, on systems where this is meaningful but text translation
occurs in text mode.

Well, yes you can. Open files in binary mode and use read/write.

That should be only a few lines; could you please present the code?

#include <fstream>

int main(int argc, char **argv)
{ // copy a file
if (2 < argc)
{ // copy argv[1] to argv[2] transparently
std::ifstream ifs(argv[1],
std::ios_base::in | std::ios_base::binary);
std:fstream ofs(argv[2],
std::ios_base:ut | std::ios_base::binary);

ofs << ifs.rdbuf();
}
return (0);
}

(I was wrong about needing read and write.)

Thanks for the code.

Since I (naturally) don't use iostreams much -- and in fact it's been
some
time since I did C++ development -- I learned a new idiom.

And you weren't wrong about read and write: it can be done that way.

I was wrong that read and write are necessary, that's all.

What you were wrong about:

The above doesn't copy standard input to standard output. ;-)

Sorry, I missed that bit. It is true in C90/C95 that you can't
freopen a standard stream to change its mode; it *might* work
properly in C99 but it's not guaranteed. So it has indeed been
a longstanding limitation of Standard C that you can't idly
switch between text and binary I/O, any more than you can idly
switch between byte and wide-character I/O. But that's generally
a minor nuisance. The existence of portable software tools,
such as the MKS Toolkit, shows that you can still implement much
of the Unix idiom on arbitrary operating systems.

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

 

[P.J. Plauger]

* P.J. Plauger:

Interestingly the C++ iostream utilities are so extremely badly
designed
that you can't make a simple
copy-standard-input-to-standard-output-exactly
program using only the standard C++ library, on systems where this is
meaningful but text translation occurs in text mode.

Well, yes you can. Open files in binary mode and use read/write.

That should be only a few lines; could you please present the code?

#include <fstream>

int main(int argc, char **argv)
{ // copy a file
if (2 < argc)
{ // copy argv[1] to argv[2] transparently
std::ifstream ifs(argv[1],
std::ios_base::in | std::ios_base::binary);
std:fstream ofs(argv[2],
std::ios_base:ut | std::ios_base::binary);

ofs << ifs.rdbuf();
}
return (0);
}

(I was wrong about needing read and write.)

Josuttis provides a similar example.

What I would like to know is how to get in iterator over a buffer such as
std::basic_filebuf, so that I can do something like:


copy(istream_iterator<unsigned char>(file_buf.eback())
, istream_iterator<unsigned char>(file_buf.egptr())
, back_inserter(data));

Which I can't do without inheriting from the buffer. That makes binary
I/O
seem inconsistent with the rest of the library.

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.

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

 

[P.J. Plauger]

Dose this potentially modify the stream data? If so, where?

/* The following code example is taken from the book
* "The C++ Standard Library - A Tutorial and Reference"
* by Nicolai M. Josuttis, Addison-Wesley, 1999
*
* (C) Copyright Nicolai M. Josuttis 1999.
* Permission to copy, use, modify, sell and distribute this software
* is granted provided this copyright notice appears in all copies.
* This software is provided "as is" without express or implied
* warranty, and with no claim as to its suitability for any purpose.
*/
#include <iostream>

int main ()
{
// copy all standard input to standard output
std::cout << std::cin.rdbuf();
}

It can, on all but Unix systems. As frequently described earlier
in this thread, reading a text stream under Windows converts CR/LF
to LF and stops reading at CTL-Z.

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

 

[P.J. Plauger]

* Steven T. Hatton:

Well, I _am_ interested because I am (was) under the impression that
std::cout.rdbuf() would give me raw data. but now, it seems as if it
might
kill spiders [control characters], or something like that.

It does.

The standard streams may actually be bad examples since they are very
OS specific.

The OS specificity is common to all streams; the standard streams are not
special in this regard and do no special processing, have special features
etc., except there's no standard C++ way, AFAIK, to turn off their
standard
C++ stream objects' trashing of the data.

What's special about the standard streams is that they're opened
in text mode prior to program startup. At least that's how command
interpreters (shells) almost always work. Nothing prevents you from
starting a program with its standard streams opened in binary
mode, however.

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

 

[Steven T. Hatton]

Sorry, I missed that bit. It is true in C90/C95 that you can't
freopen a standard stream to change its mode; it *might* work
properly in C99 but it's not guaranteed. So it has indeed been
a longstanding limitation of Standard C that you can't idly
switch between text and binary I/O, any more than you can idly
switch between byte and wide-character I/O. But that's generally
a minor nuisance. The existence of portable software tools,
such as the MKS Toolkit, shows that you can still implement much
of the Unix idiom on arbitrary operating systems.

I have no doubt whatsoever that C++ apps _can_ be ported to Windows and act
like the run on GNU/Linux an other Unix oriented systems. You can run the
KDE on Windows! But I am fairly well convinced that C#, C#++ (aka C++/CLI)
and Java will be more portable for the average developer than C++ is. 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.

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

How can C++ I/O be more like that without breaking it? I want a clear and
easy way to create a std::vector<unsigned char> v(begin, end);
where /begin/ and /end/ are the start and end+1 of a file opened in binary
mode.

Any, yes, the last I looked, Java is impemented in C and C++ with a whole
bunch of asm stuff mixed in.

 

[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.

The type conversion isn't the issue. The issue is that I want it to act
like an STL container. I don't believe I can use iterators over a non-text
file reliably because they will detect content as EOF.

This won't work on a std::ifstream opened in binary mode:

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

 

[Richard Herring]

The type conversion isn't the issue. The issue is that I want it to act
like an STL container. I don't believe I can use iterators over a non-text
file reliably because they will detect content as EOF.

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

This won't work on a std::ifstream opened in binary mode:

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

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

Did you try it?

 

[P.J. Plauger]

I have no doubt whatsoever that C++ apps _can_ be ported to Windows and
act
like the run on GNU/Linux an other Unix oriented systems. You can run the
KDE on Windows! But I am fairly well convinced that C#, C#++ (aka
C++/CLI)
and Java will be more portable for the average developer than C++ is.

C# and Java benefit from running on just one (virtual) system.
They avoid the multiplicity of text file formats in the real
world by, well, avoiding the multiplicity of text file formats
in the real world. C and C++, by contrast, have faced the
problem head on for many years and have dealt with it pretty
successfully.

Get
yourself a copy of Java I/O, and read it.

Did so years ago. We've even implemented it and licensed it to
others. But don't get Pete Becker started on all the things wrong
with Java I/O, however, because he bore the brunt of the effort.

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.

Thanks for the advice, but I've been writing tutorial books (over
a dozen) and articles (about 350) for several decades now. I spend
a *lot* of time considering such matters.

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

How can C++ I/O be more like that without breaking it? I want a clear and
easy way to create a std::vector<unsigned char> v(begin, end);
where /begin/ and /end/ are the start and end+1 of a file opened in binary
mode.

I can think of several ways of doing this, none of which are
particularly hard. Or hard to teach, at least to a student
with an open mind.

Any, yes, the last I looked, Java is impemented in C and C++ with a whole
bunch of asm stuff mixed in.

What a coincidence. C is implemented in C, with just a little bit
of assembly language mixed in. And C++ is implemented in C and C++,
with just a little bit of assembly language mixed in. Coincidence?
I don't think so.

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

 

[P.J. Plauger]

The type conversion isn't the issue. The issue is that I want it to act
like an STL container. I don't believe I can use iterators over a
non-text
file reliably because they will detect content as EOF.

This won't work on a std::ifstream opened in binary mode:

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

You're simply wrong.

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

 

[Steven T. Hatton]

C# and Java benefit from running on just one (virtual) system.
They avoid the multiplicity of text file formats in the real
world by, well, avoiding the multiplicity of text file formats
in the real world. C and C++, by contrast, have faced the
problem head on for many years and have dealt with it pretty
successfully.

My response is this: Java and C# provide their portability at runtime. They
run on an abstraction layer which maps their data and I/O representations
to platform specific representations. Mathematica also does this kind of
thing. Bear in mind that Gosling was the first to port Emacs to C. That's
byte-compiled, garbage-collected, exception-throwing, pointerless (from the
user's perspective) library-loading, ELisp virtual machine, Emacs.

Two other noteworthy programmers got their start in XEmacs, which is a fork
of Emacs that tries to remain compatable. Marc Andreesen and Jamie
Zawinski. They were two of the most significant actors in the creation of
Netscape. Netscap uses a somewhat different approach to platform
abstraction than to CLI and the JVM. It's called the Netscape Portable
Runtime. It's kind of like Netcape/Mozilla has the virtual machine built
in to it. Look at the TOC and you should be able to understand it as an
outline of a collection of interfaces:

http://www.mozilla.org/projects/nspr/reference/html/index.html

Mozilla has many features similar to Emacs, such as the built-in
interpreter, the event loop, the multiple buffers, etc.


The C++ approach should be to provide the abstraction in the form of source
code that can be optionally compiled into the user's program to the minimal
extent it is useful.

Did so years ago. We've even implemented it and licensed it to
others. But don't get Pete Becker started on all the things wrong
with Java I/O, however, because he bore the brunt of the effort.

I never said it was perfect. And I am not speaking from the implementor's
perspective. I am talking about the ease of use, and relative uniformity
of interfaces.

Thanks for the advice, but I've been writing tutorial books (over
a dozen) and articles (about 350) for several decades now. I spend
a *lot* of time considering such matters.

I'm not sure if you can appreciate how inelegant C++'s I/O library looks
from my perspective. Don't get me wrong, there are nice parts of it too.
Nonetheless, it's difficult trying to remember the meaning of a couple
dozen cryptically named state flags, the counter intuitive functions to
read and modify their values, the half a dozen pointers into the input and
output buffers (eback is the front, mind you), which function such as
snextc() calls another function such as sbumpc(), and under what
conditions, what the difference between uflow() and underflow() is, etc.

That doesn't even address the couple dozen <cstdio> functions. It's hard
to know what function and flags are relevant to the current state. Which
function are redundant, which modifications to the stream state only apply
for the duration of one function call to the stream extractor or inserter,
how to save the state of the stream before you modify it, so that you can
recover it, etc.

All that lowlevel stuff is useful in some circumstances, but there is no
coherent interface for a person who wants to work with a file (in the Unix
sense). There should be file descriptor objects that provides information
about the file such as is typically found on any operating system. The
abstraction doesn't have to be part of a runtime virtual machine. It can
be a simple abstract base class or class template that is implemented for
each environment. I want to open the file and read it into whatever buffer
is best suited to my application. I shouldn't need to remember a whole
bunch of information, or pull out some esoteric function just because I
want raw data.

What's a binary stream? Well, it's kind of like a stream of text, except it
doesn't modify the data to suit the platform. Can I use it to read binary
data? Well, sort of, but there are a few caveats which you will probably
have to figure out through experimentation. What is the underlying data
representation? It depends.

So far, in the past 48 hours I've seen three examples of veteran programmers
not fully understanding basic notions associated with C++ I/O.

I can think of several ways of doing this, none of which are
particularly hard. Or hard to teach, at least to a student
with an open mind.

Where's my_binary_file.begin() and my_binary_file.end()?

What a coincidence. C is implemented in C, with just a little bit
of assembly language mixed in. And C++ is implemented in C and C++,
with just a little bit of assembly language mixed in. Coincidence?
I don't think so.

That's great, but I see no reason that C++ should fail to provide a higher
level of abstraction which presents the low level services it can
manipulate, in a coherent, minimal, yet complete interface.

 

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

That's great, but I see no reason that C++ should fail to provide a higher
level of abstraction which presents the low level services it can
manipulate, in a coherent, minimal, yet complete interface.

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.

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

 

[P.J. Plauger]

My response is this: Java and C# provide their portability at runtime.
They
run on an abstraction layer which maps their data and I/O representations
to platform specific representations. Mathematica also does this kind of
thing.

So does C (and C++). You just happen not to like that model.

The C++ approach should be to provide the abstraction in the form of
source
code that can be optionally compiled into the user's program to the
minimal
extent it is useful.

Agreed, and it does, IMO.

I never said it was perfect. And I am not speaking from the implementor's
perspective. I am talking about the ease of use, and relative uniformity
of interfaces.

So was I. There's nothing like implementing something to see all the
traps and pitfalls waiting for the unwary. And there's nothing like
providing commercial support for learning how the unwary programmers
fall into those traps.

I'm not sure if you can appreciate how inelegant C++'s I/O library looks
from my perspective.

Oh, I can. I just don't much care, since you seem to think your
opinion weighs more than the experiences of several million
programmers over several decades.

Don't get me wrong, there are nice parts of it too.
Nonetheless, it's difficult trying to remember the meaning of a couple
dozen cryptically named state flags, the counter intuitive functions to
read and modify their values, the half a dozen pointers into the input and
output buffers (eback is the front, mind you), which function such as
snextc() calls another function such as sbumpc(), and under what
conditions, what the difference between uflow() and underflow() is, etc.

That doesn't even address the couple dozen <cstdio> functions. It's hard
to know what function and flags are relevant to the current state. Which
function are redundant, which modifications to the stream state only apply
for the duration of one function call to the stream extractor or inserter,
how to save the state of the stream before you modify it, so that you can
recover it, etc.

All that may be true, but only a tiny fraction of programmers have
to work at those levels. And Java has comparable mysteries at the
same subterranean levels.

All that lowlevel stuff is useful in some circumstances, but there is no
coherent interface for a person who wants to work with a file (in the Unix
sense). There should be file descriptor objects that provides information
about the file such as is typically found on any operating system. The
abstraction doesn't have to be part of a runtime virtual machine. It can
be a simple abstract base class or class template that is implemented for
each environment. I want to open the file and read it into whatever
buffer
is best suited to my application. I shouldn't need to remember a whole
bunch of information, or pull out some esoteric function just because I
want raw data.

What's a binary stream? Well, it's kind of like a stream of text, except
it
doesn't modify the data to suit the platform. Can I use it to read binary
data? Well, sort of, but there are a few caveats which you will probably
have to figure out through experimentation. What is the underlying data
representation? It depends.

So far, in the past 48 hours I've seen three examples of veteran
programmers
not fully understanding basic notions associated with C++ I/O.

Okay, I got that you don't understand C++ iostreams, or even C
file I/O. And, following your usual modus operandi, you're
making the rest of the world wrong for your frustration. You
can always do it over right. Or go back to Java.

Where's my_binary_file.begin() and my_binary_file.end()?

See istreambuf_iterator and stop whingeing.

That's great, but I see no reason that C++ should fail to provide a higher
level of abstraction which presents the low level services it can
manipulate, in a coherent, minimal, yet complete interface.

I think it does, at least well enough. YM(obviously)V.

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

 

[Steven T. Hatton]

You're simply wrong.

Are you sure about that?

hattons@ljosalfr:~/code/c++/scratch/binary/
Thu Jul 28 15:59:00:> cat main.cpp
#include <fstream>
#include <vector>
#include <iterator>
#include <iostream>
#include <sstream>

using namespace std;

main(int argc, char* argv[]){
if(argc<2) { cerr << "give me a file name" << endl; return -1; }

ifstream file (argv[1],ios::binary|ios::in);
if(!file) { cerr << "couldn't open the file:"<< argv[1] << endl; return
-1; }


cout<<"File "<<argv[1]<<" openemode = ios::binary|ios::in "<< endl;

std::vector<unsigned char> data;

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

cout<<"Read "<<data.size()<<"bytes of data"<< endl;

file.clear();
file.seekg(0,ios::beg);
ostringstream oss;
oss << file.rdbuf();

cout<<"Read "<<oss.str().size()<<"bytes of data"<< endl;

}
hattons@ljosalfr:~/code/c++/scratch/binary/
Thu Jul 28 15:59:06:> g++ -obinio main.cpp
hattons@ljosalfr:~/code/c++/scratch/binary/
Thu Jul 28 15:59:21:> ./binio binio
File binio openemode = ios::binary|ios::in
Read 40157bytes of data
Read 40974bytes of data
hattons@ljosalfr:~/code/c++/scratch/binary/
Thu Jul 28 15:59:30:> ls -l binio

 

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

Are you sure about that?

(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.

 

[Steven T. Hatton]

So does C (and C++). You just happen not to like that model.

You're playing semantics, and you know damn good and well what I meant.

Agreed, and it does, IMO.

It could do far better.

So was I. There's nothing like implementing something to see all the
traps and pitfalls waiting for the unwary. And there's nothing like
providing commercial support for learning how the unwary programmers
fall into those traps.

Hmmm... I know what my experience was. It was relatively easy to pick up,
and it does a whole lot, out of the box.

<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."

Oh, I can. I just don't much care, since you seem to think your
opinion weighs more than the experiences of several million
programmers over several decades.

A lot of code I've seen uses C-style I/O, or some third-party C++ I/O
library. My opinion is not unique.

All that may be true, but only a tiny fraction of programmers have
to work at those levels. And Java has comparable mysteries at the
same subterranean levels.

Yes, but Java does a better job of abstracting them. Perhaps I need to buy
and read the book quoted above. It looks as if it provides an insightful
treatment.

Okay, I got that you don't understand C++ iostreams, or even C
file I/O.

Not well, and therein lies a problem with a lot of experience C++
programmers. They simply assume the person already know a good deal about
C programming.

See istreambuf_iterator and stop whingeing.

I was asking about the stream buffer not the stream. I don't want formatted
I/O. Also, I was pointing out the divergince in interfaces betwee I/O and
the STL, not to mention std::string.

I think it does, at least well enough. YM(obviously)V.

I know there are more comprehensive C++ I/O libraries. I prefer to seek
standards because they mean my code and coding practices should be
portable.

One thing that seem like it would be useful is extending the idea used in
numeric limits to apply ot the I/O classes, and any other classe for which
one might want information, and in clude code to print the status and
description of the class being examined.

 

[P.J. Plauger]

You're playing semantics, and you know damn good and well what I meant.

Yes, I know what you mean and no, I'm not "playing semantics." I
meant exactly what I said.

It could do far better.

So can many things. If you think you know how to do something
better, fer Crissake go do it and prove it to the rest of us.
Meanwhile, we'll muddle along with the stuff that works. And
I bet you'd be more productive if you spent more time learning
the available tools and less time making a case that they're
designed badly.

Hmmm... I know what my experience was. It was relatively easy to pick up,
and it does a whole lot, out of the box.

So does printf, and iostreams, if you confine yourself to
the obious usages. You keep comparing different levels of
abstraction.

A lot of code I've seen uses C-style I/O, or some third-party C++ I/O
library. My opinion is not unique.

That doesn't make it necessarily right, or important, however.

Yes, but Java does a better job of abstracting them.

Once again, a matter of opinion. Java is no longer sufficiently
important to me to critique, however.

Perhaps I need to buy
and read the book quoted above. It looks as if it provides an insightful
treatment.

Not a bad idea. Langer and Kreft put a lot of work into their
book, as did Josuttis.

Not well, and therein lies a problem with a lot of experience C++
programmers. They simply assume the person already know a good deal about
C programming.

That's an endemic problem in our trade, not unique to C and/or C++
programmers. But I don't see what that has to do with your
willingness to learn something before you start criticizing it.

I was asking about the stream buffer not the stream.

And I told you the proper answer to your question, if you're
capable of hearing it.

I don't want formatted
I/O.

I wasn't offering it.

Also, I was pointing out the divergince in interfaces betwee I/O and
the STL, not to mention std::string.

And I was pointing out the convergence, if you'll only stop
being right and listen.

I know there are more comprehensive C++ I/O libraries. I prefer to seek
standards because they mean my code and coding practices should be
portable.

Standards can help in that area, to be sure. Doesn't seem to
bother Java programmers, however.

One thing that seem like it would be useful is extending the idea used in
numeric limits to apply ot the I/O classes, and any other classe for which
one might want information, and in clude code to print the status and
description of the class being examined.

I suppose, even though I don't see the utility of such a blend.
But isn't that akin to mixing iostreams and STL?

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

 

[Alf P. Steinbach]

* P.J. Plauger:

Nothing prevents you from
starting a program with its standard streams opened in binary
mode, however.

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)?