- Boost - lists.boost.org

[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

To modularize, or not to modularize. What is the plan?
by Rene Rivera 10 May '19

10 May '19

Bringing this up because of the recent discussion in the 1.70.1 thread. And of course because this is the week that a certain BSC meets. Hence I thought I would clarify what I've meant my a modular Boost all this time. A modular Boost, to me, means a Boost that first and foremost a collection of independently consumable C++ libraries. That would have the following aspects to it: * An end user or library author can obtain a single Boost library of their choice and use it in their project, assuming they also obtain the appropriate dependencies of that library. * BoostOrg would not produce a monolithic, combined, merged, etc distribution. * BoostOrg would produce collectively tested milestone modular distributions. Sounds lovely right? ...I'll leave the discussion of merits to responses herein ;-) What would it take to reach that modular goal? Why do I keep saying we've been working on this for ages and ages? Briefly here's what it would take to get there (not in any particular order): * Abandon the single header include tree. * Abandon the monolithic build infrastructure. * Ban relative use of inter-library dependencies. * Explicit declaration of inter-library dependencies. * Strict normalized library layout. * Remove, and ban, dependency cycles at the inter-library user consumable granularity. There's probably more items that I've forgotten above. But this should be enough to converse about. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

14 63

[boost-ci][azp] Configuration for Azure Pipelines
by Mateusz Loskot 09 May '19

09 May '19

Hi, FYI, James approved and merge my submission of Azure Pipelines to the repository with common CI configuration templates. Here is the PR: https://github.com/boostorg/boost-ci/pull/16 The AzP configuration follows common conventions from the existing templates for Travis CI and AppVeyor, and steals from Boost.Build's azure-pipelines.yml crafted by Rene with a few pinches of AzP experience from Boost.GIL. The boost-ci README.md provides more details. Although James maintains boost-ci, he is neither able to test the AzP configuration (I tested it quite extensively myself) nor maintain it. If you will give it a go and notice any problems, please open new issues for boost-ci and I will do my best to help. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2

1 0

Introducing me, Sagnik Dey
by Sagnik Dey 08 May '19

08 May '19

Hello! I am pleased to announce that I will be working on the Boost.Real project as part of GSoC'19. Looking forward to a productive summer, producing quality code and getting to know the developer community better. Thank You, Sagnik Dey

1 0

Re: [boost] [doc][signals] Broken links for Boost 1.70
by Glen Fernandes 08 May '19

08 May '19

On 2019-04-15 at 21:46:18 Mateusz Loskot wrote: > On https://www.boost.org/doc/libs/1_70_0/ links to these documentations are broken: > > https://www.boost.org/doc/libs/1_70_0/libs/signals/ > > Could anyone help to identify what is going wrong with those and how to fix it? Signals was removed as a Boost library starting with in 1.69.0 and I had put a notice in the 1.69 release notes about this (section "Discontinued Libraries"). I've removed the links for Signals (v1) on the Libraries page going forward. e.g. https://www.boost.org/doc/libs/develop/libs/libraries.htm e.g. https://www.boost.org/doc/libs/develop/ Additionally, I've added an entry in the "Libraries Retired from Boost" on that first libraries page for Signals (v1) alongside compose. Glen

2 1

[any] ABI break
by Antony Polukhin 07 May '19

07 May '19

Hi, I'm planning to apply an ABI breaking change to the Boost.Any https://github.com/boostorg/any/pull/11 That PR makes the binaries that use boost::any smaller. For example libboost_program_options.so looses 4KB in size. Boost libraries were not guaranteeing ABI stability, but boost::any is quite often used across library boundaries. Double checking that there's no objections.

1 1

Lets do 1.70.1 WHO IS WITH ME!!!
by Vinnie Falco 06 May '19

06 May '19

A crashing defect in Beast was discovered shortly after release: <https://github.com/boostorg/beast/issues/1599> It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial: <https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8…> Thanks to the detailed report we were able to write a unit test which reproduces it reliably. Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect. Regards

8 19