December 2019 - Boost - lists.boost.org

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them.

1 0

(no subject)
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them. Glen

1 0

[config][build] Doc missing in 1.72
by Edward Diener 24 Dec '19

24 Dec '19

In the 1.72 distribution the documentation for config and build are missing.

3 5

[review][fixed_string] FixedString review results
by Joaquin M López Muñoz 22 Dec '19

22 Dec '19

These are the results of the candidate Boost.FixedString review. Thanks to all the people (and there's been many) who contributed. To clear up the tension, let me begin by announcing that: Candidate Boost.FixedString is ACCEPTED into Boost. Acceptance is subject to the authors' addressing of some issues raised during the review that I label as "priority 1" below. *Summary of reviews* We've had 10 full reviews: * Accept: Deniz Bahadir, Emil Dotchevski, Gavin Lambert, JeanHeyd Meneide, Paul A. Bristow, Peter Dimov, Peter Koch Larsen. * Conditionally accept: Zach Laine. * Reject: Andrzej Krzemienski, Phil Endecott. Zach's conditions to acceptance seem minor and easily addressable to me. Andrzej based his rejection on a perceived lack of clarity as to what the actual pitch of the library is, which ultimately boils down to the issue of throwing/asserting on capacity overflow: my impression is that a strong pitch, if not a universally acclaimed one, emerged during discussions. Finally, Phil voted to reject but then went on to state that he would accept based on a number of "minimally sufficient" conditions that are trivial to meet (or even have been already implemented by Krystian). All in all, I think it is a reasonable compromise to grant acceptance based on the resolution of a number of important issues, listed below. *Issues* I've classified issues in three different priorities: * Priority 1: to be solved *before* inclusion into Boost. * Priority 2: to be addressed somewhere in the future. * Priority 3: anecdotal or without clear support from the community, to be addressed at the authors's discretion. * Priority 1 issues* 1. CMakeLists.txt should either be made generic or removed from repo (it is currently a specific thing for Visual Studio). 2. Choose a name for the component. Some consensus arose that naming should follow std::string's and be of the form basic_foo<...> with aliases foo, wfoo, etc. As for "foo", the following candidates have been proposed: * static_string * fixed_capacity_string * array_string * static_capacity_string * inplace_string * capped_string * bounded_capacity_string * bounded_string To be clear, I don't think any of these is clearly more popular than the rest, so it is up to the authors to make up their mind. 3. constexpr as much as possible, taking into account that, pre C++20, this requires zero initialization of the data array. 4. noexcept as much as possible and, in principle, at least as much as std::string. 5. Provide hash overloads. Up to the authors if they want to cover Boost.Hash as well. 6. Determine the exact behavior on capacity overflow. I think *some* partial consensus arose around throwing via boost::throw_exception so as to provide an opt-out mechanism for exception-handicapped scenarios. This has been the most contentious issue during the review but I think the authors are in their right to decide on throwing much as anyone can decide otherwise and propose what would be basically a different library. 7. Make substr return a fixed_string rather than a view, and additionally provide a view-returning subview member function. 8. State clearly on the docs what C++ version is required. 9 There are wrong "size() + m > max_size()" checks (they could overflow) in the code. 10. to_fixed_string should be a set of overloads mathing those of std::string. 11. There's an issue around some detail::is_input_iterator alias that Zach asked be clarified. 12. Compile-fail tests should be added to verify that those functions with constraints are correctly constrained. *Priority 2* 13. Determine if fixed_string<0> should be specialized or not to make it more memory efficient. This raises potential issues in the uniqueness of the pointer returned by data(). 14. Determine if operator+(fixed_string,fixed_string) should be provided. My impression is that people generally wanted this, and I've been tempted to raise this to priority 1. 15. Optimize the type of the internal size data member when size_t is larger than necessary. 16. BOOST_FIXED_STRING_USE_BOOST is unconditionally defined within the code. The authors should clearly state what this is for and let the user configure the library to use with/without Boost or, else, remove the thing entirely. 17. Source code organization (three equally named files, detal and impl folders), raised some eyebrows. Some (including Vinnie) favor a single-file implementation. 18. Docs should be more C++ standard-like and provide a synopsis. Vinnie has indicated they may abandon Doxygen in favor of asciidoc to produce better-quality docs. In general, people were not enthusiastic about the documentation. 19. The current monolithic test should be split up in lighter, more manegeable test files. Peter Dimov suggested some additional improvements on the testing part. * Priority 3* 20. Provide a literal operator"" 21. Should traits parameter be removed? 22. Store size (as capacity-size) in the last char of the data array, so as to save one memory byte. This might affect performance, though. 23. Add functions for checking remaining capacity. Thanks to Krystian and Vinnie for their work! And to everybody who has contributed to this really interesting review. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

7 12

[gsoc2020] New here
by Siddhant Jain 22 Dec '19

22 Dec '19

Hi, my name is Siddhant I am a first year CS student at IIIT Hyderabad. I am interested in learning more about and contributing to boost. I have visited the obvious beginners links but I am unable to grasp the library to the level where I can contribute code. What would be the suggest plan of action to get comfortable with reading and write code used in boost. I am interested in working on Boost.geometry and/or Boost.real. Thanks

1 0

[move][core] boost::swap() vs boost::adl_move_swap()
by Andrzej Krzemienski 21 Dec '19

21 Dec '19

Hi Everyone, I am seeking an advice. I recently got this pull request: https://github.com/boostorg/optional/pull/77 changing the boost::swap() to boost::adl_move_swap() because it should compile faster. Is there any recommendation for Boost libraries which one to prefer and under what circumstances? boost::adl_move_swap() seems to allow moves rather than copies in more cases. On the other hand boost::swap() seems to have other improvements, like BOOST_GPU_ENABLED. Regards, &rzej;

2 1

boost::python::def_visitor alignment / padding crash.
by Janek Kozicki 20 Dec '19

20 Dec '19

I have discovered an alignment related bug in boost::python::def_visitor For a very detailed description see https://gitlab.com/libeigen/eigen/issues/1795 * a minimal failing example: https://gitlab.com/cosurgi/minieigen-real/blob/minimalFailingExample/src/mi… * and the failing CI pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/104745741 Initially I thought that it was related with libeigen. But it turns out that it crashes even without libeigen, when just using boost::multiprecision::float128. The code crashes with g++ 8.3.0 and works with g++ 9.2.1 boost version 1.67 is used there. should I open an issue on boost github? best regards -- # Janek Kozicki http://janek.kozicki.pl/

1 1

[appveyor] Really slow turnover
by Edward Diener 20 Dec '19

20 Dec '19

When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt. Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?

7 18

[review][STLInterfaces] review extended to Dec. 23
by Barrett Adair 20 Dec '19

20 Dec '19

The formal review of STLInterfaces is extended to December 23. Please consider submitting a review if you can.

1 0

Re: [boost] Jason is getting MARRIED!
by Bjorn Reese 20 Dec '19

20 Dec '19

On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote: > My JSON library is going to propose to Boost soon, is there anyone who > might be willing and able to function in the role of review manager? Before we get to that point, there are some questions that the community should address. These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer? Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms? Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree? PS: On a procedural note, you need an endorsement of the library before seeking a review manager.

10 68