Re: [boost] Boost.Outcome review - First questions

Subject: Re: [boost] Boost.Outcome review - First questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 20:41:17

>> Compilers spotted the common outcome::value_storage during moves when it
>> was identical, and totally eliminated any memory copies.
> Okay, so the single thing outcome::outcome provides is the conversion
> from the other Outcomes.
> I believe this is great and I will add it to the open question for
> std::expected as I've already notified privately to you (waiting a
> response :) )

Yeah sorry, private email has backlogged. I'm already spending every
free hour replying to email as it is.

I am also mentoring a GSoC student too, he takes priority. But I'll get
to your private email as soon as I can.

>> clang 4.0+ and GCC 6.0+ with -O3 optimisation appear to now be clever
>> enough to spot trivial move constructors and trivial types, and not copy
>> memory when the bits in memory would not change.
>
> Do you mean that now we can use optional and expected without any
> performance penalty and that the design of Outcome is not needed any more?

This is correct. But to be specific, the **storage layout** design of
Outcome is not needed any more with very recent compilers. I don't think
the current approach is damaging though.

>> Currently every time I commit to the git repo there is a new version of
>> Outcome. The ABI is permuted with the SHA of the git. This prevents
>> unstable versions of Outcome conflicting with different unstable
>> versions of Outcome in the same process.
>
> Hugh. I don't see how would someone like to use two unstable version of
> the same library.

In large orgs, one team may use one version of a library and another
team another version. Each team does not realise that the other team
does this. When someone else combines the libraries into a single
executable, boom!

>>> No this example doesn't show any advantage of Boost.Outcome, quite the
>>> opposite. However the other example that Andrzej has posted recently is
>>> a better example as I have already said as a response.
>> The only difference was returning result instead of outcome, and
>> removing the exception throwing function call. Otherwise the examples
>> are identical.
>>
> The return value is very important; the example show an important thing
> of Boost.Outcome: error propagation.

But we were propagating exception_ptr before. That is also error
propagation. I don't get the difference.

Niall

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