Re: [boost] [extension]

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-06-29 15:56:25

On 6/29/07, Stephan Diederich <stephan.diederich_at_[hidden]> wrote:

> Hi Jeremy and Mariano,
>
> On 5/29/07, Jeremy Pack <rostovpack_at_[hidden]> 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