Re: Announcing Xrtti - Extended Runtime Type Information for C++

On May 6, 9:26 am, Le Chaud Lapin <jaibudu...@gmail.com> wrote:


I am interested to learn more about what you are saying here. I want
Xrtti to be as useful as it can be, and I think you are suggesting
that there may be a way to make it better. Can you please elaborate
on this statement?

For what it's worth, Xrtti allows the lookup of the complete extended
runtime type info for any object with a vtable, regardless of how that
object is pointed to. So you can write a method like I have in my
example code that does something like this:

void DoSomethingWithAnUnknownObject(void *pObjectWithVtable)
{
     const Xrtti::Struct &structRef =
Xrtti::LookupStruct(pObjectWithVtable);

     // Now you have complete access to all descriptive information
about
     // the type of the object pointed to by pObjectWithVtable, and can
     // create an instance, call methods on it, destroy it, etc, via
the Xrtti
     // API
     ...
}

What I'm getting at here is that you don't need to know the name of
the class defining an object that you encounter at runtime, you can
still look up its complete extended runtime type information. I am
not sure exactly what more you would need to serialize it.

Although I wonder if maybe you are thinking about the deserialize
case, where there must be an identifier encoded in the serialized form
of the object that allows the serialization library to re-acquire the
type information about the serialized object. In this case I can
think of a couple of ways:

1. Store the full class name of the object in the serialized form,
i.e. Foo::Bar::Baz. Then assume that if the program has Xrtti info
for the class named Foo::Bar::Baz (i.e. const Xrtti::Context *pContext
= Xrtti::LookupContext("Foo::Bar::Baz") returns a non-NULL Context),
then it must be the "same" class and can be deserialized with the type
information thus returned. This would fail if a program happened to
use the same full name for a class as another program, but the classes
had different forms. This could be avoided by all programs using
their own private namespace to define their classes, but this is non-
ideal because it requires cooperation between all programs ever
written.

2. Use some other means for giving unique "identifiers" to class
definitions; maybe some kind of global registry, where a person or
corporation could register a namespace that then becomes unique to
them, and they can give whatever unique names that they want to
classes they define, and map those names to the actual class names in
their programs. This has the disadvantage of requiring coordiation
between everyone using the serialization framework, and some global
registry.

Are these the sorts of things you were thinking of when you wrote your
statement? If so, do you have any other ideas about how to approach
this problem?

Thank you,
Bryan

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]