Subject: Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2015-07-03 17:16:51
On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:
> The formal review of Boost.DLL library by Antony Polukhin is nearing the
> end of the first week.
> As of today, over 100 people read through the library's tutorial,
> suggesting quite some interest.
> However, no reviews were submitted yet. Please take the time to post your
> thoughts - even if you
> don't have time to do a full review, or try the library, comments on
> design and interfaces are
> still very valuable.
I started an experimentation to check a few things related to plugin
systems specific to my projects
and want to finish it before giving a final review.
I still can do a pre-review using my experience so far, but wait for my
confirmation before counting my review.
> Please post your reviews on the mailing list and if possible, answer the
> following questions:
> - Should the library be accepted?
YES, it should be accepted.
> - How useful is it?
- It helps solving a common problem (the code managing plugins in an
- It does it without the usual constraints (interface only in C for
example) - this part I am actually challenging with my test code.
- It's header only and cross platform.
- It does not do more than helping getting functions and objects from
shared libraries (like previous boost.extend did IIRC).
- I tried to use several other such libraries before and so far it's the
> - What's your evaluation of
> - Design
I consider the solutions provided to solve each usual issue with plugin
systems to be simple
and clear, easy to use (as long as you understand what loading plugins
Until I check in some complex cases, I think the design is very good.
The symbol name magic might be tricky to understand sometime but it's an
issue which is a side effect of providing
a simple tool to manage symbole names, so it's still good.
One thing I was wondering: would it be possible to provide a way to load
shared libraries from
raw memory? Or does the OS APIs all requires that the library have to be on
a file sytem?
I didn't look at the implementation yet.
> - Documentations
It's good. I pointed a few things but globally it's working for me.
I do not understand how to use this function, what is T here?
Also, I did a lot of different plugin systems in the past so I am not sure
what someone unexposed to this kind of system would think of the code.
I suspect that the table in the QuickStart page might scare such people at
but in the same time I find it very useful as a summary of how to use the
I didn't have any problem with the tutorial so far.
> - Tests
I didn't run nor read the tests provided with the library.
> - How much effort did you put into your evaluation?
I read all the doc without references pages, a big part of references
The small test project I am trying to setup is a complex "worse case"
plugin system matching
my most difficult project (for which plugins are a vital part of the
so once I do that I'll have a good idea of
potential issues in non trivial cases.
> - Did you attempt to use the library? On what systems and compilers?
Yes as said before I have a small test on-going but it's not finished yet.
My attempt is currently on VS2013 64bit on Windows 7 and 8.1.
I would like to try it with VS2015RC but Boost 1.58 does not compile
correctly with this compiler.
I will try it with gcc and clang on linux once my test is finished and
working on Windows.
I expect all the platforms to behave the same in my test, so we'll see.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk