On 12/10/2017 10:51, Groke, Paul via Boost wrote: [...]
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? Representing this case where 2 modules link to the same error_category which actually end up being instantiated twice. So that I could play with it. But I can I build it from scratch as well.
What this discussion shows IMHO opinion is that via a dll or via an header only exported static inline function we aren't really able to prevent the library user ending up having more that a single address for the same error categories. There are for both case combinations where this might break, but that's IMO a problem of people builds setup. And it would then really be a problem when the errors begin to be evaluated across their originating modules, which narrows even more the risk that this actually becomes a real problem. So personally I stay inclined that defining BOOST_ERROR_CODE_HEADER_ONLY+BOOST_SYSTEM_NO_DEPRECATED would be a better default in the future. :D Cheers, -- Damien Buhl Software Developer +33 6 77 43 10 05