binary iostreams ?
Plinio Conti
I mean, if I want to write an int, a float, etc. AS IT IS I can't use
streams, because they write and read a human readable text format of
numbers.
Does anyone know how to solve the problem?
Any public library?
What do you think about this choice?
bye
Plinio
plinio....@SPAMtiscalinet.it
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Plinio Conti
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Tom Hilinski
and write(), which read/write bytes of data.
"Plinio Conti" <plinio....@SPAMMINGmclink.it> wrote in message
news:95f35i$84k$1...@news.mclink.it...
Carl Daniel
"Plinio Conti" <plinio....@SPAMMINGmclink.it> wrote in message
news:95f35i$84k$1...@news.mclink.it...
>
> I mean, if I want to write an int, a float, etc. AS IT IS I can't use
> streams, because they write and read a human readable text format of
> numbers.
>
> Does anyone know how to solve the problem?
> Any public library?
> What do you think about this choice?
>
I too have wanted a binary stream - like a Java DataOutputStream (or
input) - I think it's a major missing feature from the C++ I/O library.
I'll take C++ over Java any day of the week, but in the IO streams area, I
think the java.io package has a lot to offer over <iostream> and friends.
-cd
Edward Diener
function to write and read binary data as a stream of characters.
Plinio Conti wrote:
> Why std c++ library stream classes are only text-oriented?
>
> I mean, if I want to write an int, a float, etc. AS IT IS I can't use
> streams, because they write and read a human readable text format of
> numbers.
>
> Does anyone know how to solve the problem?
> Any public library?
> What do you think about this choice?
---
James Kuyper
>
> "Plinio Conti" <plinio....@SPAMMINGmclink.it> wrote in message
> news:95f35i$84k$1...@news.mclink.it...
> > Why std c++ library stream classes are only text-oriented?
> >
> > I mean, if I want to write an int, a float, etc. AS IT IS I can't use
> > streams, because they write and read a human readable text format of
> > numbers.
> >
> > Does anyone know how to solve the problem?
> > Any public library?
> > What do you think about this choice?
> >
>
> I too have wanted a binary stream - like a Java DataOutputStream (or
> input) - I think it's a major missing feature from the C++ I/O library.
> I'll take C++ over Java any day of the week, but in the IO streams area, I
> think the java.io package has a lot to offer over <iostream> and friends.
What binary functionality do you need that read() and write() don't
provide?
Dietmar Kuehl
Plinio Conti (plinio....@SPAMMINGmclink.it) wrote:
: Why std c++ library stream classes are only text-oriented?
There is only a text oriented front end to stream buffers because text
input and output does not vary between platforms. This is very
different for binary output. For example, binary output has to consider
- word sizes: Is an 'int' two, four, or eight bytes long? The same
questions arise for all other built-in types.
- what is the bit pattern of a value? I think that at least implicitly
in the standard a binary representation for integer types is required.
I don't think that it is required to use two's complement. In any
case, the floating point representations do differ, eg. in their
number of bytes used.
- what "endianess" is to be used?
Basically it is possible to decide a format for each of those. This,
however, implies inefficient implementations on platforms where the
format does not match the internal representation.
What many people asking for binary I/O forget is that binary I/O also
requires some form of formatting! Assuming that just writing data and
then reading it in will work is asking for problems, eg. when the
compiler version changes and they decided to use a 32 bit integer
rather than a 16 bit integer: It is not even necessary to switch
platforms to run into problems!
: I mean, if I want to write an int, a float, etc. AS IT IS I can't use
: streams, because they write and read a human readable text format of
: numbers.
Which is for most I/O a reasonable approach. If it is not for you, you
might want to consider a data base: File I/O is not really useful as a
persistance mechanism. It is fine eg. for user interaction (text I/O),
logging (text I/O), cross platfrom program interaction (formatted I/O),
and data exchange (formatted I/O). In all these cases, the I/O is
formatted, although possible using a binary format. For persistance,
data bases are used. Depending on your needs, a relational or an object
oriented one may be better suited.
That said, it is worth to mention that it is easy to create a hierarchy
similar to IOStreams built on top of stream buffers but doing binary
formatting. A somewhat aged example is found at
<ftp://ftp.fmi.uni-konstanz.de/pub/algo/personal/kuehl/binio.tar.gz>.
This uses XDR formatting of the binary data (well, if I remmeber
correctly, it is easy to plug in a different binary formatting).
: Does anyone know how to solve the problem?
Use a data base, text formatting, or binary formatting. With the
details you have given it is impossible to tell which of those is the
right approach because you haven't told *why* you want a binary format
and *what* you want to do. That basically means that you came up with
solution and you want us to confirm that it is the right one without
telling us what problem is solved! Until I have seen the problem I
doubt that binary I/O is the right approach...
... and, BTW, using 'std::istream::read()' and 'std::ostream::write()'
is almost certainly the *wrong* approach! These functions are an
historical mistake which should have been corrected in the standard:
It is my understanding that these methods were present in the IOStream
version predating the rework from Jerry Schwartz and were left in to
be compatible with the earlier stuff although they were not necessary:
You could get binary I/O from the stream buffer level. The original
IOStream library (maybe you remember using <stream.h>) did not have
stream buffers and thus basic support for binary I/O was also present
on the streams level.
: What do you think about this choice?
When I wrote the above paragraph about confirming your choice, I haven't
read this question! As I said above: You told us what solution you have
choosen without stating what problem is solved. We cannot determine
whether your choice is the right one. Actually, I'm pretty sure it is
the wrong one but without seen the details I can't be certain.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
James Kanze
|> What binary functionality do you need that read() and write() don't
|> provide?
Perhaps just the simple fact that they work? read() and write() are,
for all practical purposes, useless. Java defines persistence at the
language level; C++ doesn't.
Of course, writing an object in Java using the DataOutputStream only
helps if you also are reading it in Java, using the DataInputStream.
It's no go for sending bits over the net to an arbitrary program.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
|> You can use ostream's "write" member function and istream's "read"
|> member function to write and read binary data as a stream of
|> characters.
Not for anything useful.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
---
James Kuyper
>
> James Kuyper <kuy...@wizard.net> writes:
>
> |> What binary functionality do you need that read() and write() don't
> |> provide?
>
I'm having a problem parsing that as an answer to my question. If you're
objecting that they don't work, that describes a defective
implementation, not a lack in the standard. The only alternative I can
see is that you're objecting that they do work, but I can't make any
sense out of that alternative.
> ... read() and write() are,
> for all practical purposes, useless. Java defines persistence at the
> language level; C++ doesn't.
Your definition of "practical purposes" is too narrow. The topic was
binary I/O, not persistence. There's a connection, but they're not the
same thing. Persistence is a higher level functionality, binary I/O is
merely a tool, one that has many other possible uses, and whose
characteristics make it a less than perfect tool for implementing
persistence.
James Kanze
|> Plinio Conti (plinio....@SPAMMINGmclink.it) wrote:
|> > Why std c++ library stream classes are only text-oriented?
|> There is only a text oriented front end to stream buffers because
|> text input and output does not vary between platforms. This is very
|> different for binary output. For example, binary output has to
|> consider
|> - word sizes: Is an 'int' two, four, or eight bytes long? The same
|> questions arise for all other built-in types.
It's not even necessarily a multiple of eight bit bytes; I used to know
of a machine with 9 bit bytes and 36 bit words.
|> - what is the bit pattern of a value? I think that at least
|> implicitly in the standard a binary representation for integer
|> types is required. I don't think that it is required to use two's
|> complement. In any case, the floating point representations do
|> differ, eg. in their number of bytes used.
And more importantly, how many bits in the exponant, or even, what base
is used for the representation. (IBM mainframes are base 16, not base
2.)
Even for int's, Dietmar is correct concerning signed representation;
two's complement is the most frequent, but one's complement and signed
magnitude have also been used. In addition, except for the character
types, the representations may contain unused bits.
For the rest, I'm fully in agreement with Dietmar, especially:
|> What many people asking for binary I/O forget is that binary I/O
|> also requires some form of formatting!
This is too important not to repeat. There is almost NO use for
unformatted IO -- it's basically only valid for the same run of the same
program, and then only for the standard arithmetic types.
[...]
|> ... and, BTW, using 'std::istream::read()' and
|> 'std::ostream::write()' is almost certainly the *wrong* approach!
I'd say that it's a lot more than a BTW. Another point we can't stress
too much.
|> These functions are an historical mistake which should have been
|> corrected in the standard: It is my understanding that these methods
|> were present in the IOStream version predating the rework from Jerry
|> Schwartz and were left in to be compatible with the earlier stuff
|> although they were not necessary: You could get binary I/O from the
|> stream buffer level. The original IOStream library (maybe you
|> remember using <stream.h>) did not have stream buffers and thus
|> basic support for binary I/O was also present on the streams level.
I didn't know this, but on thinking about it, it sounds likely.
|> : What do you think about this choice?
|> When I wrote the above paragraph about confirming your choice, I
|> haven't read this question! As I said above: You told us what
|> solution you have choosen without stating what problem is solved. We
|> cannot determine whether your choice is the right one. Actually, I'm
|> pretty sure it is the wrong one but without seen the details I can't
|> be certain.
I think he was asking about the choice of the standard to not support
binary iostreams. To which the obvious answer is: what is the
alternative? I think we'd all be happy to have binary streams, *IF* he
could point us to a universal binary format which is valid everywhere.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
---
Dietmar Kuehl
James Kuyper (kuy...@wizard.net) wrote:
: James Kanze wrote:
: >
: > James Kuyper <kuy...@wizard.net> writes:
: >
: > |> What binary functionality do you need that read() and write() don't
: > |> provide?
: >
: > Perhaps just the simple fact that they work? ...
I guess James Kanze meant s/work/don't work/.
: I'm having a problem parsing that as an answer to my question. If you're
: objecting that they don't work, that describes a defective
: implementation, not a lack in the standard.
No, he is not talking about a defective implementation. He is speaking
about the fact that 'read()' and 'write()' do unformatted binary I/O
which is, simply put, useless for real uses. The reason why it is
useless is not that obvious though. Of course, you will immediately
realize that writing pointers or non-POD objects to a file cannot
work. That's, however, only part of the story. Things are actually
worse: If you write something into a file you normally want some form
of persistance, ie. you want to be able to read the file later again.
Nothing in the standard guarantees that this is possible. Obviously,
when recompiling the program using other compiler flags or a newer
version, object layout may be different. For example, 'int' may be
16 bit for one version but 32 bit for another version.
Although there are probably exceptions, for typical uses you cannot
rely on using 'read()' and 'write()' to do the right thing for you for
most real uses. That pretty much comes down to my interpretation of
"don't work", too.
What is necessary is using formatted binary I/O: You have to arrange
for the use of the right number of bytes you write, on the right
endianess, etc. However, formatted binary I/O would not use 'read()' or
'write()' of the classes intended for formatted text I/O but rather the
stream buffer functions.
: Your definition of "practical purposes" is too narrow. The topic was
: binary I/O, not persistence.
Unformatted binary I/O is exclusively useful for some form of temporary
persistence.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
---
Ruslan Shevchenko
>
> Which is for most I/O a reasonable approach. If it is not for you, you
> might want to consider a data base: File I/O is not really useful as a
> persistance mechanism. It is fine eg. for user interaction (text I/O),
> logging (text I/O), cross platfrom program interaction (formatted
I/O),
> and data exchange (formatted I/O). In all these cases, the I/O is
> formatted, although possible using a binary format. For persistance,
> data bases are used. Depending on your needs, a relational or an
object
> oriented one may be better suited.
>
I. e. this means, that writing OO database on standart C++
must imply rewriting IOStream hierarchy ?
Looks, like language limitation, not feature :(
Sent via Deja.com
http://www.deja.com/
Frank
James Kanze <ka...@gabi-soft.de> wrote:
[long snip]
>
> I think he was asking about the choice of the standard to not support
> binary iostreams. To which the obvious answer is: what is the
> alternative? I think we'd all be happy to have binary streams,
Yes, yes, yes
> *IF* he could point us to a universal binary format which is valid
everywhere.
why 'universal binary format'? we just want an universal binary i/o
INTERFACE. I'm wondering why the standard cannt take the similar way
like using locale for text i/o
Regards
Frank
>
> --
> James Kanze mailto:ka...@gabi-soft.de
> Conseils en informatique orientée objet/
> Beratung in objektorientierter Datenverarbeitung
> Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting
with ]
> [ your news-reader. If that fails, use mailto:std-
c...@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. ---
]
> [ FAQ:
http://www.research.att.com/~austern/csc/faq.html ]
> [ Note that the FAQ URL has changed! Please update your
bookmarks. ]
>
>
--
Frank
Brainbench mvp for c++
http://www.brainbench.com
Sent via Deja.com
http://www.deja.com/
---
Marko Pietarinen
I had a problem reading binary data from standard input (cin) and write
binary data to standard output (cout). The problem with reading was that when
the first 0 (eof) was encountered the reading was stopped and the rest of
data was missed (even if I used the the binary read method cin.read(buffer,
10000) ).
The trick here is to put stdin and stdout in binary mode. But I didn't found
a way to put any stream in binary mode.This solution works with VC6.0 and
there is similar in BorlandC++, other systems I don't know.
Warning: If you want to use e.g. stringstreams with binary data, use
std::strings to set/get the string to/from stringstreams instead of normal
c-strings, because the 0 stops the c-string also.
#include <stdio.h>
#include <fcntl.h>
#include <io.h>
using namespace std;
int main( void )
{
int result;
/* Set "stdin" to have binary mode: */
result = _setmode( _fileno( stdin ), _O_BINARY );
if( result == -1 )
cerr << "Cannot set 'stdin' into binary mode";
char buffer[10000] = "";
cin.read(buffer, 10000);
/* Set "stdout" to have binary mode: */
result = _setmode( _fileno( stdout ), _O_BINARY );
if( result == -1 )
cerr << "Cannot set 'stdout' into binary mode";
cout.write(buffer, 10000);
return result;
Michiel Salters
> I think we'd all be happy to have binary streams, *IF* he
> could point us to a universal binary format which is valid everywhere.
ASN.1 + BER ? (Abstract Syntax Notation, Basic Encoding Rules)
It is an ISO standard, too, so it is globally available. But I'm not sure
you meant "globally" when you wrote "everywhere".
--
Michiel Salters
Michiel...@cmg.nl
sal...@lucent.com
James...@dresdner-bank.com
James Kuyper <kuy...@wizard.net> wrote:
> > Unformatted binary I/O is exclusively useful for some form of
> > temporary persistence.
> It's useful whenever your need for persistence does not coincide for
> a need for portability. It's also useful for communicating with
> devices, and I can't see any way to classify such a use as
> "persistence", (nor is such a use portable, of course, but not all
> code needs to be portable).
Certainly, but why are you trying to find a portable solution for a
problem that by definition is not portable? (The times I've output to
a device, I've used library functions like output or outword. Not
portable, of course, but the code wasn't portable anyway.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com
http://www.deja.com/
---
James...@dresdner-bank.com
Michiel Salters <sal...@lucent.com> wrote:
> James Kanze wrote:
> > I think we'd all be happy to have binary streams, *IF* he could
> > point us to a universal binary format which is valid everywhere.
> ASN.1 + BER ? (Abstract Syntax Notation, Basic Encoding Rules)
> It is an ISO standard, too, so it is globally available. But I'm not
> sure you meant "globally" when you wrote "everywhere".
I could live with that. Very well, in fact; in my telecoms work, it
IS the binary standard that we use. Somehow, however, I can't quite
see it flying in the C++ committee. Some people want performance, and
BER is not the answer to that problem.
And while I did mean everywhere with global, perhaps I should have
said something like "acceptable to everyone".
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com
http://www.deja.com/
---
Michiel Salters
> In article <3A7FAA66...@lucent.com>,
> Michiel Salters <sal...@lucent.com> wrote:
> > James Kanze wrote:
> > > I think we'd all be happy to have binary streams, *IF* he could
> > > point us to a universal binary format which is valid everywhere.
> > ASN.1 + BER ? (Abstract Syntax Notation, Basic Encoding Rules)
> > It is an ISO standard, too, so it is globally available. But I'm not
> > sure you meant "globally" when you wrote "everywhere".
> I could live with that. Very well, in fact; in my telecoms work, it
> IS the binary standard that we use. Somehow, however, I can't quite
> see it flying in the C++ committee. Some people want performance, and
> BER is not the answer to that problem.
> And while I did mean everywhere with global, perhaps I should have
> said something like "acceptable to everyone".
> --
> James Kanze mailto:ka...@gabi-soft.de
I'm aware of the efficiency issues. But that is not important, I think,
when it comes to establishing an interface. Such an "ASN.1 binary stream"
could be used in (template) functions which are also usable by other
"binary streams" which are less portable, but offer more performance/
space saving.
But given the number of pitfalls around this subject, we'd better start
working on it now if we want it finished by 2008 :)
--
Michiel Salters
Michiel...@cmg.nl
sal...@lucent.com
---