Boost logo

Boost :

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:

  PluginName=foo
  Library=foo.so
  ABIVersion=3

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
> model.

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
library.

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk