Re: [boost] [system] Header-only Boost.System by default ?

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

Cheers,

-- 
Damien Buhl
Software Developer
[phone]