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. Robert Ramey 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 help 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 course) great material for the library.
Jeremy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost