Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-19 14:05:08

> I'm assuming that this code somehow avoids the double-checked lock for
> static objects with function scope:
> https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/error_code_extended.hpp#L47
> 
> Can you please explain how it achieves this goal on all platforms?
> 
> I'd also like to understand this declaration:
> 
>     BOOSTLITE_NOINLINE inline const std::error_category &_generic_category()
> 
> Why is there a no inline macro followed by the inline keyword?

Inline linkage to allow multiple symbols, but never inline.

Some STLs (Dinkumware) ensure that the address of an error_category is
always unique throughout a process as per the C++ standard requirement.
Their code for figuring out a canonical singleton is a thread fence,
force emitting code, and some optimisers e.g. MSVC's give up at folding
code very quickly when they see a thread fence. This causes sequences of
result<T> or expected<T> to not be elided and collapsed by the optimiser
as we'd prefer.

The hack is the above. We cache the address of the canonical singleton,
and the noinline seems to cause the optimiser to disregard the thread
fence and thus to not give up quickly. The resulting assembler generated
is greatly improved on MSVC, a single result<T> shrinks from ~260
opcodes to less than 5.

I left the hack enabled on all platforms as it's benign and future STLs
might do something like Dinkumware. I might add that the hack has no
statistical effect on performance, but it reduces code bloat.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/