|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-14 11:12:35
Robert Ramey wrote:
> I believe I have found the an acceptable resolution to the "registration" cunundrum.
>
> The whole problem was generated by by the fact that type_info is not portable
> and in my view never can be and wouldn't help anyway.
>
> Hence a function that did class->unique class identifer could not exist.
>
> I realize now that we don't really require that such a function exist.
>
> How about this.
>
> I conjure up something like (pseudo code):
>
> register_cross_program_class_identifier<class T>(const char *id="T")
>
> This would be invoked for each class declaration. Now we have
> a portable id associated with each class - exactly what we need.
> Polymorphic pointers would archive this tag and use it
> to determine the proper class to construct on loading.
That would be precisely right. Indeed, I believe this is the scheme I've
previously described in terms of type_info -> GUID and GUID -> factory
maps.
> The default class identifier would be the text representation of the class name.
> (note: in general not necessarily the same as type_info.name() )
> which is going to be sufficent for almost all cases.
Yes, exactly! I actually believe that type_info is the best form --
I don't know any other way to automatically get the class name.
> If one has concerns about the universality of his class identifier
> (e.g. a class named window or some such) or if one wants to
> do something more ambitious (e.g. plug-in system) he will
> be free to use any other const string to identify his class
> by overriding the default.
Right, e.g. string representation of COM GUID.
> explicit invocation of basic_[i|o]archive::register_type would no longer be necessary.
> I believe this would resolve the whole issue to everyone's satisfaction.
Yes, I'm starting to thinking that we'll have a quite good serialization
soon.
- Volodya
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk