Subject: Re: [boost] [system] Header-only Boost.System by default ?
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2017-10-15 11:38:13
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
-- Damien Buhl Software Developer +33 6 77 43 10 05
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk