§27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text mode)
And that is basically _all_ it says about it. What the heck does the binary
flag mean?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
103  48456 
* Steven T. Hatton: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text mode)
And that is basically _all_ it says about it. What the heck does the binary
flag mean?
Basically it means that the i/o functions should not do any translation
to/from external representation of the data: they should behave as they
really should have behaved by default, but unfortunately do not.
For example, a Windows text file has each line terminated by carriage return
+ linefeed, as opposed to just linefeed in Unix, and in text mode '\n' is
translated accordingly for output, and these sequences are translated to
'\n' on input -- in practice '\r' is carriage return and '\n' is linefeed.
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.
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.
Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could be
used for something, but then they forget that i/o is there for a reason.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Steven T. Hatton wrote: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text mode)
And that is basically _all_ it says about it. What the heck does the binary
flag mean?
On some platforms "\n" translates to "\r\n" when written (and the
reverse when read) to a file while on others it does not. binary mode
will make no such translation.
Gianni Mariani wrote: Steven T. Hatton wrote: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text
mode)
And that is basically _all_ it says about it. What the heck does the
binary flag mean?
On some platforms "\n" translates to "\r\n" when written (and the
reverse when read) to a file while on others it does not. binary mode
will make no such translation.
Is that per the Standard, or "implementation imposed"? I know that what you
describe is what I typically think of when I think of binary I/O. For
example, in ancient times we used to have to explicitly tell ftp to use
binary mode transfer.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Alf P. Steinbach wrote: * Steven T. Hatton: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text
mode)
And that is basically _all_ it says about it. What the heck does the
binary flag mean?
Basically it means that the i/o functions should not do any translation
to/from external representation of the data: they should behave as they
really should have behaved by default, but unfortunately do not.
For example, a Windows text file has each line terminated by carriage
return + linefeed, as opposed to just linefeed in Unix, and in text mode
'\n' is translated accordingly for output, and these sequences are
translated to
'\n' on input -- in practice '\r' is carriage return and '\n' is
linefeed.
Yes. I am aware of DOS spiders. ^M is what it looks like in Emacs, and it
is never a nice thing to have in a tarball. dos2unix is a great tool.
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.
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.
I'm now wondering if I really understood. If I read "characters" from a
std::istream, it goes into an error state when it hits an EOF. That's why
stuff like this works (when it works)
std::vector<float_pair> positions
(istream_iterator<float_pair> (file),
(istream_iterator<float_pair> ()));
I don't believe binary files are terminated by a special character, but I
could be wrong (again).
Take this example:
####################################
Thu Jul 28 06:03:39:> 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);
if(!file) { cerr << "couldn't open the file:"<< argv[1] << endl; return
-1; }
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;
}
Thu Jul 28 06:10:21:> g++ -obinio main.cpp
Thu Jul 28 06:13:04:> ./binio binio
read 22075bytes of data
read 22470bytes of data
##########################
Notice the second output is larger than the first.
Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could be
used for something, but then they forget that i/o is there for a reason.
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.
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
Here's an interesting observation:
compiled with gcc 3.3.5
-rwxr-xr-x 1 hattons users 40830 2005-07-28 06:22 binio-3.3.5
compiled with gcc 4.0.1
-rwxr-xr-x 1 hattons users 22470 2005-07-28 06:23 binio-4.0.1
And 4.0.1 produces (much) faster code as well.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
* Steven T. Hatton: * Alf P. Steinbach:
[snip] For example, a Windows text file has each line terminated by carriage
return + linefeed, as opposed to just linefeed in Unix, and in text mode
'\n' is translated accordingly for output, and these sequences are
translated to
'\n' on input -- in practice '\r' is carriage return and '\n' is
linefeed.
Yes. I am aware of DOS spiders. ^M is what it looks like in Emacs,
That's because a carriage return is ASCII 13, Ctrl M.
It would be different using EBCDIC, I imagine.
;-)
[snip] 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.
I'm now wondering if I really understood. If I read "characters" from a
std::istream, it goes into an error state when it hits an EOF. That's why
stuff like this works (when it works)
std::vector<float_pair> positions
(istream_iterator<float_pair> (file),
(istream_iterator<float_pair> ()));
I don't believe binary files are terminated by a special character, but I
could be wrong (again).
Not in Unix, and not in Windows. However a binary file can contain any byte
values, and those that look like end-of-line markers will be translated in
text mode, and the first that looks like an end-of-file marker may be
translated. All depending on the implementation.
[snip] ifstream file (argv[1],ios::binary);
if(!file) { cerr << "couldn't open the file:"<< argv[1] << endl; return
-1; }
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;
[snip]
##########################
Notice the second output is larger than the first.
That's probably because the ostringstream does some text mode shenanigans;
although I haven't checked.
Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could be
used for something, but then they forget that i/o is there for a reason.
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.
? The _default_ is translation. That is, the default is the overhead &
performance hit (+ other much more evil effects) you're mentioning.
I do believe the lack of
real binary I/O in the Standard Library is an unexpected inconvenience.
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
There is no §21.2.1.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote: * Steven T. Hatton:
I don't believe binary files are terminated by a special character, but I
could be wrong (again).
Not in Unix, and not in Windows. However a binary file can contain any
byte values, and those that look like end-of-line markers will be
translated in text mode, and the first that looks like an end-of-file
marker may be
translated. All depending on the implementation.
And they call it a "standard"? :/
[snip] ifstream file (argv[1],ios::binary);
if(!file) { cerr << "couldn't open the file:"<< argv[1] << endl; return
-1; }
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;
[snip]
##########################
Notice the second output is larger than the first.
That's probably because the ostringstream does some text mode shenanigans;
although I haven't checked.
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. That, too, may be implementation defined for all I know. 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.
? The _default_ is translation. That is, the default is the overhead &
performance hit (+ other much more evil effects) you're mentioning.
So is it the case that ios::binary may still not produce real binary
streams? That is, the stream could still act in some ways like a text
stream, e.g., eof? I do believe the lack of
real binary I/O in the Standard Library is an unexpected inconvenience.
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
There is no §21.2.1.
TC++PL(SE).
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:BI********************@speakeasy.net... §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text
mode)
And that is basically _all_ it says about it. What the heck does the
binary
flag mean?
"Binary" and "text" are both terms of art from the C Standard, which
is included by reference in the C++ Standard. Binary I/O is byte
transparent, with the possible exception of padding NUL bytes.
Text I/O endeavors to translate between internal newline-delimited
text lines and however the system commonly represents text outside
the program.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net... * Steven T. Hatton: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text
mode)
And that is basically _all_ it says about it. What the heck does the
binary
flag mean?
Basically it means that the i/o functions should not do any translation
to/from external representation of the data: they should behave as they
really should have behaved by default, but unfortunately do not.
For example, a Windows text file has each line terminated by carriage
return
+ linefeed, as opposed to just linefeed in Unix, and in text mode '\n' is
translated accordingly for output, and these sequences are translated to
'\n' on input -- in practice '\r' is carriage return and '\n' is
linefeed.
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).
No, the usage originated in early systems that couldn't describe the
length of a file to the nearest byte. A CTL-Z delimited the logical
end of text, so your program didn't read trailing garbage.
So in text
mode in Windows, a Ctrl Z might be translated to end-of-file on input.
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.
Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could be
used for something, but then they forget that i/o is there for a reason.
Nonsense.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:EJ********************@speakeasy.net... Gianni Mariani wrote:
Steven T. Hatton wrote: §27.4.2.1.4 Type ios_base::openmode
Says this about the std::ios::binary openmode flag:
*binary*: perform input and output in binary mode (as opposed to text
mode)
And that is basically _all_ it says about it. What the heck does the
binary flag mean?
On some platforms "\n" translates to "\r\n" when written (and the
reverse when read) to a file while on others it does not. binary mode
will make no such translation.
Is that per the Standard, or "implementation imposed"?
The C and C++ Standards both require that text mode I/O do whatever
is necessary to convert between the universal internal form of text
streams and whatever the execution environment requires instead.
I know that what you
describe is what I typically think of when I think of binary I/O. For
example, in ancient times we used to have to explicitly tell ftp to use
binary mode transfer.
And you still do, sometimes, if your FTP utility can't make an
intelligent guess.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:G7********************@speakeasy.net... I'm now wondering if I really understood. If I read "characters" from a
std::istream, it goes into an error state when it hits an EOF. That's why
stuff like this works (when it works)
std::vector<float_pair> positions
(istream_iterator<float_pair> (file),
(istream_iterator<float_pair> ()));
I don't believe binary files are terminated by a special character, but I
could be wrong (again).
Correct. But the I/O subsystem on every OS has *some* way to tell
you when you run out of input characters.
... Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could
be
used for something, but then they forget that i/o is there for a reason.
I suspect there are "political" reasons things turned out the way they
did.
Nonsense. In the early 1970s, Unix pioneered the notion of a universal
format for text streams, by pushing any needed mappings out to the
device drivers. That text stream model became an integral part of C,
which first evolved under Unix. In the late 1970s and early 1980s,
Whitesmiths, Ltd. ported C to several dozen operating systems. We
elaborated the text/binary I/O model as a way of preserving both the
universal text stream format and the transparent text stream, as
needed. All that technology was captured in the C Standard in the
mid 1980s. It was then incorporated by reference in the C++ Standard
in the mid 1990s. It's there because it works.
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.
Might be, if there were such a lack.
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
Stroustrup is not nearly as familiar with the Standard C++ library
as he is with the language he invented.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:HM********************@speakeasy.net... Alf P. Steinbach wrote:
* Steven T. Hatton:
I don't believe binary files are terminated by a special character, but
I
could be wrong (again).
Not in Unix, and not in Windows. However a binary file can contain any
byte values, and those that look like end-of-line markers will be
translated in text mode, and the first that looks like an end-of-file
marker may be
translated. All depending on the implementation.
And they call it a "standard"? :/
Yes they do. The C Standard describes how to impose order over a
diverse range of operating systems. You can describe practically
every car made today as having a steering wheel, an accelerator,
and a brake -- if you want to emphasize what's standard about
them. Or you can discuss at great length the different kinds of
linkages and braking systems -- if you want to emphasize how
they differ. Depends on your "political" goal, I suppose.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
* 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? Of course, the religious C++'ers maintain that that shouldn't be possible
anyway because you can't do it on, say, a mobile phone, where C++ could be
used for something, but then they forget that i/o is there for a reason.
Nonsense.
See above. ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net... * 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::ofstream ofs(argv[2],
std::ios_base::out | std::ios_base::binary);
ofs << ifs.rdbuf();
}
return (0);
}
(I was wrong about needing read and write.)
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
* 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::ofstream ofs(argv[2],
std::ios_base::out | 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.
What you were wrong about :
The above doesn't copy standard input to standard output. ;-)
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
P.J. Plauger wrote: "Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net...
* 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::ofstream ofs(argv[2],
std::ios_base::out | 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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Alf P. Steinbach wrote:
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.
What you were wrong about:
The above doesn't copy standard input to standard output. ;-)
Cheers,
- Alf
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();
}
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: P.J. Plauger wrote:
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net...
* 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::ofstream ofs(argv[2],
std::ios_base::out | 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.
Actually I believe that should be more like:
copy(file_buf.eback(), file_buf.egptr(), back_inserter(data));
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
* Steven T. Hatton:
Dose this potentially modify the stream data?
Yes.
If so, where?
Well, I don't really care exactly where -- when you know the car has
square wheels it doesn't really matter exactly what prevents the motor from
starting and the door from opening, so I've never been interested in that.
/* 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();
}
With MSVC 7.1 under Windows XP Professional:
P:\> dir | find "exe"
28.07.2005 15:05 233*472 vc_project.exe
P:\> vc_project <vc_project.exe >x
P:\> dir | find "x"
28.07.2005 15:05 233*472 vc_project.exe
28.07.2005 15:09 4*484 x
P:\> _
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote: * Steven T. Hatton:
Dose this potentially modify the stream data?
Yes.
If so, where?
Well, I don't really care exactly where -- when you know the car has
square wheels it doesn't really matter exactly what prevents the motor
from starting and the door from opening, so I've never been interested in
that.
#include <iostream>
int main ()
{
// copy all standard input to standard output
std::cout << std::cin.rdbuf();
}
With MSVC 7.1 under Windows XP Professional:
P:\> dir | find "exe"
28.07.2005 15:05 233*472 vc_project.exe
P:\> vc_project <vc_project.exe >x
P:\> dir | find "x"
28.07.2005 15:05 233*472 vc_project.exe
28.07.2005 15:09 4*484 x
P:\> _
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
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();
}
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
* 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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote: 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 ;-) ).
--
Salu2
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net... * 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::ofstream ofs(argv[2],
std::ios_base::out | 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
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:PP********************@speakeasy.net... P.J. Plauger wrote:
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net...
* 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::ofstream ofs(argv[2],
std::ios_base::out | 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
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:UN********************@speakeasy.net... Alf P. Steinbach wrote:
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.
What you were wrong about:
The above doesn't copy standard input to standard output. ;-)
Cheers,
- Alf
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
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net... * 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
P.J. Plauger wrote: 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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
P.J. Plauger wrote: 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));
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:AL********************@speakeasy.net... P.J. Plauger wrote:
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.
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
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Me********************@speakeasy.net... P.J. Plauger wrote:
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));
You're simply wrong.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
In message <Me********************@speakeasy.net>, Steven T. Hatton
<ch********@germania.sup> writes P.J. Plauger wrote:
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.
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
basic_ifstream<char>, not basic_ifstream<unsigned char>, so the
iterators have the wrong type ;-)
copy(istream_iterator<unsigned char>(file)
, istream_iterator<unsigned char>()
, back_inserter(data));
Did you try it?
--
Richard Herring
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:AL********************@speakeasy.net...
P.J. Plauger wrote:
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...tml/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.
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.
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. 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.
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. 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.
Where's my_binary_file.begin() and my_binary_file.end()? 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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: 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.
--
Salu2
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:ff********************@speakeasy.net... P.J. Plauger wrote:
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:AL********************@speakeasy.net...
P.J. Plauger wrote: 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.
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.
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.
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.
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.
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. 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.
Where's my_binary_file.begin() and my_binary_file.end()?
See istreambuf_iterator and stop whingeing. 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.
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
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Me********************@speakeasy.net...
P.J. Plauger wrote:
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));
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
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: 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.
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.
--
Salu2
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:ff********************@speakeasy.net...
P.J. Plauger wrote:
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:AL********************@speakeasy.net...
P.J. Plauger wrote: 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.
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.
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.
It could do far better.
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.
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."
</quote>
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.
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.
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. 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()?
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. 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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Kb********************@speakeasy.net... 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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()?
See istreambuf_iterator and stop whingeing.
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.
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.
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
* 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)?
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
> 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
> 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/...3de627b7a574f3
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
>> Not in Unix, and not in Windows. However a binary file can contain any byte values, and those that look like end-of-line markers will be
translated in text mode, and the first that looks like an end-of-file
marker may be
translated. All depending on the implementation.
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?
istream_iterator<unsigned char> is using >> to read from the file and I
think it might discard any initial whitespace characters.
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
* 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/...3de627b7a574f3
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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net... * 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)?
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
Alf P. Steinbach wrote: 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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
* P.J. Plauger: "Alf P. Steinbach" <al***@start.no> wrote in message
news:42****************@news.individual.net...
* 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)?
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
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Steven T. Hatton wrote: 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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Steven T. Hatton wrote: 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:
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).
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.
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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Steven T. Hatton wrote: 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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence This thread has been closed and replies have been disabled. Please start a new discussion. |
