Almost everybody sees the benefits of standardizing the C++ language and the Standard C++ Library. The trick is to keep working during the process. We call this a period of transition, and the C++ community is engaged in it now.
Here is what the transition looks like: a standard nearing completion, but not yet fully stable. Although the standard itself is unlikely to be substantially revised, the fine tuning and ratification will continue into 1997.
And here is what the transition looks like: compilers evolving toward the standard at various rates. For a time, you will find new language features_such as namespaces, default template arguments, member function templates, nested class templates_supported on some compilers and not others. Some compilers may not even include a version of the Standard C++ Library; many will offer versions which conform to the standard only so far as they support the necessary language features. It will be some time before commercial compilers actually implement the exact C++ language, or include the Standard C++ Library as described in the standard.
Finally, here is what the transition looks like: you, the developer, and what you're going through now. You are the one evolving designs and implementations toward the emerging standard. Change will come at rates determined by your development environment, application domain, and corporate culture.
Our goal for Tools.h++ is to help you to maintain consistency in your development while moving, at your own pace, along the path of the latest C++ technology.
The primary challenge of this new version of Tools.h++ was to establish our relationship with the ANSI/ISO Standard C++ Library. Rogue Wave is committed not only to bringing our products into compliance with the standard, but to harnessing its full power. The object is to provide you with even more useful and efficient class libraries. The process of integrating our libraries with the C++ standard begins here with Tools.h++ Version 7.
For this version of Tools.h++, we have concentrated our integration efforts on the Standard C++ Library containers, often referred to as the STL or Standard Template Library. Each of the standard containers has been wrapped with a new or re-engineered Tools.h++ collection class template. You'll find a full explanation of templates in Section 11. Following are the major design goals for our integration of Tools.h++ and the Standard C++ Library, along with examples of how they are reflected in this version:
Design Goal: Leverage
To offer greater value by taking advantage of the Standard C++ Library to build upon a higher foundation than the base C++ language.
For example, Tools.h++ offers collections that use Standard C++ Library containers for their implementations. Building Tools.h++ upon the standard enables these collections to easily supply standard iterators, which in turn allows them to be used with the rich set of Standard C++ Library algorithms. At the same time, you retain the safe, easy-to-use, object-oriented interface that Tools.h++ collections have always provided.
Design Goals: Interoperability
To support one of the primary benefits of the C++ standard, which is to allow libraries, modules, classes, and algorithms from diverse providers to easily work together at a high level.
For example, we made sure you can safely and efficiently pass a Tools.h++ doubly-linked list where a Standard C++ Library list is expected.
Design Goal: Freedom
To maintain access to the Standard C++ Library.
For example, when using a Tools.h++ collection implemented with a Standard C++ Library container, you are always free to drop down to the level of the implementation that takes advantage of the non-object-oriented features of the Standard C++ Library.
Design Goal: Object-orientation
To enhance the Standard C++ Library with efficient, object-oriented interfaces.
All our new and re-engineered collection class templates exemplify this goal. In each case, we have put an efficient wrapper around a corresponding Standard C++ Library container to provide a familiar, though expanded, Tools.h++ collection interface.
Design Goals: Simplicity and Safety
To enhance the Standard C++ Library with a simpler interface, which reduces risk and makes client code easily maintainable.
The object-oriented interface helps achieve this goal. Unlike the Standard C++ Library, the Tools.h++ container methods know what data they control, freeing the user from the need to specify iterators and algorithms.
Design Goal: Compatibility
To protect our customers' investment in code written with previous versions of Tools.h++.
For example, we have re-engineered the Tools.h++ Version 6.1 collection class templates to base them on Standard C++ Library containers. In almost all cases, your existing source code that used classes in the previous version of the library will compile with the new library without modification.
Design Goal: Smooth Transition
To provide the means for developers to begin moving along the path toward standard C++ at their own pace and with minimal hassle.
For example, you can use Tools.h++ with or without the Standard C++ Library. If your development environment supports a version of the Standard C++ Library certified for use with Tools.h++, we offer 28 new or re-engineered class templates implemented using the Standard C++ Library container classes. If you don't have the Standard C++ Library, we offer you a subset interface to many of the same class templates, implemented using the technology of previous versions of Tools.h++. The appropriate implementation is selected automatically and transparently at compile time. By coding to the more restricted interface, you will be able to take full advantage of the Standard C++ Library as soon as it becomes available to you.
Future versions of Tools.h++ will make full use of the Standard C++ Library and other newly added features of the C++ language. This version includes several areas where we have elected to wait before incorporating the latest available technology. In some cases, we're waiting until the standard library or language feature is more widely available. In other cases, frankly, we're waiting until we gain more experience with the new features to see how we can best mold them into a unified and effective whole. We want to be careful not to commit ourselves and our customers to less than optimal patterns of usage. In the meantime, we'd like to draw your attention to the following areas:
Tools.h++ continues to use classes RWCString and RWWString. These classes, along with their substring classes and collaborating regular expression and tokenizer classes, have long been considered among the most useful and powerful classes in the library. This suite of functionality is not offered by the Standard C++ Library. You may use the C++ standard string and wstring in your applications, but you may occasionally incur the overhead of copying if you must convert between Tools.h++ and standard strings.
Tools.h++ continues to use class RWLocale. At the time of this release, the C++ standard locale class specification is still undergoing review by the ANSI/ISO standards committees.
Exception Hierarchy
Tools.h++ continues to use its own exception hierarchy, which is similar to the exception hierarchy in the draft C++ Standard. We don't expect to change over until the standard exception hierarchy is more widely available. You are free to use standard exceptions in your application, but you must be prepared also to catch Tools.h++ exceptions when making calls into the Tools.h++ library from within your try blocks.
Namespaces
Tools.h++ is not yet using or attempting to use namespaces specified by the current draft. For now, we continue to use the RW prefix to distinguish our classes within the global namespace. Of course, this does not preclude you from using namespaces in your own application, if your compiler allows it.