Click on the banner to return to the user guide home page.

©Copyright 1996, Rogue Wave Software, Inc.

Endnotes

[1]

An alternative design strategy would be to pass objects that are to be inserted into a collection by reference, as in The NIH Classes. We rejected this approach for two reasons: it looks so similar to pass-by-value that the programmer could forget about the retained reference; also, it becomes too easy to store a reference to a stack-based variable.

[2]

Details about methods readFile(); readLine(); readString(istream&); readToDelim(); and readToken() may be found in the RWCString section of the Class Reference.

[3]

However, system functions to transfer multibyte strings may make such assumptions. RWCString simply calls such functions to provide such transformations.

[4]

Because the default constructor for RWDate fills in today's date, constructing a large array of RWDate may be slow. If this is an issue, declare your arrays with a class derived from RWDate that provides a faster constructor, or use RWTValOrderedVector<RWDate>.

[5]

Your system's locale files determine the format used.

[6]

With many PC compilers, even ostream::write() and istream::read() perform a text conversion unless the file is opened with the ios::binary flag.

[7]

RWNIL is a macro whose actual value is system dependent. Typically, it is -1L.

[8]

Because of multiple inheritance, it may be necessary to know not only an object's type, but also its location within an inheritance tree in order to disambiguate which object you mean.

[9]

The Rogue Wave collection classes allow a generalized test of equality; it is up to you to define what it means for two objects to "be equal". A bit-by-bit comparison of the two objects is not done. You could define "equality" to mean that a panda is the same as a deer because, in your context, they are both mammals.

[10]

This is actually patterned after Stroustrup (1986, Section 7.3.2).

[11]

The draft ANSI standard describes container iterators in great detail. Briefly, such iterators are valid in the range "first-element" to "one-past-last-element", which are returned respectively by the methods begin() and end(). The "end" iterator, however, does not reference an item in the container, but acts as a sentinel.

[12]

It's OK to change a collection via the iterator itself.

[13]

See Stroustrup, The C++ Programming Language, Second Edition, Addison-Wesley, 1991, for a description of intrusive lists.

[14]

For a discussion of genericity versus inheritance, see Meyer (1988).

[15]

Adapted from Knuth (1973).

[16]

Unfortunately, the requirement for total ordering is a logical, not a semantic one, so the compiler cannot help by rejecting poorly chosen comparitors. In general, such code will compile, but probably have unexpected behavior.

[17]

Actually, the generic macros are easy to use, but difficult to write. They are also difficult to debug because they are preprocessor macros, and most debuggers cannot enter macro code.

[18]

The functional equivalent to apply() in the Smalltalk world is do. It takes just one argument: a piece of code to be evaluated for each item in the collection. This keeps the method and the block to be evaluated together in one place, resulting in cleaner code. As usual, the C++ approach is messier.

[19]

C++ template mechanisms prevent us from being able to do this. However, this restriction is probably a good thing_pointers saved at one location are likely to be troublesome indeed when injected into another.

[20]

You may find for template classes that with some compilers the source file must have the same base name as the header file where RWDECLARE_PERSISTABLE was used.

[21]

Actually, the Smalltalk collection classes are so similar that they all share the same version of restoreGuts(), inherited from RWCollection.

[22]

Strictly, it only needs to be different from every other identifier in any given executable.

[23]

The RWDEFINITION_MACROs do more than merely implement the two mentioned methods. Before you choose not to use one of the provided macros, review them in detail to be sure you understand all that they do.

[24]

See Chapter 18 (Implementation Details of RWStringIDs) for a discussion of RWStringID and how to mimic a virtual function. We wrote the code this way to maintain link compatibility with object code compiled from the previous version of Tools.h++.

[25]

This is a glaring deficiency in C++ that the user must constantly be aware of, especially if the user plans to have heterogeneous collections. See the section in Persistence called Don't Use Sorted RWCollections to Store Heterogeneous Collections for a description of the problem.

[26]

For a description of the persistence mechanism, see the section called Persistence.

[27]

Despite the existing standard for locale names, many vendors provide variant naming schemes. Check your vendor's documentation for details.

[28]

The first argument of the function asString()is a character, which may be any of the format options supported by the Standard C Library function strftime().

[29]

You can restore a stream to its unimbued condition with the static member function RWLocale::unimbue(ios&); note that this is not the same as imbuing it with the current global locale.

[30]

Of course, if you are working on a 64-bit system, there is no practical upper limit to the dates you can use.

[31]

16-bit DLLS will also accumulate automatic RWClassIDs while they are loaded in memory.

[32]

RWBTreeOnDisk has complexity similar to RWBTreeDictionary, but the time overhead is much greater since "following linked nodes" becomes "disk seek;" and the size overhead has a much greater impact on disk storage than on core memory.

[33]

RWSet and RWIdentitySet as well as collections with "Hash" in their names.