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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk