Boost Users :
Subject: Re: [Boost-users] Boost.DLL formal review is ending soon - submit your reviews
From: Lee Clagett (forum_at_[hidden])
Date: 2015-07-13 14:07:25
On Thu, Jul 9, 2015 at 2:13 PM, Vladimir Prus <vladimir.prus_at_[hidden]>
> 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
> 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
> - self loading and self querying
> - getting program and module location by exported symbol
> The documentation can be found at:
> and the source can be obtained at:
> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net