- Boost - lists.boost.org

[outcome] Changelog of all changes made since review announcement one week ago
by Niall Douglas 20 May '17

20 May '17

Dear list, The Outcome review begins later today, but so much feedback has landed this past week already that I had better announce what has changed in develop branch to prevent people reraising already fixed things: ## 20170519 boost_peer_review4: - Issue #13 The opcode counting CI tests in test/constexprs was severely broken on POSIX. Thanks to Tom Westerhout for finding the problem and supplying its fix. - unittests.cpp had become clang-tidy unclean, fixed. - Issue #15 Move `outcome::expected<T, E>` into `outcome::experimental::expected<T, E>`. Thanks to Vicente J. Botet Escriba for persuading me to do this. - Issue #14 Removed all the static asserts in the Expected implementation apart from the nothrow move constructor check, which is now correct unlike the incorrect assert from before. Thanks to Vicente J. Botet Escriba for explaining Expected's semantics. - Issue #21 Correct misspelling of `extended_error_code` with `error_code_extended` in the docs. Thanks to Deniz Bahadir for reporting this. - Issue #17 Give credit to Paul Bristow for the name "Outcome". Thanks to Peter Dimov for finding the correct person. - Issue #18 `result<T>` had a `.set_exception()` which it should not have had. Thanks to Peter Dimov for reporting this. - Issue #19 Remove observers `.is_ready()`, `.get_error_or()`, `.get_exception_or()`. Thanks to Peter Dimov and Andrzej Krzemienski for suggesting this. - Issue #20 Rename: - `monad_error` to `bad_outcome` - `monad_errc` to `bad_outcome_errc` - `monad_category` to `bad_outcome_category` - `BOOST_OUTCOME_THROW_MONAD_ERROR` to `BOOST_OUTCOME_THROW_BAD_OUTCOME` Thanks to Peter Dimov, Andrzej Krzemienski and Paul Bristow for suggesting this. If anyone prefers to see these changes in a tarball, you can get a tarball at https://github.com/ned14/boost.outcome/releases/tag/boost_peer_review4 or the boost_peer_review4 tag in git. Note that this tarball was generated straight off develop branch from my laptop and MAY NOT WORK well. I didn't get a chance to implement these outstanding issues before the review began: - https://github.com/ned14/boost.outcome/issues/11 Expected should never have a valueless state - https://github.com/ned14/boost.outcome/issues/12 Copy assignment gets instantiated even when type T cannot be copied - https://github.com/ned14/boost.outcome/issues/16 Default constructor of T is sometimes compiled when T has no default constructor Thanks in advance for your feedback and reviews. As I hope the above shows, it makes a big difference. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

[context] Windows x64 fiber local storage GS offset
by Elbert Mai 20 May '17

20 May '17

The Windows x64 implementation of Boost.Context saves fiber local storage from GS:[0x18]. For example, in jump_x86_64_ms_pe_masm.asm: ; load NT_TIB mov r10, gs:[030h] ; save fiber local storage mov rax, [r10+018h] mov [rsp+0b0h], rax However, this is the NT_TIB struct as defined in winnt.h typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; union { PVOID FiberData; DWORD Version; }; PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; This implies that fiber local storage is found in GS:[0x20], not GS:[0x18]. The Windows x86 implementation uses FS:[0x10], which is consistent with the NT_TIB struct. Am I missing something, or does Boost.Context save/restore fiber local storage at the wrong address in Windows x64?

3 3

[Beast] Discussion
by Vinnie Falco 20 May '17

20 May '17

A desire was stated in the 2015 formal review for Boost.Http, that the author would engage the community during the development of the library. I've been doing that throughout the development of Beast and I will continue to do so. So I am inviting you and anyone else who would like to participate in the design and evolution of this library to weigh in with comments on anything that you would like, ahead of the Beast formal review (scheduled July 1st). Your feedback can help make the library better! On Sat, May 20, 2017 at 8:19 AM, Bjorn Reese via Boost <boost(a)lists.boost.org> wrote: > On 05/20/2017 04:17 PM, Vinnie Falco via Boost wrote: > >> I hope readers are convinced that HTTP requests and responses should >> be modeled as self-contained objects with all necessary fields >> prescribed by rfc7230, and that the HTTP status should be neither >> separate nor stored in an error_code. > > > Not really, but that is the subject for a review of a different library. Here's a nice new thread for the discussion.

1 0

[math] Chebyshev polynomial
by Bjorn Reese 20 May '17

20 May '17

Does Boost.Math contain functions for Chebyshev polynomials? Preferably a recurrent chebyshev_next(). I can find functions for Legendre, Laguerre, and Hermite polynomials, but not Chebyshev.

3 3

[review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by charleyb123 . 19 May '17

19 May '17

Hi Everyone, ** HEADS UP, NEXT WEEK ** The formal review of Niall Douglas' Outcome library starts next week (Fri-19-May to Sun-28-May). Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/ download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

14 92

[outcome] Fix with support for VS2017 Update 1
by Niall Douglas 19 May '17

19 May '17

Earlier today Vinnie Falco found that the peer review edition of Outcome does not compile on Visual Studio 2017 Update 1. I do apologise for this. Update 1 came out a few days before the peer review edition was set in stone. I didn't know it had until now, and I tested against VS2017 RTM, not Update 1. I have applied a fix to develop branch and cherry picked just this fix to the frozen master branch. You can find that fixed peer review edition at this branch: https://github.com/ned14/boost.outcome/tree/master_vs2017_fixed I hope that this does not inconvenience people too much, and once again, sorry. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 3

[offtopic] Who has the power to create Trac accounts nowadays?
by Niall Douglas 19 May '17

19 May '17

Sorry for asking boost-dev, but had no reply on boost-steering. I've got some new GSoC mentors wanting to contribute to https://svn.boost.org/trac/boost/wiki/SoC2017 but they need a Trac login to do so. Who has that power, and can they grant me the power to create Trac accounts as this comes up every year? I'm ned14 on Boost Trac. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

Any Projects that need significant contribution?
by GuillermoReyes 19 May '17

19 May '17

Hi all, My name is Guillermo - I am currently looking to significantly contribute to the boost library. In fact, I recently applied for gsoc17. I am willing to work on the nearly antipodal points issue (astroid problem), but am open to contributing to others as well. I have accepted an internship offer, so my time may be limited to part time work. I really want to contribute to the library :) Thanks Again, Sincerely, Guillermo Reyes -- View this message in context: http://boost.2283326.n4.nabble.com/Any-Projects-that-need-significant-contr… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[review] Review of PolyCollection is finished, thanks!
by Ion Gaztañaga 18 May '17

18 May '17

Hi, The review period for PolyCollection has come to an end. Thanks to all participants for submitting their reviews, and sharing their insights. All votes have been positive, so congratulations to Joaquín, PolyCollection will be accepted. I will collect all the suggestions, fixes and change proposals during this weekend and post an official result announcement in a few days. I encourage everyone to continue discussing further issues that can improve the library in the mailing list. Best, Ion, review manager

2 1

[dynamic_bitset] Comparison operators without assertions
by Pavel Kretov 18 May '17

18 May '17

Hi all. Looking through boost::dynamic_bitset code, I found a interesting inconsistency between its operator== and operator<. Namely, the first works well with bitsets of different size, while the second triggers an assertion: boost::dynamic_bitset<> a(std::string("111")), b(std::string("1110")); a == b; // false a < b; // Assertion `a.size() == b.size()' failed. This means that we cannot reliably use dynamic bitset within ordered containers like std::set or std::map. Since the standard library has distinct concepts of equality and equivalence (see [1]), it's fine to have different comparison behaviors in dynamic_bitset. However, as far as I can judge, equivalence is a metaphysically broader concept than equality, we shouldn't restrict it to bitsets of the same size only. So, the questions: 1. May I remove that assertion? (It won't be a breaking change, after all). 2. How about doing the same thing to bitwise operators, too? Instead of throwing an assertion if sizes don't match, it may be worth to generalize the operators definitions. I can see several possible schemes, but not all of them are consistent enough. 3. Shouldn't BOOST_ASSERT be used instead of the one from assert.h? ――― Pavel K. [1]: http://en.cppreference.com/w/cpp/concept/EqualityComparable

8 25