Re: [boost] Boost.DLL formal review

Subject: Re: [boost] Boost.DLL formal review
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-07-11 17:50:46

2015-07-11 14:51 GMT+03:00 Bjorn Reese <breese_at_[hidden]>:

> It is unclear to me whether there are any limitations about aliasing.
> For instance, can I alias constructors, operators, or functions in an
> anonymous namespace?
>

Functions and classes from anonymous namespaces could be exported using
aliases. There's no anonymous namespace related restrictions.

>     - Implementation
>>
>
> Looks clean from my brief examination.
>
> My only complaint is that some headers includes system headers that
> typically brings in their own macros and non-namespaced types which
> may or may not colide with the user code. For example,
> <boost/dll/runtime_symbol_info.hpp> includes <dlfnc.h> on Posix
> platforms. This is not a major complaint, and I realize that this
> can be difficult to avoid in a header-only library.
>

This is avoided for Windows (we have the Boost.Winapi module that takes
care of that), but for Linux, MacOS and other platforms this could be an
issue. Extremely heavy headers are avoided (for examples those, that
contain platform specific binary formats descriptions). Taking care of
others requires new module Boost.POSIX, which is not in my plans right now.

>     - Documentations
>>
>
> Generally good and well-structured.
>
> Some suggestions and minor comments:
>
> Some sentences are difficult to read due to their grammar. For example,
> the "Linking plugin into the executable" tutorial, or the the second
> and third questions in the FAQ.
>
> Tutorial "Searching for a symbol in multiple plugins" should mention
> that previously loaded libraries are unloaded on subsequent loads (this
> is mentioned in the reference documentation, but it would be nice to
> have here as well.)
>
> Tutorial "Symbol shadowing problem (Linux)" should start by describing
> the problem it solves.
>
> Reference BOOST_DLL_SECTION says: ''Permissions Can be "read" or
> "write" (without quotes!).'' I suggest that you list the names as
> code-blocks instead (e.g. use `read` in the .qbk)
>
> Reference runtime_symbol_info: When I first saw the *_location names
> I thought that they referred to the addresses (especially
> this_line_location.) I suggest that they be renamed to *_path.
>
> Reference dll::import and dll::import_alias uses string_ref for
> func_name, yet states that func_name must be a "Null-terminated C or
> C++ mangled name of the function to import. Can handle std::string,
> char*, const char*."
>
> FAQ ends with "[endsect]"
>

I'll fix those issues.

> The design rationale and the FAQ seems to be in disagreement about ABI
> portability.
>

Did not get that. At what place do they disagree? ABI != portability.

-- 
Best regards,
Antony Polukhin