On 29 June 2015 at 22:54, Antony Polukhin wrote:

2015-06-29 20:10 GMT+03:00 Klaim - Joël Lamotte :

...

On 29 June 2015 at 15:11, Vladimir Prus wrote:

...

The documentation can be found at:

http://apolukhin.github.io/Boost.DLL/index.html

Just a quickfix while I'm reading it:

In

http://apolukhin.github.io/Boost.DLL/boost_dll/tutorial.html#boost_dll.tutor...

...

"// This block is invisible for Quickbook documentation All you need to

do,

...

is write a simple class that stores callbacks and calls them at destruction:"

I believe the first sentence should not have been visible.

Fxd, thanks!

Another quick note: you might want to clarify somewhere that this is a header-only library. "To start with the library you only need to include header. " is useful but doesn't state exactly the same and I had to look in the repo to check that I didn't have to compile it. Otherwise the documentation is nice. I'm preparing a review.

2015-07-11 14:51 GMT+03:00 Bjorn Reese :

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, includes 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