Programming with RWStringIDs
RWCollectable now has a new regular member function, and two new static member functions. In order to maintain link compatibility with objects compiled against previous versions of the Essential Tools Module, none of these functions is virtual. The functions are therefore slightly less efficient than they would be if we broke link-compatibility.
The new regular member function is:
RWStringID stringID() const;
The new static member functions are:
RWStringID stringID(RWClassID); // looks up RWStringID
RWClassID classID(RWStringID); // looks up classID
RWFactory also includes the following new functions:
void addFunction(RWuserCreator, RWClassID, RWStringID);
RWCollectable* create(RWStringID) const;
RWuserCreator getFunction(RWStringID) const;
void removeFunction(RWStringID);
RWStringID stringID(RWClassID) const;
RWClassID classID(RWStringID) const;
You can use
RWCollectables that ship with the Essential Tools Module and
RWCollectables that have been defined with fixed
RWClassIDs exactly as in previous versions of the Essential Tools Module. For instance, you could use this common programming idiom:
RWCollectable *ctp; // assign the pointer
if (ctp->isA() == SOME_CONST_CLASSID) // do a specific thing
However, when you use
RWCollectables that have user-provided
RWStringIDs, which implies any non-permanent
ClassIDs, you must anticipate that the
RWClassID may have different values during different runs of the executable. For these classes, there are two possible idioms to replace the one above:
RWCollectable *ctp;
// assign the pointer somehow
// use with existing RWCollectable for comparison:
// comparison will be faster than comparing RWStringIDs
if(ctp->isA() == someRWCollectablePtr->isA())
// you may code to that class interface
// ...
// idiom to hard code the identification. Slightly
// slower because string comparisons are slower than int
// comparisons; also stringID() uses a dictionary lookup.
if (ctp->stringID() == "Some ID String") {
// you may code to that class interface
}
