I was looking for a way to automatically generate a run-time ID for any and every types. I came up with this:

template < typename _Type >
struct TypeRTID
{
	static size_t const m_id;
};
template < typename _Type >
size_t const TypeRTID < _Type > ::m_id = (size_t const) &TypeRTID < _Type > ::m_id;

you can use it like this:

size_t const floatRTID = TypeRTID < float > ::m_id;
size_t const floatPtrRTID = TypeRTID < float * > ::m_id;

Quote:Original post by Oiu1233
I was looking for a way to automatically generate a run-time ID for any and every types.

Why?

There are very few times that you need this kind of ID, and those few times (such as serialization) can be handled easily through a base class.

Quote:Original post by owl
Are there any drawbacks to this?

There always are.


It creates a static instance of every object. This may be an issue if you have large objects or nontrivial constructors.

The type must allow external linkage. It is possible to give a typename that has no linkage or internal linkage, and experienced template metaprogrammers use those. They would break the system.

Dynamic linking will give different results. Each module will have a different static instance, so provide different answers.

The value may differ between builds. It is quite likely that the addresses will change, and an id from one build may refer to a completely different type in another build, or refer to no object whatever.

There is broad liberty for the compiler as to how to interpret template type names. It is possible to have names unexpectedly merged, or types that you would expect to be merged end up distinctively different. If you use template types or typedef names it may be expanded to various unkonwn degrees.

Don't discount compiler bugs: there are still some linkers out there that will not properly merge duplicate templates.




There are very few reasons where you need to get an actual type id at runtime, and most of those can be handled through more reliable solutions.

I think the biggest problem is that assignment of IDs isn't guaranteed to happen before they're used. So before main() they could be set to zero and if you have other code using implicit initialization like this that depends on your IDs you could have subtle, hard to debug issues emerge.