On Thu, Jul 9, 2015 at 2:13 PM, Vladimir Prus <vladimir.prus@gmail.com> wrote:

Boosters,

I wanted to remind that the formal review of Boost.DLL library by Antony Polukhin is nearing the end - the last day to submit reviews is Sunday. Of course, not much discussion is likely to happen on Sunday,
so if you have any thoughts, sending them on Thursday or Friday will
be much appreciated. Thanks in advance!

The summary of the library features and review checklists are reproduced below.

Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library
provides a portable across platforms way to:

   - load libraries at runtime
   - import and export any native functions and variables
   - make alias names for C++ mangled functions and symbols
   - query libraries/objects and executables for sections and exported
   symbols
   - self loading and self querying
   - getting program and module location by exported symbol

The documentation can be found at:

    http://apolukhin.github.io/Boost.DLL/index.html

and the source can be obtained at:

    https://github.com/apolukhin/Boost.DLL

Please post your reviews on the mailing list and if possible, answer the
following questions:

- Should the library be accepted?
- How useful is it?
- What's your evaluation of
  - Design
  - Implementation
  - Documentations
  - Tests
- How much effort did you put into your evaluation?
- Did you attempt to use the library? On what systems and compilers?


I apologize for this late response, I got tied up the last few days and was unable to look at this more thoroughly. I did look at the code, and all of the documentation/examples. I just had a few discussion points:

I'm sure some will find this library would be useful; I worked on a project that implemented the factory example in a Windows & Linux environment. Unfortunately, these types of systems are also brittle (ABI). Is there a way to add a symbol that acts similar to the soname automatically? If group A provides a boost::dll plugin with an explicit version, and then group B doesn't request that version when loading some symbol from the plugin, boost::dll automatically fails in all load functions. This way a provider of a plugin can force the user of a plugin to think about potential ABI problems through the boost::dll interface.

The use-case might be too narrow though, especially since the importer of boost::dll should really think about these issues. However, is it worth discussing ABI issues a little more in the documentation, or at least point to a good external resource (the Drepper paper)? Someone who finds this library may be less knowledgeable of such issues.


My other question was about the header-only design. Is there a reason why all of the code is being exported into the users codebase? Is it necessary? I think this should be a compiled + linked library, or it should be explained in the rationale. I'm guessing it can get interesting if this library itself were a pulled in as a DLL - is there a concern of plugins also use boost::dll but a different version? It wasn't obvious to me initially why this was header-only, this isn't template heavy library. Although, ASIO has a header-only mode option too.


Also Niall's demangling thing sounds nice but complicated. I think runtime errors would be preferred over undefined behavior, so hopefully it can be done.

Lee