X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/4130b487dcbd6f7f8cbc3e724ddf752b3817559c..81c882b613b5d99ddb1e5ab69fcd7ebccc287025:/docs/latex/wx/tstream.tex diff --git a/docs/latex/wx/tstream.tex b/docs/latex/wx/tstream.tex index 5709db71d8..7b456062a2 100644 --- a/docs/latex/wx/tstream.tex +++ b/docs/latex/wx/tstream.tex @@ -1,4 +1,4 @@ -\section{Streams in wxWindows overview}\label{wxstreamoverview} +\section{wxStreams overview}\label{wxstreamoverview} Classes: \helpref{wxStreamBase}{wxstreambase}, \helpref{wxStreamBuffer}{wxstreambuffer}, \helpref{wxInputStream}{wxinputstream}, @@ -8,17 +8,18 @@ Classes: \helpref{wxStreamBase}{wxstreambase}, \wxheading{Purpose of wxStream} -We went into troubles with C++ std streams on several platforms: -they react quite well in most cases, but in multi-threaded case, for example, -they have many problems. Some Borland Compilers refuse to work at all -with them and using iostreams on Linux makes writing programs, that are +Standard C++ streams can cause problems on several platforms: +they work quite well in most cases, but in the multi-threaded case, for example, +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. -Therefore, wxStreams have been added to wxWindows because an application should -compile and run on all supported platforms and we don't want users depend on release -X.XX of libg++ or some other compiler to run the program. +Therefore, wxStreams have been added to wxWidgets so that applications can +reliably compile and run on all supported platforms without dependence on a +particular release of libg++. wxStreams is divided in two main parts: + \begin{enumerate}\itemsep=0pt \item the core: wxStreamBase, wxStreamBuffer, wxInputStream, wxOutputStream, wxFilterIn/OutputStream @@ -26,20 +27,20 @@ wxFilterIn/OutputStream \end{enumerate} wxStreamBase is the base definition of a stream. It defines, for example, -the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions are +the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions 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 +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. -wxFilterIn/OutputStream is base class definition for stream filtering. -I mean by stream filtering, a stream which does no syscall but filter datas +wxFilterIn/OutputStream is the base class definition for stream filtering. +Stream filtering means a stream which does no syscall but filters data which are passed to it and then pass them to another stream. For example, wxZLibInputStream is an inline stream decompressor. @@ -50,7 +51,7 @@ wxStreamBuffer. This could also be a simple link to the a true syscall \wxheading{Generic usage: an example} -About its usage, it's simple. We can take the example of wxFileInputStream and here is a sample +Usage is simple. We can take the example of wxFileInputStream and here is some sample code: \begin{verbatim} @@ -61,13 +62,13 @@ code: // Ok, read some bytes ... nb_datas is expressed in bytes. in_stream.Read(data, nb_datas); - if (in_stream.LastError() != wxStream_NOERROR) { + if (in_stream.LastError() != wxSTREAM_NOERROR) { // Oh oh, something bad happens. // For a complete list, look into the documentation at wxStreamBase. } // You can also inline all like this. - if (in_stream.Read(data, nb_datas).LastError() != wxStream_NOERROR) { + if (in_stream.Read(data, nb_datas).LastError() != wxSTREAM_NOERROR) { // Do something. } @@ -81,12 +82,6 @@ code: // What is my current position ? off_t position = in_stream.TellI(); - // wxFileInputStream will close the file descriptor on the destruction. + // wxFileInputStream will close the file descriptor on destruction. \end{verbatim} -\wxheading{Compatibility with c++ stream} - -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 -be difficult to implement it and it may be available in the fix of wxWindows 2.0. -