From: Robert Ramey (ramey_at_[hidden])
Date: 2007-03-13 20:19:34
I've looked at this proposal a little bit. I was expecially curious how
it managed to do this totally within a header with not static objects.
I had been unable to do this.
Looking at a tiny bit more carefully, it seems to be that it presumes
that the possible "plug-ins" are listed ahead of time. I'm not sure
what the all the implications of that are. But it would preclude
shipping an add-on DLL to be used by an existing program.
This isn't necessarily a criticism, but its clear to me that this is
a "different thing" than what is part of the serialization libary.
The extended_type_info component could use a "construct
from id" function. The serialization library doesn't need it
but I thought it make make the component more useful.
The details turned out to be problematic. But recently
a possible way to do this has occurred to me. So maybe
something will happen someday in this regard.
Implementing this for non-RTTI wasn't all that hard
as I remember. It did require a fair amount of
code shuffling which resulted in breaking out extended_type_info
as a separate component.
The current version depends upon static objects to
register themselves in a global table so they don't have
to be "pre-registered" by the programmer. This is
convenient - and its what people insisted on - but I think
this is the root cause of some of difficulties which
occured (hopefully resolved in the HEAD) with
the dynamic loading/unloading of DLLS.
The serialization library lets one select the typeinfo
system he want's a particular class to use. The common
one is RTTI. However, one based on the specified
EXPORT name is also implemented. There is a test
which demonstrates that the different systems
inter-operate. So it might be interesting to see
if this method would/could be used as another
variation of extended type info.
I didn't spend a huge amount of time looking at it
so feel free to take these comments with a grain of salt.
Jeremy Pack wrote:
>> I want to suggest Robert Ramey as a mentor (if he agrees of course),
>> because boost::serialization already has some mechanisms for plugin
>> library in place.
> I agree - we discussed this in a thread a few months ago. Robert's
> would be appreciated, especially for removing the RTTI requirement
> from the library. He already pointed me in the right direction - I
> just haven't
> gotten the chance to work on implementing it yet.
> However, there are places in the code where I currently use a python
> script to generate some redundant template code - Hartmut Kaiser's
> preprocessor library would probably come in quite handy there and in
> a few other places.
> A number of items in my "to do someday" list involve using the
> preprocessor and template tricks.
> Either of them has knowledge that would give Mariano (and me of
> great material for the library.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk