Sure, this is possible. I actually am working on something slightly similar for a component-based entity/game framework. All it requires is some template work, basic inheritance, the typeid() operator and a few static variables.

First, if you've never heard of either pluggable factories (or, more specifically, the really cool trick used for autoregistry) or the curiously-recurring template pattern, I suggest reading the posted links. The pluggable factory technique is the core trick you're going to need, all remaining bits are basically ease-of-use tricks.

Next, I suggest creating a 'registrar helper' object that maintains all information about your type system. At minimum, I've found a method to retrieve the type name as a string and some sort of numerical type ID useful. Essentially what you're going to be doing with this is creating a static instance of one of these for each type you want to register and using C++'s static object initialization idioms to have this be handled automatically. For reference, see the 'm_registerThis' thing in the linked pluggable factory article.

Here's where things get cool. Fundamentally what we want to do now is come up with a way to actually achieve that 'one static registry thing per object type,' and I find a CRTP variant to be the most elegant solution here. This class is ultimately very basic, and more or less just serves as a vehicle to attach this registry helper without also cluttering up the class with inherited member variables, etc. You should be able to get away with something like the following:


Since you mentioned using something like this for serialization, you may want to include interface declarations for serialize()/deserialize() methods, though this may be better off placed in a separate abstract class that the aforementioned CRTP helper object derives from-- making an interface like that behave is a pain in the ass with templated types. Now all a user has to do in order to make an object visible to your system is have it inherit from this CRTP class, like so:

Presto! But wait, there's more!

I don't think I mentioned the specific method(s) by which you can have the compiler automagically fill in the name of the type, but this, too, isn't rocket science-- enter typeid(), as in the following:
(this can be placed in the CRTP base class header file and assumes a constructor for the helper object is defined, taking a single const char* as an argument.)

The second cool trick the CRTP does here is to allow you access to the C++ type that you want to register. The type_info structure that typeid() returns contains a useful member, 'name,' that contains the name of the type. Unfortunately for us, however, the specific content of this is compiler-dependent and almost always not what we're after. That being said, there is a way to turn it into something practical:

If building on GCC, you will also need to free() the resulting character string, as mentioned in the comments. Operator delete[] will not work. Since I mentioned that storing the name was a good idea and something I do anyways, you can simply pop this in the type registrar helper's destructor and have everything work fine.

From here, you're free to add any sort of additional indexing information into the type registry, etc. and/or implement additional serialization functionality, as per the linked article on pluggable factories. As it's entirely possible that I missed something here, please feel free to ask questions if there's something you don't understand or if you run into implementation issues. I'm actually quite fond of how nicely this came together for me :)

EDIT: Realized I forgot to include a few needed headers in the undecorate function, so that's fixed now.
EDIT 2: Also clarified how typeid() fits into the whole shebang.