Boost logo

Boost :

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

>> - What is your evaluation of the documentation?
> Hard going. Niall knows far, far, far too much already? Get someone else to write a tutorial on 'how to use outcome'?

This saddens me.

Can you suggest particular hard going parts?

> (I expected a folder in /libs called outcome, but I got one called boost.outcome so it wasn't in the alphabetical order or format
> that I expected, but I found it :-)

You need to do "git clone
outcome" if you want to rename the output directory.

> I expected to be able to run the examples using b2 but sadly this is not supported. Is there any reason why not (apart from an
> aversion to bjam?) Boost has a system (even if not the best or Niall's preference) for running on multiple platforms and this
> doesn't fit with it which feels Boost-unfriendly at least.

Outcome provides a very rich cmake experience. If accepted, I will
implement bjam support.

> However, it appears to run OK from the IDE 'start without debugging' but produced no output. Not comforting. It really isn't my
> idea of a simple example. So I tried expected_payload1.cpp since it looks (and was recommended) as a better working example. (VS
> moans about deprecated Posix names, but hey... and boost.outcome\example\expected_payload2.cpp(27): warning C4267: 'argument':
> conversion from 'size_t' to 'unsigned int', possible loss of data is ugly).

You hit on a good observation. More than half of the examples are not
usable as programs, they are only there to compile successfully and get
sucked into the documentation as code example. I've logged the issue to

> The output "Failed to open file somefile due to 2" isn't an exemplary error message, even if it is only trying to show how outcome
> works. (Putting this string "Failed to open file somefile due to 2" as a comment would make it easy for the reader to understand
> without actually running the example).

Grr. Your STL's printer for error_code is not being helpful.

> I tried to run the test expected_pass.cpp but got
> modular-boost\libs\boost.outcome\test\expected_pass.cpp(15): fatal error C1083: Cannot open include file:
> '../boost-lite/include/boost/test/unit_test.hpp': No such file or directory
> but it looks plausible. Again I'd expect a jamfile to do this.

If you don't want to use cmake, I placed a batch file in test called
"withmsvc.bat" which speaks the right incantation for MSVC.

> In the end, we now have to decide if this is all going to be 'OK in the end' and have faith in Niall's skill, judgement, and
> determination to see this functional and finished. I do. So that's a yes.

Many thanks for the review, and I am sorry that compiling and running
code went so badly for you.

> Nits noted
> ==========
> Lots of files missing Boost licence. This is of course essential for Boost.

All of the implementation files, bar the auto generated one, should have
licence boilerplate. The boilerplate is actually generated by a python
script incidentally, saves me having to remember.

You're right that the examples are missing those, historically due to
doxygen. Logged to

The test/expected_pass.cpp file is not my code, it's Vicente's from his
test suite. If he prepends some licence boilerplate to his, it'll get
picked up in mine.

> Some punctuation and a nicer:
> This eliminates the fragile switch statements converting between error code domains in favour of an information loss-free
> transmission. The cost is once again a loss of type safety because if a function might return an error code, it should never be able
> to return and the compiler will not complain.

Fixed in develop branch. Thank you.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at