std::ios::binary?

[Steven T. Hatton]

Steven T. Hatton wrote:

I can see where trying to specify a generic file descriptor could be
problematic. However, I can't imagine it poses anything close to the
variability that locales pose. Perhaps it really is something best left
outside of the C++ Standard. My first inclination was to suggest the
Standard could provide some kind of extensible framework, and use POSIX as
a default implementation. But, then that imposes a requirement on the
implementation which may not be easy to meet.

Whoops! I got to thinking about that statement, and realized that, AFAIK,
you can't get a filename from a POSIX file descriptor.

 

[Steven T. Hatton]

Dietmar Kuehl wrote:

And knowing which iterators are available, as well as what flags to use to
modify the behavior of the stream. Also relevant is the distinction
between formatted and unformatted operations. It is well advised also to
understand that unformatted streams may still alter the underlying data,
and that formatted operations may alter the data in a so-called "binary"
stream. It is easy to put the stream into "stupid" format states where
the wrong combination of flags is set causing the numeric format to behave
as if the default were set. strm.clear(flag) unsets everything _but_ flag.
strm.setf(flags) doesn't mean `set flags' even though that's what it does.
Then there is 'basic_ios' verses 'ios_base'. std::string::clear() does
something completely different than std::stringstream::clear(). Reading a
stream completely and correctly puts it into a fail state.

Then there are the necessary complexities of the design to consider.

Add this to the: 'Damn! why did that do that?' list. std::hex is a
manipulator. ios::hex is a flag. std:stream will accept either one,
with different results. Please note that I have not said there is anything
fundamentally wrong with C++ I/O, there's just a bunch of that kind of
stuff.

 

[Steven T. Hatton]

But
the statement certainly shows a lack of appreciation for the many
real, and sometimes highly inventive, contributions made by others
to the library. That, to me, reflects arrogance, stupidity, or both.

"The C++ Standard Library is an impressive body of work representing a
carefully selected, and fairly orthogonal collection of essential building
blocks upon which programmers have built some of the most sophisticated and
useful mechanisms in human history."

 

[Steven T. Hatton]

"The C++ Standard Library is an impressive body of work representing a
carefully selected, and fairly orthogonal collection of essential building
blocks upon which programmers have built some of the most sophisticated
and useful mechanisms in human history."

Message-ID: <[email protected]>
Newsgroups: comp.std.c++
Subject: Re: Making the Standard more intelligible.
Date: Thu, 30 Jun 2005 01:38:23 GMT

 

[Steven T. Hatton]

Dietmar Kuehl wrote:

But I did not say that. What I was specifically thinking about was the
way
Java I/O interfaces fit together as "filters". That's the part I like. I
fully agree, the character level suff like reading in mixed character
based
and numeric based data plain sucks in Java when compared to C++. Now, in
comparison to C...

Ha! I just built the latest Boost cvs and did F2 $BOOST_HOME and it opened
an html page I'd never seen before. This link was on it:

http://home.comcast.net/~jturkanis/iostreams/libs/iostreams/doc/

"The Iostreams Library serves two main purposes:

* To allow the easy creation of standard C++ stream and stream buffer
classes for new data sources and sinks.
* To provide a convenient interface for defining i/o filters and
attaching them to standard streams and stream buffers.

The library focuses on freeing users from writing boiler plate code and
allowing them instead to create highly reusable components.

In addition to providing an abstract framework the library provides a number
of concrete filters, sources and sinks which serve as example applications
of the library but are also useful in their own right. These include
components for accessing memory-mapped files, for file access via operating
system file descriptors, for code conversion, for text filtering with
regular expressions, for line-ending conversion and for compression and
decompression in the zlib, gzip and bzip2 formats."