2015-07-07 18:48 GMT+03:00 Rodrigo Madera
Before I give my review, I would like to first ask some open questions here and see if I understood some points correctly.
* Is Mac OS totally unsupported?
It is supported and must work (in theory). Unfortunately I have no device with MacOS so it was impossible for me to run tests.
* When would support for it be possible?
If the library will be accepted into Boost, then the library will be tested by the Boost regressions testers. It means 100% support for MacOs, Android and other platforms.
As an avid Mac OS user, I feel excluded. Don't know if this is an issue for anybody else, though.
I'd like to have an online service for testing on MacOS or at least a virtual machine that supports MacOS out of the box. Unfortunately I've found none... That must be a disturbing alarm for the vendor: developers can not test software on the platform!
* Why is the default section named "boostdll"?
Section name must be a valid C identifier, so it seemed like a nice idea to use that section name for Boost.DLL
* Why not use the platform default?
This seems like a more user friendly solution. If a user is exporting symbol with an alias name, then there's a chance that some day the user will need to query exported symbols. Putting symbols into the default section will make them indistinguishable from other symbols.
* Can't the "on_unload" have a similar API in the library?
If the user needs to do something on library unload, then a global/static variable with user-defined destructor is the solution. Such solution is much more flexible and does not force user to use `on_unload` API (which is not ideal). I suspect that `global/static variable` to be more common. But you're right, this must be more explicitly specified in docs. Typo with `[callplugcpp_tutorial6]` also must be fixed. -- Best regards, Antony Polukhin