Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-11 19:11:19

On 11 Feb 2016 at 11:57, Michael Marcin wrote:

> On 2/11/2016 5:47 AM, Niall Douglas wrote:
> > outcome<int> _foo; // contains some value
> > int foo;
> > if(_foo) foo=_foo.get();
> > foo=_foo.get_or(5); // also works
> 
> I'm not convinced.
> 
> I ran a comparison of a trivial implementation of result with your test 
> code versus your implementation.
> The results weren't pretty.

I'll caveat everything I'm about to say with a dose of salt as from 
past experience my memory of what Stephan told me varies from what he 
actually told me. So bearing that in mind as my memory recalls faulty 
...

Stephan took a very conservative interpretation of error categories 
on the Dinkumware shipped with MSVC, and so you get a large quantity 
of "splosh" on MSVC because touching an error category forces 
emission of code.

You'll see vastly tighter code on GCC especially, and pretty good on 
clang. In the op code counting unit tests there are something like 
1000 opcodes on MSVC for six instructions on GCC. It's that bad.

When I raised just how much opcode splosh MSVC generates with 
Stephan, he asked "is it any slower?" I benchmarked it, and the 
answer is not much, barely measurable, maybe only a few dozen CPU 
cycles. It's basically binary bloat, other than that fairly benign.

Stephan has promised to look into the very strict interpretation of 
error categories in a future MSVC if the less strict interpretation 
on libc++/libstdc++ proves benign in real world usage. tl;dr; a fix 
for the bloat generated by MSVC when compiling Outcome is many years 
out, if at all.

Niall

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