1. The boost::extension author reported (when i asked him) a lack in the C++11 standard (without precision) that makes it hard to implement correctly this library on all platforms/compilers (unfortunately he didn't say which ones). Do you have any information about that?
I don't exactly understand what is the problem. You create an entry factory point like extern "C" { foo* bar(); } Resolve bar withing shared object/dll and it works 100% As long as you don't mix runtimes i.e. dll and main program uses different heaps and so on there is no problems I'm aware of.
2. booster::shared_object::shared_object(std::string const & file_name )
Here file_name is a path, right? I'm guessing it's relative to the way the OS will look for modules?
Actually it is quite same on Unix and Windows. A name without "path" like "foo.so" it searches withing general path, on windows .:$PATH and on Unix under predefined set of locations + LD_LIBRARY_PATH. If full/relative path provided it searches according to it.
3. Is there a specific reason that there isn't a provided abstraction (template "helper" function) that will call resolve_symbol() and try (dynamic or not) to cast it for you to the provided type? My understanding is that you wanted to let the user do as he wish but I was asking myself if common usage could be identified and provided by default.
There is a helper function that helps to cast void * to function pointer. Genrally any plugin/so/dll should have its entry point like shown above and implement some known interface. What would do the job. It is more abstraction of dlopen/dlsym rather then generic interface to map anything you want need dynamically.
Thanks!
Joël Lamotte
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost