- 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 https://github.com/ned14/boost.outcome.git 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 https://github.com/ned14/boost.outcome/issues/37.
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 https://github.com/ned14/boost.outcome/issues/38 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/