BDE 4.14.0 Production release
|
Facilitate uniform unexternalization of user and fundamental types.
This component provides a namespace, bslx::InStreamFunctions
, that facilitates uniform support for BDEX unexternalization across all BDEX-compliant user-defined types, including template types and containers, as well as those fundamental types (and bsl::string
and bsl::vector
) for which the BDEX protocol provides direct support.
The namespace bslx::InStreamFunctions
facilitates client unexternalization of objects in a uniform, type-independent manner. It contains the bdexStreamIn
function that unexternalizes objects of all BDEX-compliant types. This function unexternalizes the specified object
in the specified version
or the version
read from the input stream as required by the BDEX protocol. The bdexStreamIn
function is overloaded for fundamental types, enumeration types, bsl::string
, and bsl::vector
. Note that, excluding bsl::vector
, version information is never read from the stream while unexternalizing these types.
By default, objects of enumeration type are streamed in as 32-bit int
values. Users can override this behavior by providing overloads of the InStreamFunctions::bdexStreamIn
function in the enumeration's namespace for their enumeration types. The general form of this overload is:
For value-semantic types that support the BDEX protocol, the free function bdexStreamIn
calls the bdexStreamIn
member function for that type.
bslx_instreamfunctions is an integral part of the BDEX unexternalization contract. The BDEX contract is at least in part "collaborative", which is to say that each developer of a given kind of component (e.g., a stream or a value-semantic container) must comply with the relevant portions of the contract to ensure that the "system as a whole" works for everybody. bslx_instreamfunctions plays several related but different roles in helping various developers to produce BDEX-compliant components. In this section we briefly highlight how and why bslx_instreamfunctions is helpful (or required) for these different developers. By discussing different aspects of usage, we convey the general design goals of this component, and, to a certain extent, the overall BDEX contract. See the bslx
package-level documentation for a full specification of the BDEX contract.
The author of a non-template value-semantic type has full knowledge of the details of the "value" of that type, and may choose to use the appropriate input stream get
methods directly when implementing the required bdexStreamIn
method for that type. However, if one or more aspects of the value are of template parameter type, then the author cannot in general know how to stream the value using the get
methods. For example, if a type has as its value one int
data member:
then the implementation of the bdexStreamIn
method can contain:
However, if the data member is of (template parameter) VALUE_TYPE
:
then the implementation of the bdexStreamIn
method must rely on the bslx::InStreamFunctions
implementation to input the value:
This call will resolve to the correct sequence of get
calls no matter whether VALUE_TYPE
is a fundamental type, a BDEX-compliant enum
, or a proper BDEX-compliant class. In the latter two cases, the explicit specification of the version format (in this case, 1) guarantees the stable operation of this method whether or not VALUE_TYPE
is provided additional version formats.
This section illustrates intended use of this component.
In this example we illustrate the primary intended use of the parameterized methods of this component, as well as a few trivial invocations just to show the syntax clearly. To accomplish this, we exhibit three separate example "components": an enum
, a value-semantic point object, and an input stream. In all cases, the component designs are very simple, with much of the implied functionality omitted, in order to focus attention on the key aspects of the functionality of this component.
First, consider an enum
Color
that enumerates a set of colors:
Next, we consider a very special-purpose point that has as a data member its color. Such a point provides an excellent opportunity for factoring, but since we are interested in highlighting BDEX streaming of various types, we will present a simple and unfactored design here. In a real-world problem, the mypoint
component would be implemented differently.
Note that the MyPoint
class in this example represents its coordinates as short
integer values; this is done to make the BDEX stream input byte pattern somewhat easier for the reader of this example to recognize when the input buffer is printed.
Representative (inline) implementations of these methods are shown below:
Then, we will implement an extremely simple input stream that supports the BDEX documentation-only protocol. For simplicity, we will use an externally managed buffer, and will only show a few methods needed for this example.
The relevant (inline) implementations are as follows.
Finally, use the above enum
, point class, and input stream to illustrate bslx::InStreamFunctions
functionality. This test code does not attempt to do anything more useful than reading values from a stream whose buffer was written "by hand" and confirming that the expected values were read correctly from the known byte pattern in the buffer.