Re: [boost] [Boost-users] Boost.DLL formal review is ongoing

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
application).
 - 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
less intrusive.

> - 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
imply).

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?

  - Implementation
>

I didn't look at the implementation yet.

>   - Documentations
>

It's good. I pointed a few things but globally it's working for me.

Note:
http://apolukhin.github.io/Boost.DLL/boost/dll/symbol_location.html

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
first,
but in the same time I find it very useful as a summary of how to use the
library.
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
pages.

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
design),
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.