The Streams package architecture includes the common framework, the extended framework, and the common filtered streams.
The common stream framework is the base architecture on which each stream family is built. It is divided into input streams and output streams. Both are composed of a handle class and two body classes, as shown in Figure 2 and Figure 3.
Classes RWHandleBase and RWBodyBase are part of the Smart Pointer package in the Threads Module.
The handle classes for the input streams are named RW{TYPE}InputStream, and the handle classes for the output streams are named RW{TYPE}OutputStream, where {TYPE} is one of the following:
Byte (binary streams)
Char (narrow character streams)
UChar (Unicode character streams)
WChar (wide character streams)
Data (data streams)
Your application manipulates the handle classes and the concrete stream classes only when they are created. After creation, the concrete stream classes are manipulated through their corresponding handle classes.
The abstract body classes for the input streams are named RW{TYPE}InputStreamImp and RWFiltered{TYPE}InputStreamImp, and the abstract body classes for the output streams are named RW{TYPE}OutputStreamImp and RWFiltered{TYPE}OutputStreamImp, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
Data
The abstract body class RW{TYPE}InputStreamImp is the base class for input streams that are terminal elements in a processing stream. Class RW{TYPE}OutputStreamImp is the base class for output streams. These concrete terminal stream elements can be used by themselves or as first processing elements. An example of these elements is a TCP/IP network stream.
The abstract body class RWFiltered{TYPE}InputStreamImp is the base class for input streams that are intermediate elements in a processing stream. Class RWFiltered{TYPE}OutputStreamImp is the base class for output streams that are intermediate elements in a processing stream. These concrete intermediate stream elements cannot be used by themselves or as first processing elements. They take a handle to the next processing element when constructed. An example of these elements is the synchronized streams that, for each operation invoked on them, lock an internal mutex, and then forward the operation onto the next processing element.
The extended framework adds memory streams to the binary, narrow character, Unicode character, and wide character stream families. These streams write data to memory. Only output streams are included because the performance problems occur only during output operations. A new handle class for each stream family is required in order to access the content of the memory written by the memory output stream.
The extended framework is built on top of the common framework and is composed of a handle class, an abstract body class, and a concrete class for each stream family, as shown in Figure 4.
The memory stream handle classes are named RW{TYPE}ArrayOutputStream, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
When using memory streams, your application manipulates both the new handle classes and the concrete stream classes when they are created. After creation, the concrete stream classes are manipulated through their corresponding handle classes.
The memory stream abstract body classes are called RW{TYPE}ArrayOutputStreamImp, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
The memory stream concrete classes are named RWChained{TYPE}ArrayOutputStreamImp, where {TYPE} is one of the data types listed above. They are created by calling one of their public static make() functions, which returns a handle to the created concrete memory stream body.
The common filtered streams are intermediate stream elements that are common to each stream family. They require a handle to a stream element of their family type at construction time. They forward a request to this handle after carrying out their own task.
The common filtered streams are built on top of the common framework and are divided into the input streams and the output streams, as shown in Figure 5 and Figure 6.
The three kinds common filtered streams are:
Buffered streams
Synchronized streams
Guarded streams
The output buffered streams write to their internal buffer until it becomes full. Then, the content of the buffer is written to the stream element that was registered in the buffered stream at construction time.
The input buffered streams read from their internal buffer until it becomes empty. Then, they try to read elements (up to the buffer size) using the stream element that was registered in the buffered stream at construction time.
The buffered streams are available in every stream family except for the data streams. The data streams in the Streams package do not have a terminal stream, but always forward to a stream element of one of the other family types. The data streams do not require their own buffered streams, because they are not terminal elements.
The buffered stream classes for the input streams are named RWBuffered{TYPE}InputStreamImp, and the buffered stream classes for the output streams are named RWBuffered{TYPE}OutputStreamImp, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
Your application manipulates the concrete stream classes only when they are created. After creation, the concrete stream classes are manipulated through their corresponding handle classes.
The synchronized streams synchronize individual streaming operations in a multi-threaded environment. The synchronized streams take a handle to the next streaming element when constructed. Each operation invoked on the synchronized stream locks an internal mutex and is forwarded onto the next processing stream element.
The synchronized stream classes for the input streams are named RWSynchronized{TYPE}InputStreamImp, and the synchronized stream classes for the output streams are named RWSynchronized{TYPE}OutputStreamImp, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
Data
Your application manipulates the concrete stream classes only when they are created. After creation, the concrete stream classes are manipulated through their corresponding handle classes.
The guarded streams synchronize a group of streaming operations in a multi-threaded environment. They require the first of the guarded stream elements to be a synchronized stream because they use its internal mutex to ensure that all operations invoked on the guarded stream are part of a single synchronized group of operations.
The guarded streams are usually temporary objects that are created using a manipulator in a group of insertion operations. For instance, if an object os is a handle to a chain of streaming elements whose first element is a synchronized stream, then the following code creates a temporary guarded stream that ensures that all the following insertions are synchronized.
os << rwGuard << data1 << data2 << data3; |
The rwGuard manipulator creates a temporary guarded stream that locks its next streaming element's (a synchronized stream) internal mutex. The insertions that follow are made onto the temporary guarded stream, which simply forwards them to the synchronized stream's next streaming element. After the last insertion is carried out, the temporary guarded stream object is destroyed, which releases its next streaming element's internal mutex.
The guarded streams can also be created by using their public static make() function, in which case they retain the lock on their next streaming element until they are destroyed. If the next streaming element used to construct a guarded stream is not a synchronized stream, then the guarded stream does not have any effect. It forwards only a request to its next streaming element.
The guarded stream classes for the input streams are named RWGuarded{TYPE}InputStreamImp, and the guarded stream classes for the output streams are named RWGuarded{TYPE}OutputStreamImp, where {TYPE} is one of the following:
Byte
Char
UChar
WChar
Data
Your application manipulates the concrete stream classes only when they are created. After creation, the concrete stream classes are manipulated through their corresponding handle classes.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.