As we explained in the introduction to this manual, one of our primary goals for this version of Tools.h++ is to protect your investment in existing code based on previous versions of the library. As you can see from this chapter, we have significantly re-engineered the collection class templates in order to bring them up to date with the Standard C++ Library. The following classes were re-engineered:
You have seen that you can now use all of these classes either with or without the Standard C++ Library. Used without the Standard C++ Library, they have the same interfaces and implementations as in the previous version of Tools.h++, updated with some bug fixes. These minor enhancements should not cause any source incompatibilities with existing code.
You may need to make a few changes to existing source code when using the above classes with the Standard C++ Library. The adjustments required for specific classes are outlined below.
Extra template arguments are now required for:
|
RWTPtrHashDictionary |
RWTValHashDictionary |
|
RWTPtrHashSet |
RWTValHashSet |
|
RWTPtrHashTable |
RWTValHashTable |
|
RWTPtrSortedVector |
RWTValSortedVector |
Existing code using these templates will not provide the number of template arguments expected by this version of Tools.h++ when used with the Standard C++ Library. The solution to this problem is to use the macros discussed in Section 11.10.1. Using the macros described there will satisfy the compiler and preserve the semantics of your existing code.
The class hierarchy has changed for:
|
RWTPtrHashSet |
RWTValHashSet |
|
RWTPtrHashTable |
RWTValHashTable |
|
RWTPtrOrderedVector |
RWTValOrderedVector |
|
RWTPtrSortedVector |
RWTValSortedVector |
If you have existing code that makes use of any of the inheritance relationships among the collection class templates, that code will not compile with this version of Tools.h++ when used with the Standard C++ Library. There are no inheritance relationships among the standard library-based implementations of the collection class templates. For example, in the previous version of Tools.h++, RWTPtrHashSet inherited from RWTPtrHashTable, RWTValOrderedVector inherited from RWTValVector, and RWTValSortedVector inherited from RWTValOrderedVector. The pointer-based versions of these templates followed a similar pattern. These relationships do not hold in the new version of Tools.h++. If you have code based on this inheritance, you will need to modify it .
The most likely place where you will find this problem in your existing code is when building an RWTValHashTableIterator from an RWTValHashSet, or an RWTPtrHashTableIterator from an RWTPtrHashSet. Because the constructor for RWTValHashTableIterator is expecting a reference to an RWTValHashTable, passing in an RWTValHashSet instead depends on the inheritance relationship.
The solution to this particular problem is found in the new class RWTPtrHashSetIterator. Wherever you find code which constructs an RWTValHashTableIterator from an RWTValHashSet, use an RWTValHashSetIterator instead. Note that RWTValHashSetIterator is provided whether or not the Standard C++ Library is available, so you can modify your code now in anticipation of migrating your code to the standard library-based implementations.
Required less-than semantics for an element type may affect:
|
RWTPtrDlist |
RWTValDlist |
|
RWTPtrOrderedVector |
RWTValOrderedVector |
|
RWTPtrSlist |
RWTValSlist |
|
RWTPtrSortedVector |
RWTValSortedVector |
As mentioned above, some compilers will require that the expression (t1 < t2) be defined for two instances of your element type. This is due to the inclusion of convenient member functions, such as sort() and min_element(),combined with certain compilers that instantiate all member functions whether used or not. You might have existing code that instantiates one of these templates on a type T for which no operator<() is defined. If that is the case, you will have to define one.
The best thing would be to define it in a way you can really use, if you ever use those member functions which really do require it. The quick and dirty approach would be to globally define a dummy operator<() whose only purpose is to appease the compiler. Our experience is that code written "just to appease the compiler" constitutes a maintenance nightmare. Please avoid it if at all possible.