HP Integrity NonStop J-Series - Manual (Page 276)

Anywhere the self-documenting feature of RWStringID adds enough value to compensate for its slight
inefficiencies. ●
RWStringIDs are generated for all RWCollectable classes that are compiled under the current version of Tools.h++.
This additional code generation has only minor impact on programs that do not use the RWStringIDs. The
RWFactory will be larger, to hold lookups from RWClassID and RWStringID; and startup time will be very slightly
longer, to accommodate the addition of the extra data to the RWFactory.
Identification Collisions
While RWStringID can help alleviate identification collisions, the possibility of collisions between RWStringIDs of
different classes still exists. Collisions can occur:
When an automatically generated RWStringID conflicts with a user-chosen one; ●
When one or more classes are accidentally assigned the same RWStringID; ●
When two classes in different namespaces have the same name and thus the same automatically generated
RWStringID. This assumes your compiler supports namespaces. ●
In some cases, collisions like these will be unimportant. Automatically generated RWClassIDs are guaranteed to be
distinct from one another and from any legal user-provided RWClassID. The virtual isA() method, the stringID()
method, and constructor lookup based on the RWClassID will all continue to work correctly.
There will be some situations, however, where collisions will cause difficulty. Polymorphic persistence of classes
with user-chosen RWStringIDs that collide will not work correctly. In these cases, the data will not be recoverable,
even though it is stored correctly. Similarly, user code that depends on distinguishing between classes based only on
their RWStringIDs will fail.
As a developer, you can work to avoid such collisions. First of all, you should use an RWStringID which is unlikely
to collide with any other. For instance, you might choose RWStringIDs that mimic the inheritance hierarchy of your
class, or that imbed your name, your company's name, a creation time, or a file path such as found in revision control
systems. And of course, you should always test your program to insure that the class actually associated with your
RWStringID is the one you expected.