I spent a bit more time on WynterStorm today, this time cleaning up some older code.
In my last incarnation of WynterStorm, I had been using a TypeInfo class for RTTI in various places. Using Trefall's component classes as well as an event management system that I pulled from here on gamedev, I had taken in a second TypeInfo class that used standard C++ RTTI. Because I had introduced this class into my code, I had to move the old class out to prevent any conflictions. Today I resolved this issue by adding functionality into my original TypeInfo class and further modifying my engine to make use of my TypeInfo implementation rather than the one that relied on C++'s RTTI. Currently, integration with the TypeInfo class is fairly easy, and requires a few things.

First, a simple class would look like so:
[source lang="cpp"]class KeyPress : public Crystal::Event
{
TYPEINFO_DECLARE();
public:
KeyPress(int key) : keysym(key){};
int getKey() const {return this->keysym;}

private:
int keysym;
};[/source]

Here, TYPEINFO_DECLARE is a simple macro that adds two things to the class: a static constant member, and a virtual method to retrieve that member for this specific class. This implementation also requires that there is the following code in a .cpp file:
[source lang="cpp"]TYPEINFO_IMPLEMENTATION(Shard::KeyPress, 1, CLASS(Crystal::Event));[/source]

This code creates the static constant member for the above class, and initializes it with parent information. TYPEINFO_IMPLEMENTATION is defined as:
[source lang="cpp"]#define TYPEINFO_IMPLEMENTATION(name, ...) \
const Crystal::TypeInfo name::typeInfo(Crystal::String(#name), __VA_ARGS__);[/source]

The first variable, name, refers to the name of the class which will contain a TypeInfo. The second variable is the number of parent classes. Normally this will stay as 1, to avoid the diamond problem, however in some cases multiple parents may be necessary. The following variables are the names of the parent classes, encapsulated in the CLASS macro, which just returns a TypeInfo variable from a class(as opposed to an object, which uses the PCLASS macro).
The following classes are currently implemented in WynterStorm like so:
[source lang="cpp]TYPEINFO_IMPLEMENTATION(Crystal::Object, 0);
TYPEINFO_IMPLEMENTATION(Crystal::Event, 1, CLASS(Crystal::Object));
TYPEINFO_IMPLEMENTATION(Shard::KeyPress, 1, CLASS(Crystal::Event));[/source]

Using Crystal::Object as a parent class is not a requirement for using the TypeInfo system, but is used here as the base class of Crystal::Event. Crystal::Object currently is just an empty class with TypeInfo, but I plan on extending this type later to server other purposes.

With that information, I will end with the following questions for you all:

1. What sorts of RTTI implementations are you using?
2. Do you find the C++ standard RTTI to be slow enough to warrant a custom implementation on modern machines?
3. Have any of you chosen to use a custom RTTI implementation for other features (reflection, for example)?
4. How would you suggest I change my current solution?

Thank you for your time,
-Wynter Woods