repos

[martin f k. <ma...@ma...>]

Stephan: about our plans to provide dynamic module loading
compatible to libfactory++.

Instead of libdlfactory or librefactory, I think what we want
instead is two new libraries and leave libfactory++ as it is:

  libdllfinder++ (or maybe libsofinder++)
  libmodloader++

The first exports an API to search the filesystem for a DLL that
exports certain functionality. It should be able to take a class
name (which we can translate to the class constructor and search for
the function), and it should be able to use

  - a config file specifying paths
  - an environment variable of paths
  - a path list in the function invocation

to search. The return value should be the absolute filesystem path
of the DLL defining the class, or it throws an exception otherwise.

First, we must check if (a) such work already exists, and (b)
whether it is possible at all. Remember that mangling it a bitch,
but you probably know this much better than I do.

The second library then merely loads the DLL at runtime, registers
the class with libfactory++ and makes the user happy. It can either
just use the class name to identify the builder in the registry or
generate a unique name on the fly. I guess both should be possible,
and with the latter, it should be possible to use other types for
the index than std::string.

What do you think?

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: mad...@ma...
=20
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
                                                       -- mark twain