Re: [boost] [Boost.DLL] Formal Review request

Subject: Re: [boost] [Boost.DLL] Formal Review request
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-10-06 05:38:48

2014-10-06 13:07 GMT+04:00 Andrew Marlow <marlow.agents_at_[hidden]>:

> 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