Boost logo

Boost :

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).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk