Arkadiy Vertleyb wrote:

"Robert Ramey" <ramey@rrsd.com> wrote

...

I'm just taken a cursory look at this scheme. But it likes it might be similar or even identical to that implemented by the serialization library to recover types for serialized pointers. See extended_type_info.

Most importantly, does this scheme really work in practice? Is it easy enough for end users, and does it allow users and libraries to avoid collisions with each other?

Oh it works - its being subject to the boost torture test process as we speak. The issue of unique type identification was addressed at length during the first serialization review. If the typeid is only used within a program runtime type_info can be used. The system doesn't require type_info to be used but that's usually the most convenient - unless your compiler doesn't support runtime typing. If its to be passed from one executable to another - persistence and/or marshalling - you have to export it with some sort of key. I usually use the class name. Its all in there and even explained in the context of its usage within the serialization package. There is also a facility referred to a void_cast which is used to correctly cast from one type to another at runtime. That's the short version - you might want to check out the manual and the code. It could easily be excised from the serialization library. I only did it because I had to have it and I couldn't find anything else out there. Honestly, I'm not even sure it addresses the same issue that you do. Feel free to check it out. Robert Ramey