BDE 4.14.0 Production release
|
Macros | |
#define | BSLX_TESTINSTREAM_EXCEPTION_TEST_BEGIN(testInStream) |
#define | BSLX_TESTINSTREAM_EXCEPTION_TEST_END |
Enable unexternalization of fundamental types with identification.
This component implements a byte-array-based input stream class, bslx::TestInStream
, that provides platform-independent input methods ("unexternalization") on values, and arrays of values, of fundamental types, and on bsl::string
. bslx::TestInStream
also verifies, for these types, that the type of data requested from the stream matches what was written to the stream. bslx::TestInStream
is meant for testing only.
The bslx::TestInStream
type reads from a user-supplied buffer directly, with no data copying or assumption of ownership. The user must therefore make sure that the lifetime and visibility of the buffer is sufficient to satisfy the needs of the input stream.
This component is intended to be used in conjunction with the bslx_testoutstream externalization component. Each input method of bslx::TestInStream
reads either a value or a homogeneous array of values of a fundamental type, in a format that was written by the corresponding bslx::TestOutStream
method. In general, the user of this component cannot rely on being able to read data that was written by any mechanism other than bslx::TestOutStream
.
The supported types and required content are listed in the bslx
package-level documentation under "Supported Types".
Note that input streams can be invalidated explicitly and queried for validity and emptiness. Reading from an initially invalid stream has no effect. Attempting to read beyond the end of a stream will automatically invalidate the stream. Whenever an inconsistent value is detected, the stream should be invalidated explicitly.
If exceptions are enabled at compile time, the test input stream can be configured to throw an exception after a specified number of input requests is exceeded. If the input limit is less than zero (default), then the stream never throws an exception. Note that a non-negative input limit is decremented after each input attempt, and throws only when the current input limit transitions from 0 to -1; no additional exceptions will be thrown until the input limit is again reset to a non-negative value.
The input limit is set using the setInputLimit
manipulator.
This component also provides a pair of macros:
BSLX_TESTINSTREAM_EXCEPTION_TEST_BEGIN(testInStream)
BSLX_TESTINSTREAM_EXCEPTION_TEST_END
These macros can be used for testing exception-safety of classes and their methods when BDEX streaming is involved. A reference to an object of type bslx::TestInStream
must be supplied as an argument to the *_BEGIN
macro. Note that if exception-handling is disabled (i.e., if -DBDE_BUILD_TARGET_EXC
was not supplied at compile time), then the macros simply print the following:
When exception-handling is enabled (i.e., if -DBDE_BUILD_TARGET_EXC
was supplied at compile time), the *_BEGIN
macro will set the input limit of the supplied instream to 0, try
the code being tested, catch
any TestInstreamException
s that are thrown, and keep increasing the input limit until the code being tested completes successfully.
This section illustrates intended use of this component.
Suppose we wish to implement a (deliberately simple) MyPerson
class as a value-semantic object that supports BDEX externalization and unexternalization. In addition to whatever data and methods that we choose to put into our design, we must supply three methods having specific names and signatures in order to comply with the BDEX protocol: a class method maxSupportedBdexVersion
, an accessor (i.e., a const
method) bdexStreamOut
, and a manipulator (i.e., a non-const
method) bdexStreamIn
. This example shows how to implement those three methods.
In this example we will not worry overly about "good design" of the MyPerson
component, and we will declare but not implement illustrative methods and free operators, except for the three required BDEX methods, which are implemented in full. In particular, we will not make explicit use of bslma
allocators; a more complete design would do so:
First, we implement MyPerson
:
Then, we can exercise the new MyPerson
value-semantic class by externalizing and reconstituting an object. First, create a MyPerson
janeSmith
and a bslx::TestOutStream
outStream
:
Next, create a MyPerson
janeCopy
initialized to the default value, and assert that janeCopy
is different from janeSmith
:
Then, create a bslx::TestInStream
inStream
initialized with the buffer from the bslx::TestOutStream
object outStream
and unexternalize this data into janeCopy
:
Finally, assert
the obtained values are as expected and display the results to bsl::stdout
:
#define BSLX_TESTINSTREAM_EXCEPTION_TEST_BEGIN | ( | testInStream | ) |
#define BSLX_TESTINSTREAM_EXCEPTION_TEST_END |