On 3/13/07, Robert Ramey <ramey@rrsd.com> wrote:
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.
It took me a while to figure out. I probably wouldn't have submitted the library without this feature - it is one of the primary features that sets it apart from the other plugin libraries that I was able to find. 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.
I can see how my examples might give that impression. It does NOT require that the plugins be listed ahead of time. It does require that some sort of interface (base class) be defined ahead of time. But shipping an add-on dll to be used by an existing program is the primary goal of the library. I think one of my examples shows that pretty well - look in the examples folder for the hello world example. The "existing program" (main.cpp with a header of word.hpp) only knows about the word class. The "Add-on DLL" (hello_world.cpp, which also uses word.hpp) is the only entity that knows about the hello and world classes. But the "existing program" can use them, because they are both derived from the word class. I will attempt to have decent documentation up with the rest of the code very soon. Thanks to all of you who have taken the time to look through the library anyway! 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.
That is what I expected - I doubt that there is a way to do the extended type info without static objects unless you require a bit of extra work from the user. 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.
This would be very useful for plugins - allowing a choice between the systems would definitely alleviate a lot of people's concerns. 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
I don't expect anyone to take a huge amount of time looking at it yet - I put it up to find out if anyone had suggestions for API improvements or additional features. Thanks for looking over it! Jeremy Pack