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