- Boost - lists.boost.org

Re: [boost] [variant2] Andrzej's review -- design
by Mike 08 Apr '19

08 Apr '19

> Going back to variant, in one case, we are defining an empty state, which > forces the user to provide explicit handling for that state, *everywhere*. You keep repeating that the user would have to explicitly handle that everywhere. I thought I just showed you that this is not the case. Except for visit, you don't have to explicitly handle the valueless state at all and even in the case of visit, you might be fine with std::visit just throwing an exception, because that is indeed an exceptional circumstance. I don't see this *everywhere* at all. Best Mike

8 18

[release] Master branch now completely closed for the 1.70.0 release
by Marshall Clow 08 Apr '19

08 Apr '19

The master branch is now closed for all changes except by permission for the release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_70_0.q… > Thanks, -- The Boost Release Team

4 7

Regarding Boost.Astronomy GSoC19 proposal review
by sarthak2007 07 Apr '19

07 Apr '19

Hello community, I am Sarthak Singhal, pursuing B.Tech in Computer Science from Indian Institute of Technology, Kanpur. I had submitted the programming competency test to mentor and also got a positive response from her. I had also submitted the project proposal to the mentor and based on her suggestions have improved it also. I have submitted the draft of the proposal to GSoC site. I request you to go through the proposal. I will appreciate your feedback to improve the proposal. Thank you, Sarthak Singhal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 4

[release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 07 Apr '19

07 Apr '19

The release candidates for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> The SHA256 checksums are as follows: 6e5cba1269225395bb5e78dda48441ccadaf745e42638180015e9e6257068336 ./boost_1_70_0_rc1.7z 35d8e1361e2063f70aa3a6ca0dd8af0877ceb75477ebbd2c726bb1d039658c7a ./boost_1_70_0_rc1.tar.bz2 ec8ddbbee2fd61e2f78a1dfe9a07ad83ca8f6a2f4c704d6f297d89c6afdc4f2c ./boost_1_70_0_rc1.tar.gz ee2c3b97ce10f85a31b6a105ad8edf1c20fb4b936c9a6e6008206059cb98ab1b ./boost_1_70_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

7 14

Re: [boost] [Boost-users] [release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 07 Apr '19

07 Apr '19

On Sat, Apr 6, 2019 at 10:53 AM Rainer Deyke via Boost-users < boost-users(a)lists.boost.org> wrote: > On 04.04.19 16:27, Marshall Clow via Boost-users wrote: > > As always, the release managers would appreciate it if you download > > the candidate of your choice and give building it a try. Please report > > both success and failure, and anything else that is noteworthy. > > boost::movelib::adaptive_merge continues to be broken if > iterator_traits<RandIt>::size_type != std::size_t. This breaks > boost::container::flat_map when cross-compiling for MacOS. I have > previously reported this error here. > > I consider this a critical error - as in, I won't be able to upgrade to > Boost 1.70 at all unless this error is fixed for the release. > This is https://github.com/boostorg/move/issues/25, correct? -- Marshall

1 0

[gsoc 19] Review of the proposal draft
by pranay gupta 07 Apr '19

07 Apr '19

Hi list, I have submitted the first draft of my proposal for implementing non-negative matrix factorisation in boost.ublas. It would be really helpful if you could please review it and suggest any improvements. Thanking you in advance. Sincerely, Pranay

2 3

Variant2 review
by Niall Douglas 07 Apr '19

07 Apr '19

I'll firstly apologise for the brevity of this review. It is just before the ACCU conference where I am speaking on a topic I have little knowledge of, and I have done almost no prep due to insufficient hours in the day. I am aware that if I don't make a review now, then I won't at all, so this will have to do. 1. Overall I like the library, it adds significant benefit (primarily removal of dynamic memory allocation) over Boost.Variant. 2. I don't like the lack of propagation of triviality of each individual special member functions. std::variant does this. std::expected does this. I can see Peter's point that for long lists of alternative states, implementing this is a lot of pain for almost no gain. However I do NOT agree with him for Expected. For a two-state variant, it is very highly likely that triviality of special member function will be very important for not a small number of use cases. I personally am happy for Variant2 to implement Expected without review approval here IF that Expected matches exactly std::expected. I am NOT happy if Variant2's Expected breaks conformance on triviality of special member function. If that is the only option on the table, then either please do not include an Expected implementation, or don't include Variant2. This raises a wider point though. What is good for a two-state variant still applies, though less so, to three-state variants, four-state variants and so on. I think there is a fundamental design issue here. If Variant2 can't propagate triviality of individual special member functions for small-number-of-state variants, then there is something fundamentally wrong here. 3. I find the design choice to randomly permute state to avoid an empty state baffling when there is a double buffer based design choice available. I do not like, one bit, the random permutation of state. I think it will lead to buggy code with hard-to-test corner cases. I think it needs to go away in the proposed design. I also don't get the dislike of the double buffer based design. Peter seems to really dislike it, and avoids it whenever possible. I can't understand why. If you can employ a double buffer design in order to eliminate random permutation of state, to me this is an unalloyed good in every way. Nowhere does it say that a variant must be no larger than the largest of its possible states. There is nothing wrong, *whatsoever*, with a variant which is sized the largest of its possible states multiplied by two. So please change the design to that instead. That should be the default design, and design claims. Programmers should write code assuming that design. IF it can be proven that a double buffer is unnecessary e.g. all alternative types are noexcept, a monostate alternative is available etc, THEN you can employ a single buffer implementation as an *optimisation*. That makes thing simple for the end user: add monostate, get single buffer sized. Otherwise assume double buffer sized. With a default double buffer design, most of the other issues which other reviewers have raised go away. Even Robert's concerns about assignment operators, with a double-buffer-by-default design one can always implement the strong guarantee. I badly need to depart, so I'll have to end there by saying that I vote to ACCEPT, conditional on (i) propagation of triviality of special member functions for at least small numbers of alternative states and (ii) removal of ANY POSSIBILITY of random permutation of chosen state under ANY circumstances. Finally, thanks Peter for bringing this library for review. Nice library. Niall

1 0

Proposal for GSoC'19 ( Random Points Generation)
by Mudit Agarwal 06 Apr '19

06 Apr '19

Hi I am submitting my first draft of the proposal for the project, Implementing algorithm for random point generation according to some given distribution in a geometry. I have also implemented competency test for the project https://github.com/Mudit-1999/Random_Points_Generation. It would be really helpful if you could please check if I have fulfilled all the points mentioned to pass competency test. Can you also please review my proposal and suggest any improvement. Hereby attach is my proposal. Thanking you in advance Regards, Mudit Agarwal

1 0

[review][variant2] Variant2 Review Starts April 1
by Michael Caisse 06 Apr '19

06 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> and the documentation here: <https://pdimov.github.io/variant2/doc/html/variant2.html> Please take an early look at the library and ask questions now. Peter Dimov is very active on the Cpplang Slack #boost channel; however, please consider using the Boost Dev or User Mail Lists so that the entire community might benefit from your conversation. Note: The repository contains an expected implementation also; however, that is not being considered in this review. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com

5 12

[gsoc19] looking for mentor
by Aziz Mousa 06 Apr '19

06 Apr '19

hi, I have my idea to contribute in boost project, I read the boost libraries list and see that the author of Algorithm is "Marshall Clow" I want to know how to contact with him to tell him about my idea. thanks.

1 0