1999-11-22 14:44:25 -05:00
|
|
|
\section{wxStreams overview}\label{wxstreamoverview}
|
1999-03-12 13:42:15 -05:00
|
|
|
|
|
|
|
Classes: \helpref{wxStreamBase}{wxstreambase},
|
|
|
|
\helpref{wxStreamBuffer}{wxstreambuffer}, \helpref{wxInputStream}{wxinputstream},
|
|
|
|
\helpref{wxOutputStream}{wxoutputstream},
|
|
|
|
\helpref{wxFilterInputStream}{wxfilterinputstream},
|
|
|
|
\helpref{wxFilterOutputStream}{wxfilteroutputstream}
|
|
|
|
|
|
|
|
\wxheading{Purpose of wxStream}
|
|
|
|
|
1999-08-24 09:04:55 -04:00
|
|
|
We had troubles with standard C++ streams on several platforms:
|
|
|
|
they react quite well in most cases, but in the multi-threaded case, for example,
|
1999-08-21 09:54:32 -04:00
|
|
|
they have many problems. Some Borland Compilers refuse to work at all
|
|
|
|
with them and using iostreams on Linux makes writing programs, that are
|
|
|
|
binary compatible across different Linux distributions, impossible.
|
1999-03-12 13:42:15 -05:00
|
|
|
|
2004-05-04 04:27:20 -04:00
|
|
|
Therefore, wxStreams have been added to wxWidgets because an application should
|
1999-08-24 09:04:55 -04:00
|
|
|
compile and run on all supported platforms and we don't want users to depend on release
|
1999-03-12 13:42:15 -05:00
|
|
|
X.XX of libg++ or some other compiler to run the program.
|
|
|
|
|
|
|
|
wxStreams is divided in two main parts:
|
1999-08-24 09:04:55 -04:00
|
|
|
|
1999-03-12 13:42:15 -05:00
|
|
|
\begin{enumerate}\itemsep=0pt
|
|
|
|
\item the core: wxStreamBase, wxStreamBuffer, wxInputStream, wxOutputStream,
|
|
|
|
wxFilterIn/OutputStream
|
|
|
|
\item the "IO" classes: wxSocketIn/OutputStream, wxDataIn/OutputStream, wxFileIn/OutputStream, ...
|
|
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
wxStreamBase is the base definition of a stream. It defines, for example,
|
2000-07-15 15:51:35 -04:00
|
|
|
the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions
|
1999-03-12 13:42:15 -05:00
|
|
|
are really implemented by the "IO" classes.
|
|
|
|
wxInputStream and wxOutputStream inherit from it.
|
|
|
|
|
|
|
|
wxStreamBuffer is a cache manager for wxStreamBase (it manages a stream buffer
|
|
|
|
linked to a stream). One stream can have multiple stream buffers but one stream
|
|
|
|
have always one autoinitialized stream buffer.
|
|
|
|
|
|
|
|
wxInputStream is the base class for read-only streams. It implements Read,
|
|
|
|
SeekI (I for Input), and all read or IO generic related functions.
|
|
|
|
wxOutputStream does the same thing but it is for write-only streams.
|
|
|
|
|
2000-07-15 15:51:35 -04:00
|
|
|
wxFilterIn/OutputStream is the base class definition for stream filtering.
|
|
|
|
Stream filtering means a stream which does no syscall but filters data
|
1999-03-12 13:42:15 -05:00
|
|
|
which are passed to it and then pass them to another stream.
|
|
|
|
For example, wxZLibInputStream is an inline stream decompressor.
|
|
|
|
|
|
|
|
The "IO" classes implements the specific parts of the stream. This could be
|
|
|
|
nothing in the case of wxMemoryIn/OutputStream which bases itself on
|
|
|
|
wxStreamBuffer. This could also be a simple link to the a true syscall
|
|
|
|
(for example read(...), write(...)).
|
|
|
|
|
|
|
|
\wxheading{Generic usage: an example}
|
|
|
|
|
1999-08-24 09:04:55 -04:00
|
|
|
Usage is simple. We can take the example of wxFileInputStream and here is some sample
|
1999-03-12 13:42:15 -05:00
|
|
|
code:
|
|
|
|
|
|
|
|
\begin{verbatim}
|
|
|
|
...
|
|
|
|
// The constructor initializes the stream buffer and open the file descriptor
|
|
|
|
// associated to the name of the file.
|
1999-08-21 09:54:32 -04:00
|
|
|
wxFileInputStream in_stream("the_file_to_be_read");
|
1999-03-12 13:42:15 -05:00
|
|
|
|
1999-08-21 09:54:32 -04:00
|
|
|
// Ok, read some bytes ... nb_datas is expressed in bytes.
|
|
|
|
in_stream.Read(data, nb_datas);
|
1999-11-22 14:44:25 -05:00
|
|
|
if (in_stream.LastError() != wxSTREAM_NOERROR) {
|
1999-03-12 13:42:15 -05:00
|
|
|
// Oh oh, something bad happens.
|
|
|
|
// For a complete list, look into the documentation at wxStreamBase.
|
|
|
|
}
|
|
|
|
|
|
|
|
// You can also inline all like this.
|
1999-11-22 14:44:25 -05:00
|
|
|
if (in_stream.Read(data, nb_datas).LastError() != wxSTREAM_NOERROR) {
|
1999-03-12 13:42:15 -05:00
|
|
|
// Do something.
|
|
|
|
}
|
|
|
|
|
|
|
|
// You can also get the last number of bytes REALLY put into the buffer.
|
1999-08-21 09:54:32 -04:00
|
|
|
size_t really_read = in_stream.LastRead();
|
1999-03-12 13:42:15 -05:00
|
|
|
|
|
|
|
// Ok, moves to the beginning of the stream. SeekI returns the last position
|
|
|
|
// in the stream counted from the beginning.
|
1999-08-21 09:54:32 -04:00
|
|
|
off_t old_position = in_stream.SeekI(0, wxFromBeginning);
|
1999-03-12 13:42:15 -05:00
|
|
|
|
|
|
|
// What is my current position ?
|
1999-08-21 09:54:32 -04:00
|
|
|
off_t position = in_stream.TellI();
|
1999-03-12 13:42:15 -05:00
|
|
|
|
|
|
|
// wxFileInputStream will close the file descriptor on the destruction.
|
|
|
|
\end{verbatim}
|
|
|
|
|
1999-08-24 09:04:55 -04:00
|
|
|
\wxheading{Compatibility with C++ streams}
|
1999-03-12 13:42:15 -05:00
|
|
|
|
|
|
|
As I said previously, we could add a filter stream so it takes an istream
|
|
|
|
argument and builds a wxInputStream from it: I don't think it should
|
2004-05-04 04:27:20 -04:00
|
|
|
be difficult to implement it and it may be available in the fix of wxWidgets 2.0.
|
1999-08-05 18:05:15 -04:00
|
|
|
|