- Boost - lists.boost.org

[config] Disabling symbol visibility?
by John Maddock 19 May '19

19 May '19

We have an open ticket from someone that wants all symbols hidden, including those marked with BOOST_SYMBOL_VISIBLE, is this sensible to support? What are the likely consequences of doing so? See https://github.com/boostorg/config/issues/243 Thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

[gsoc19] Introduction
by Thomas Ferrand 18 May '19

18 May '19

Hello everyone, I am Thomas Ferrand a french student in computer science and I am happy to take part in GSoC this summer. I will be working on Boost.SafeFloat (https://github.com/sdavtaker/safefloat) a library that aims at helping developers detecting errors in floating point numbers computations. Best regards, Thomas Ferrand

3 2

[GSoC19] Greetings
by Kim 18 May '19

18 May '19

Hello, Another student and I will be contributing to the proposed Boost library, Real, with mentors Damian Vicino and Laouen Belloli. My name is Kimberly Swanson. I am a mathematics undergrad at University of Central Florida. My primary focus during the summer will be to improve the memory complexity of Real's internal representation. After the main changes, I plan to implement benchmarks with Google Benchmark (though I am open to using other libraries, if recommended). Future changes made regarding memory/computational complexity would refer to results from the benchmark. I aim to get it to a review-ready state before the end of GSoC (fingers crossed). Warm Regards, Kim

2 1

[variant2] Acceptance conditions met - Targeted for 1.71.0
by Michael Caisse 17 May '19

17 May '19

Peter Dimov has updated the Variant2 library based on review acceptance criteria. I have reviewed the changes and "OK" Variant2 to be included as a Boost library. My understanding is that Peter is targeting Variant2 to be available in the 1.71.0 release. Congratulations Peter! Thank you for your quick work in updating the library based on the review feedback. -- Michael Caisse Ciere Consulting ciere.com

2 1

Need help setting up Travis CI and codecov
by Sagnik Dey 15 May '19

15 May '19

We are getting ready to start work on the Boost.Real project and getting Travis CI and codecov integration for the new repository https://github.com/BoostGSoC19/Real, would be a great help. Can someone please provide some help as to how to set it up? The yml files for both travis and codecov are already present in the repo as this is a fork from an older repo that had a working travis and codecov integration. Thank You, Sagnik Dey

2 1

[GSOC19] Introduction
by Ashar 15 May '19

15 May '19

Hi, My name is Mohammad Ashar Khan, I will be working on uBLAS to bring better expression templates support using boost.YAP. I will also be adding support for expression optimization using mathematical laws. Regards Mohammad Ashar Khan

1 0

[Real] [GSoC19] Working together on Real
by Kim 15 May '19

15 May '19

Hello, Sagnik Dey and I, both GSoC19 students, will work together on Real. Laouen Belloli suggested we reach out to the dev list regarding how we will work with the BoostGSoC19/Real repo. Should we 1. work on the same repo using different branches, or 2. each make a fork of the repo We have some overlapping tasks from our GSoC proposals, and plan on possibly implementing different implementations for some thing(s), while dividing up the tasks between ourselves for others. Further, we would like to get Travis CI and codecov in the respective repo(s), but we need to know which option we're going with first. Best Regards, Kim

1 0

[GSOC19] Introduction
by Amit Singh 15 May '19

15 May '19

Hello everyone, My name is Amit Singh. I will be contributing to ublas tensor this summer. My goal is to improve the design and integrating new features to tensor. Best Regards Amit Singh

1 0

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 12 May '19

12 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > out_ptr is a small abstraction for making types such as > std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming > std::retain_ptr > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work > work C-Style output functions as a parameter, addressing the need of > wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's Does out_ptr have other use-cases than C interoperability?

7 14

[variant2] Review Results
by Michael Caisse 11 May '19

11 May '19

First, I would like to apologize to Peter and the those who took time to review Boost.Variant2 for the slow turn-around of a result. Thank you Peter for producing and submitting such a high-quality library for review. The code has been a pleasure to read and review. Thank you to the reviewers! Your participation in the process is what makes Boost libraries high-quality. I personally appreciate the time and effort that each of you have put into this review. ------------- Result ------------- Boost.Variant2 will be ACCEPTED after the following changes are made. An additional review will not be required. - The library will implement the strong guarantee: - If all alternatives have nothrow move, single buffer - else, double buffer - Improved documentation: - Addition of a tutorial - Addition of design motivation - Peter has indicated that triviality propagation will come in a future version. The initial Boost release need not support triviality propagation. - Expected will not be included but may be submitted for review at another time. ---------------- Review Verdicts ---------------- The following people provided reviews. Reject ---------- Andrezj Krzemienski Antony Polukhin Jan Herrmann Accept ---------- Emil Dotchevski Gavin Lambert Phil Endecott Conditionally Accept -------- Bjorn Reese Andrey Semashev Damian Jarek Niall Douglas Andrezj and Antony’s rejections were based on not having a valueless-by-exception state. Neither saw the selected design space worth considering and each believed the trade-off was dangerous for users. The Conditional Acceptance reviews voiced the following: - Strong preference for the strong guarantee (and therefore no need to provide “surprising” behaviour for the state after an exception.) - Improved documentation containing both tutorial and motivation sections. - Triviality propagation of the variant types. - Accepted without expected being contained. -------------- Some Thoughts -------------- There was a good amount of healthy discussion on the Developer Mail List concerning Variant2. I want to thank all of the participants for engaging with civility and keeping to the technical merits despite the galvanized opinions concerning valueless-by-exception and the basic exception guarantee. Over the past couple weeks I have re-read all of the discussion threads 3 or 4 times. While some people didn’t find value in the exchanges, this level of engagement about design trade-offs is one of the attributes that sets Boost reviews apart. They are not merely reviews discussing the quality of implementation but also the intricacies of design choices within the constraints and consistency of the language. When reviewers articulate their opinions the entire community learns and grows. The trade-offs that Peter made seem dangerous to some yet the exact correct formulation for others. There are even standard library implementers that don’t agree with std::variant’s valueless-by-exception. A high-quality variant that provides the strong exception guarantee is a type that has been missing from the programmer toolbox. Variant2 provides this. I will make an additional announcement to the community when the conditions for acceptance have been met. Thank you all for making Boost better! michael -- Michael Caisse Ciere Consulting ciere.com

7 6