RealityPrime

I don’t know how many active programmers read this blog. For non-programmers, you can safely skip this entire entry. It’s very technical and will probably be quite boring to anyone but hard-core software architects.

In developing my bigger overall project, I’ve needed a number of small utilities that I’d rather not have to create myself. One of those is a robust C++ runtime type system, useful for serialization, but also dynamic morphable code. The built-in C++ RTTI generally falls short for a number of reasons, including a wasteful 4+ bytes per object (that’s in addition to any virtual function table). The system in Visual Studio also doesn’t seem to understand the concept of structures and arrays very well, which makes it not at all useful to me. And other systems out there either add their own per-object storage, or they pre-process the header files (which is cool, but complex and painful to set up, and hard to limit to only certain objects and members), or they have horrendous macros to contend with.

So I wrote a quick drop-in replacement, which set me back two weeks on my master schedule. But it was worth it. It has zero per-object storage, no base-class to inherit from, no table lookups and the amount of typing for each new class I make is extremely low (zero, if I don’t want the class or member to have any type information). Plus, the system functions just as well for built-in classes, such as int and float, all pointers — everything I’ve thrown at it so far, including the rest of my vast new project.

Here’s an example class:

struct Foo
{
    int value;
    int* test[10];
    Foo* ptr;

    Foo() { }

// this special constructor, and a public default constructor/destructor are all you need per typed class
    Foo(TypePtr& t)
    {
        INIT_STRUCT(Foo);
        // use INIT_DERIVED(Foo,Parent) for all inherited members to be brought in
        // for templated classes, use INIT_TEMPLATE(Foo,mytype) to result in a type named "Foo<mytype>" vs. "Foo<T>"

        INIT_MEMBER(Foo, value);
        INIT_MEMBER(Foo, test);
        INIT_MEMBER(Foo, ptr);
    }

    Foo(int _value)
    {
        value = _value;
        ptr = this;
    }
};

If I call cout < < TYPE(Foo) , I get the following output printed to the screen:

struct Foo
{
    int value;
    int* test[10]; //internally: int**
    Foo* ptr;
};

This is all stored as a nested table of static Type objects, each about 48 bytes, not counting any string data for names, which I’ll probably make strippable for a release version.

The Type object for any given typename can be found by simply calling Typed<Foo>::GetType() (or via the equivalent macro: TYPE(Foo) ) For an instantiated object Foo f, call ::GetType(f). These calls are inlined and are resolved at compile-time to incur almost zero overhead, not even a table lookup–just a check to see if the type is not yet defined. The biggest cost occurs once, when the type is initialized via that special constructor, on first use (I gave up on using C++ static initializers, as the invocation order is hard to control).

For dynamic runtime typing, this requires one last small step: adding a virtual TypePtr GetType() { return ::GetType(*this); } (or macro ENABLE_DYNAMIC_TYPING ) to each derived class, which allows one to call f->GetType(); on any runtime object. It piggy-backs on the existing vtbl, so there’s no added overhead. Without that extra line of code, the Type would appear as whatever the compile-time pointer/reference thinks it is (e.g., a Foo* pointer will think the object is of type Foo, even if it is derived from Foo.)

That’s all the programmer has to worry about. Everything else is automatic. All basic types are defined, and pointer types are automatically created to match and point to (via a Type::GetDeref() call) their dereferenced types. I’ve experimented with alternative Cast(p) and Create() functionality as well, though I haven’t needed it. And I’ll add automatic serialization when I need it. Note: one need not include all members in a type definition. So it’s easy to make serializers that ignore runtime or derivative data, or even automatic pointer serializers that handle new memory layouts.

To explain how this is all done, one needs to understand templates pretty well, and partial specialization in particular. It allows a Typed<T> class that is automatically created for each type T that I invoke via any TYPE(T) or related call. It doesn’t exist unless you ask for it. And partial-specialization allows the system to define static initializers for built-in or opaque types that don’t require those special constructors, while still using generic class initializers for everything else.

The way it avoids any per-object storage is to use class statics in the Typed<T> classes, not in the many instantiations of each type. Since the basic underlying Type object is the same for all objects of that type (and, indeed for all types — the Typed<T> is just type-dressing), it only makes sense to store it here. And that allows a Typed object to exist without changing anything about the built-in int definition. It should work for opaque/finished types as well, but only for publicly accessible members (or protected members for derived classes). Finally, I’ve also played around with having a static-per-type "identity" object hang around which can be used for things like vectors and matrices, or anything else.

Anyway, this sort of thing is exactly why I like programming for myself. I can release the code, or keep it to myself. But most importantly, I don’t lose it when I change jobs or clients.

If anyone wants to use or improve on this system, please let me know. I’d personally like to get rid of the requirement for public default constructors and destructors, as some of my base classes like to keep those private. You can comment below if you’re interested. I won’t post it unless there’s sufficient interest, as it’ll take me a few hours to isolate it and package it up.

Tags: Articles // 6 Comments »