On 6/29/07, Stephan Diederich <stephan.diederich@googlemail.com> wrote:
Hi Jeremy and Mariano,
On 5/29/07, Jeremy Pack <rostovpack@gmail.com> wrote:
Versioning can be done very simply using the Boost.Extension library. This will be described in greater detail in the documentation soon, but you can get a hint as to how it's done from the examples.
Thanks. That helped. I'm doing exactly what you suggested, plus something additional I'd like to share. (The idea is actually taken from CrystalSpace). In the interface class I'm defining an method to retrieve the current version of the interface. This method gets an "always inline" attribute. When exporting the class through boost.extension, I'm calling that method to store the current Interface version in the Info-struct of boost.extension. Now I've a wrapper around the factory map, which compares the stored version in the plugin with the current version of the interface. That way, I can change the interface class and increase the version number without getting bad surprises.
That is a good idea - it certainly shouldn't be hard to add those extra classes (they'd be optional). Once you feel the code is ready, why don't you post some samples here. If it looks like it will fit well, it could certainly be worth adding. If you want us to try and write the code to do the same type of thing, we can try that as well - but it won't be done as soon.
For part 2, this can actually be done using RTTI - just dynamic_cast it.
Works, thanks! I thought it wouldn't be possible to dynamic_cast a type from another library, but it seems to work... Any ideas if this can cause problems?
If I recall correctly, there is the possibility of problems using an older (much older) version of Borland C++. I read about it on some Borland help site once while designing the library. I think I've written it in a way that will overcome even those problems - but we won't find out until we've run the unit tests on more machines. Thus far, we've found no issues on any compiler. Another thing I recently discovered is some kind of class -> library
mapping. This is especially useful for debugging purposes... Did you think about that?
This is one of the items on our "To Do Someday" list - but we're not sure how soon we'll get time to work on it. A few other people have expressed interest in it as well, so we'll see what we can do. The initial version of the library (October 2006) actually did have this sort of mapping, but I haven't rewritten it for this latest implementation (which has changed substantially). Jeremy