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

Subject: Re: [boost] [system] Header-only Boost.System by default ?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-10-10 01:59:50

On 10/10/2017 12:31, Niall Douglas wrote:
> On 10/10/2017 00:15, Vinnie Falco wrote:
>> On Mon, Oct 9, 2017 at 10:34 AM, Niall Douglas wrote:
>>> The only correct and safe way to use error categories is from a shared
>>> library. In header only mode, multiple instances may appear and thus no
>>> longer be proper singletons. Stuff breaks in this situation, badly.
>>
>> If this is true, and I hope that it is not, then we better do
>> something about it and soon, because forcing header-only libraries
>> that want to provide their own error categories to put them in a
>> shared library is a non-starter.
> 
> Nothing we can do. WG21 is still thinking about how to solve it
> properly. All attempts until now to fix the base cause of it have run
> into quicksand.

Short of magic compiler changes (and possibly OS changes, since it would 
require having a symbol from multiple shared libraries loaded at the 
same address), probably the only way to resolve that is to not require 
singletons -- which means that code that does pointer comparisons on 
categories has to be hunted down and replaced with code that compares 
some internal id that is common to all intended-to-be-identical 
categories, which in turn requires that someone explicitly define a 
suitably unique id for each custom category.

Which is a breaking API contract change and a performance reduction and 
adds the problem of managing unique category ids.  (And ensures hilarity 
will ensue if someone doesn't use a unique id for different categories.)

The other way to prevent the problem is to guarantee that error codes 
are never passed across shared object boundaries, but I think we can 
probably agree that in most cases that's a non-starter.  Although it is 
something that header-only libraries are perhaps slightly more likely to 
get away with (by then pushing the problem to the application author).