ISO-8601 Format Parsing
The definition of iso8601 has changed, and now enforces the newer ISO-8601:2000 format. This is stricter than the previous format, and may result in errors when parsing some non-conforming ISO-8601 strings that were accepted in previous releases. In order to continue to parse non-conforming ISO-8601 representations, you'll need to specify the iso8601_compat enumeration value instead. The rules for handling implied date and time components have changed. These changes are discussed in the documentation for the two available parsers.
Parsing Strings with RWDateTime::iso8601
Previously the current time of day / date was used when filling in values for truncated iso8601 strings. Now the epoch is used.
To restore the behavior of using the current time of day / date when filling in values for truncated ISO-8601 strings, you will need to specify the RWDateTime::iso8601_compat flag instead of RWDateTime::iso8601 when parsing the string. RWDateTime::iso8601_compat has other differences from RWDateTime::iso8601. See the SourcePro C++ API Reference Guide for more details.
API Change to RWTIsvSlist and RWTIsvDlist
The copy constructor and assignment operator for these classes has been made private. They were compiler defined and did not actually copy anything.
Existing applications that depend on these interfaces will fail to compile. Any code that called these functions relied on incorrect behavior, and should be reviewed to verify that a copy is really necessary. If you truly need to make copies of a linked list, consider using RWTValSlist or RWTValDlist.
RWios::fail() Behavior
Previously this method checked only for std::ios::failbit. It now checks for std::ios::badbit as well, as specified by the C++ Standard.
Since fail() indicates that either badbit or failbit is set, if your application needs to know specifically if failbit is set, it can check if that bit is set in the return of rdstate():
if (bis.rdstate() & std::ios::failbit) {
// std::ios::failbit is set.
}
|
RWTPtrHashMap and RWTPtrHashMultiMap Equality
These classes previously checked only the keys when determining equality. They now check both the keys and the values, as do the other Rogue Wave map-based containers.
Applications that depend on the previously documented behavior of only comparing the keys in the container will need to implement their own equality functions for these containers.
Signed Char Support in Virtual Streams
New methods explicitly supporting signed char data have been added to the virtual streams classes RWvistream and RWvostream. Previously signed char data was implicitly converted to an int for serialization.
For backward compatibility, default implementations are provided for these methods that attempt to maintain previous behavior. However it is recommended that if you have derived your own classes from RWvistream or RWvostream, you should provide explicit implementations of these functions.
Default Stream Version Changed to Support Optimization in Virtual Streams Data
Enhancements to the virtual streams classes have been made to reduce the amount of data stored on the stream. The default stream version has been changed to make these enhancements available by default. If you need to read data stored with an older stream version, you will need to make an explicit call to set the stream version.
Prior to this release, these stream versions existed:
Version 0: the initial version when virtual streams were introduced
Version 1: an enhancement to the initial version
In this release, the following versions have been added:
Version 2: avoids storing the size of an RWCString to a binary or endian stream twice, and fixes a data portability issue seen when writing to a portable stream
Version 3: avoids writing unnecessary data to the virtual stream when serializing size_t values with the putSizeT() method
If you try to read data that was streamed with a previous version of SourcePro, or to write data that will be consumed by a previous version, you may experience errors. Use the version() method on the steams classes to set the required version.
New Functor API
While the new class RWTFunctor supports implicit conversion to and from the deprecated types RWTFunctorR0 et al., there may still be some instances where existing code will fail to compile. Typically this will occur in situations where the code is depending on an implicit conversion from RWTFunctorR0 et al. to some other type. In those cases, you will need to either update your code to use RWTFunctor, or provide an explicit cast to RWTFunctorR0 et al.
Iterator Classes
The behavior of RWUAvailableEncodingListIterator, RWUAvailableLocaleListIterator, RWUEncodingAliasListIterator, and RWUEncodingNameStandardListIterator was over-specified in previous releases, indicating that incrementing an iterator that was already past-the-end of the collection or decrementing an iterator that was already at the beginning of the collection would leave the iterator unchanged. Incrementing an iterator that is already past-the-end or decrementing an iterator that is already at the beginning should be treated as undefined behavior, and you should take appropriate precautions in your code to prevent this from happening.
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.