From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-04-27 09:02:50
Stefan Seefeld wrote:
> Peter Dimov wrote:
>> entry_point will probably have to demangle the various "greet" exports
>> and perform overload resolution and implicit conversions as necessary.
>> This _is_ heavy machinery but it's hidden from the user and Boost.Python
>> may already contain the bulk of the functionality.
> If this is going to become the basis for a plugin system you probably
> want to have some versioning mechanism
Yea, which can be as simple as file containing:
I would like to point out that the similar versioning problem exists with
boost::serialization -- if you change class definitions without changing
class version, you run in problems. This however, does not render
serialization completely unusable.
> as well as some form of
> introspection, checksumming, etc. to catch the most common failures.
> In short, you will really end up developing a full-fledged component
Why do you need introspection or checksumming (what's "checksumming", btw)?
> I'm not saying this is worthless. I'm just pointing out that a simple
> dlopen/dlsym mechanism won't be really useful without the rest, and
> it's this rest that will be hard to do, in particular if the goal is
> to provide a generic solution.
BTW, in the case where plugins target a specific version of main
application, and versioning can be handled by other means (like package
management), you don't have any versioning problem at all to solve in the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk