Subject: Re: [boost] Boost.DLL formal review is ongoing
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-07-07 14:16:57
2015-07-07 18:48 GMT+03:00 Rodrigo Madera <rodrigo.madera_at_[hidden]>:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk