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

Implementation Details of RWStringID
The next few sections cover implementation details of RWStringID. If you are curious about how we manage to
provide virtual functionality without adding virtual methods, or if you are interested in issues of design, efficiency,
and other specifics, these sections are for you.
Automatic RWClassIDs
Automatic RWClassIDs are created in a systematic way from unused RWClassIDs in the range 0x9200 to 0xDAFF.
There are 18,687 possible such RWClassIDs, so only extraordinary programs can possibly run out. However, we are
used to dealing with extraordinary customers, so we feel we must warn you: you will not be able to build and use
more than 18,687 different classes with automatically generated RWClassIDs in any one program
[31] .
Note that this implies nothing about the total number of objects of each class that you may have. That number is
limited only by the requirements of your operating system and compiler. Of course, you also have access to the full
set of RWClassIDs below 0x8000_that is, 32767 more possible
RWCollectable s - but they will not be automatically
generated. You must specify them manually.
Implementing Virtuals Via Statics
Since the virtual method isA() returns a "run-time unique" RWClassID, we can use this one virtual method to provide
an index into a lookup table where various data or function pointers are stored. (This may remind you of C++ built-in
vtables!) Since
RWCollectable s already depend on the existence of a single RWFactory , we chose to use that
RWFactory instance to hold the lookup information.
The static method:
RWStringID RWCollectable::stringID(RWClassID id);
will attempt to look up id in the RWFactory instance. If it succeeds in finding an associated RWStringID, it will
return it. Otherwise, it will return RWStringID("NoID").
The static method:
RWClassID RWCollectable::classID(RWStringID sid)
works in an analogous manner, looking in the RWFactory instance to see if there is an RWClassID associated with
sid. If the method finds one, it returns it; otherwise, it returns RWClassID __RWUNKNOWN.
Polymorphic Persistence
Polymorphic persistence of RWCollectable s is not affected by the addition of the new class RWStringID. Existing
files can still be read using newly compiled and linked executables, as long as the old RWClassIDs are unchanged.
New classes that have RWStringIDs may be freely intermixed with old classes. The storage size of collectables that
do not have permanent RWClassIDs will reflect their larger space requirements, but the store size of other
RWCollectables will be unaffected.
Note that collections containing RWCollectable s with the same RWStringID have that RWStringID stored into a
stream or file only once, just as multiple references to the same RWCollectable are only stored the first time they are
seen.
Efficiency
Since RWClassID is more efficient in both time and space than RWStringID, you may wish to continue using it
wherever possible. RWStringIDs are useful:
For organizations that need to generate unique identifiers for many programming groups; ●
For third party libraries that need to avoid clashes with other libraries or users; ●