2014-10-06 13:07 GMT+04:00 Andrew Marlow
For anyone who is interested in boost.DLL, as a user, implementor, reviewer or just curious, I encourage them to look at ACE DLL. ACE has been there, done that.
I've took a look at it and saw no advantages over Boost.DLL. Moreover, it looks overcomplicated at some places (DLL_Manager class is redundant, OS takes care of this; not unloading plugins looks like a strategy from pure C that is not good in C++; no UTF16 support and so on...)
I know that ACE code looks horrible due to its age and the need to support ancient compilers, and there are ugly macros all over the place. However, ACE has solved this problem so I think developers that want to solve the problem again should look at how it has been done before.
For example, I see from the boost.DLL example that the entire pathname, including any OS-specific suffixes etc, is supplied to the ctor. ACE takes a different view and it is instructive to look at the comments in the code to see why. I am thinking of different versions of UNIX in particular and how they handle shared libraries differently.
Use `load_mode::append_decorations` to avoid specifying platform specific decorations. Not specifying a path leads to many problems. Take a look at the WinAPIs mess of "add-search-path/remove-search-path/add-maybe-before-search-path/add-search-path-before-before". It's hell, global variables are not good in modern multi threaded programs.
ACE has also thought about shared library lifetimes quite thoroughly and caters for a lifetime that might be greater than the immediate object that is doing symbol lookup for example. This is in the DLL_Manager class.
Please take a closer look to the Boost.DLL library and tell me what is exactly missing. -- Best regards, Antony Polukhin