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/