February 2018 - Boost - lists.boost.org

We need more mentors for GSoC
by David Bellot 14 Feb '18

14 Feb '18

Hi Boost community, we have already a few mentors, but we need more. If you're interested working with top-level C++ students from all around the world, please contact me and I'll add you to the list of mentors. We need more mentors now ! Best regards, David

2 2

[gsoc-18] enhancing boost.intrusive library
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost Community. My name is Anurag Tangri. I am a 3rd year student at Thapar university patiala. I have good knowledge of C++ programming knowledge because of my competitive programming background. I am interested in “Enhancing Boost.Intrusive Library” project so i am a looking for mentor to guide me.

2 1

Yap review extended until Feb 19th
by Louis Dionne 14 Feb '18

14 Feb '18

Dear Boost community, The review of Zach Laine's Yap library was supposed to conclude today, Wednesday February 14th. To give more people the chance to review the library, and since there's no review scheduled directly after Yap, the review period will be extended until (and including) Monday February 19th. Thanks, Louis Dionne

1 0

[gsoc-18]
by Anurag Tangri 14 Feb '18

14 Feb '18

Hello Boost community ! My name is Anurag Tangri. I am a 3rd year undergrad at Thapar University. I am very much familiar with C++14 because of my competitive programming background.I have decent knowledge of Data structures and algorithms and eagerly want to contribute in open source. I am new to open source and stuff. So it would be very helpful if someone could guide me.

1 0

[release] 1.67.0 deadline for new libraries approaching
by Daniel James 14 Feb '18

14 Feb '18

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team

2 1

[release notes] Linking to github issues/pull requests
by Daniel James 14 Feb '18

14 Feb '18

Hi, I've added templates for linking to github issues and pull requests from the release notes. There are two templates: [github module number] which expands to '#number' [github_pr module number] which expands to 'PR#number'. Both will be linked, they need the name of the module to link to the right place. We only really need the issue template as github redirects to the pull request if appropriate, but existing release notes have been using the PR#3 format, so I thought it should support that. You can see an example in the unordered release notes for 1.67.0: https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q… http://www.boost.org/users/history/in_progress.html Does that look okay? Daniel

5 17

[yap] Review
by P F 14 Feb '18

14 Feb '18

- Whether you believe the library should be accepted into Boost I think it should be Accepted. - Your name Paul Fultz II - What is your evaluation of the library's: The design is very nice and simple to follow. I have found Proto to be a little hard for me to grep, but this seems fairly simple to follow. I think the transform -> evalute workflow is great. Also, with transforms being just function objects, it makes transformations very composable. I think this library is very useful. I would love to use this for some projects at work, but the dependency on Hana prevents that(I need to support gcc 5 and MSVC). Looking at the codebase, it could easily be replaced with Boost.Fit(once its included in the release) in the future. Of course, I dont expect a reimplementation without Hana as a condition for acceptance. However, I think Hana at least can be removed from the "interface". The expression elements could be expressed as a `std::tuple` and the placeholders could be a `std::integral_constant`. This should make it easier to use another backend without breaking API compatibility. Some other notes: - Couldn't the operator macros be provided as base classes? So instead of writing: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr { static const boost::yap::expr_kind kind = Kind; Tuple elements; // Member operator overloads for operator!(). BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr) }; The user could write: template <boost::yap::expr_kind Kind, typename Tuple> struct user_expr : logical_not<::user_expr> { static const boost::yap::expr_kind kind = Kind; Tuple elements; }; You could also get rid of the need for `::user_expr` by just taking it as a type and using something similiar to `mp_transform` to change the parameters. Or even change `Kind` to be a type of `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` could be used directly: template <typename Kind, typename Tuple> struct user_expr : logical_not<user_expr> { static const boost::yap::expr_kind kind = Kind{}; Tuple elements; }; - The customization points seem unnecessary. Why wouldn't the user just use `transform`? Using `transform` also keeps the customizations local. Also, implicit transformations seems like it would lead to suprises(and not good suprises). Are those on the cutting block? - It would be interesting to provide common transformations, like common subexpression elimination, or dead code elimination, but I guess that is beyond the scope of this library. - The `op_string` function is missing the case for `expr_ref` and `terminal`. Also, the tests only check for plus. - The `make_expr_from_tuple` does a move here: auto make_expr_from_tuple (ExprTemplate<Kind, OldTuple> const & expr, NewTuple && tuple) { return ExprTemplate<Kind, NewTuple>{std::move(tuple)}; } But maybe this should be using `std::forward`? - Did you attempt to use the library? If so: Yes, I ran it on clang 3.8 and gcc 7. - How much effort did you put into your evaluation of the review? Several hours

3 8

Regarding how to get selected for gsoc boost
by Syed Souban 13 Feb '18

13 Feb '18

Hi! I am Syed Souban. I am new to the world of open source and I want to contribute to it. I am a Computer Science And Engineering Undergraduate and I know C, C++, Java, Android App Development, HTML, CSS, JavaScript, PHP. I want some guidance on how should I start preparing to get selected for GSoC in your organisation.

2 1

[system] virtual ~error_category
by Peter Dimov 12 Feb '18

12 Feb '18

The virtual destructor of error_category creates problems for constexpr-ification because it makes the class non-literal. I can't think of a scenario in which we need the destructor to be virtual. It's probably virtual for "guideline" reasons - the class has virtual functions. But does it really need to be? Error categories aren't destroyed via a pointer to base. They are, in fact, static instances, not destroyed at all, except on program exit. Can anyone think of a case in which error_category needs the virtual destructor?

7 16

Boost C++ is a mentoring organization for GSoC'18 !
by David Bellot 12 Feb '18

12 Feb '18

We just received this message from Google. It says it all ! *Congratulations! Boost C++ Libraries has been selected as a Google Summer of Code 2018 mentor organization.* This year again, we will be a mentoring organization for the Google Summer of Code. If you want to be a mentor, please contact me right now and register on the Google Summer of Code website too. Best regards, David

1 0