-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Damien Buhl via Boost Sent: Dienstag, 10. Oktober 2017 21:54 Am 10.10.2017 um 10:21 schrieb Groke, Paul via Boost:
[...] And even if the "same address" thing was solvable (which I think it is, although not pretty and it would require interface changes), there is the problem with unloading DLLs/SOs. You'd have to pin every module that contains error categories. Which IMO is a side effect that you really don't expect and want, especially from a header-only library.
I must be missing something about internal linkage. This problem should already exists with the current implementation no ? If you have an error_category singleton instance in a TU, then unloading a dll containing this TU should also lead to having the error_category refer to some incorrect memory location then.
You're right. It should work though if it's guaranteed that the module that created an error_code object is still loaded while there's a chance that the object may be accessed. If you add some magic that manages to find an already existing equivalent error_category instance, to solve the "more than one instance" problem, an error_code created in module A might end up referencing the error_category object in module B. Then unloading module B would break error_code objects created by A, which really isn't good.
Do you know of any example code doing this ?
Doing what exactly?