January 2020 - Boost - lists.stage.boost.cppalliance.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

Optional library
by anshu khare 27 May '20

27 May '20

Hi mentors I was going through the optional library of boost. I was facing some problem in understanding the code base. In lines from 94 to 97 in optional.hpp, the code is as follows: struct in_place_init_if_t { Struct init_tag{}; explicit in_place_init_if_t(init_tag) {} //not able to understand this line }; I understand that we are creating a structure in_place_init_if_t and inside that we are creating another structure init_tag and then we are calling the constructor of in_place_init_if_t. But I am not able to understand that what does it the constructor do when we pass init_tag as an argument to it. Is it same as we are creating a structure Car and then creating another structure wheels inside it and passing wheels as an argument to the constructor of car as follows: struct car { Struct wheels{}; explicit car(wheels) {} //not able to understand this line }; Could you please tell what is the significance of passing wheels as an argument in this counter example?

2 1

binomial distribution setter function
by Kemin Zhou 18 Mar '20

18 Mar '20

This is my first time posting in this mailing list. Not sure how to post to the developer only mailing list after reading the document for mailing list for a good half an hour. If I posted in he wrong mailing please let me know and kindly provide the developer mailing list. I am looking at the binomial.hpp file. I need to use the binomial object in a loop which requires to have high performance. I am thinking constructing the binomial object each time in the loop would be less efficient than if I construct a single object, the each time reset the p parameter and use the object. I am not sure why the setter method was not provided. 296 RealType success_fraction() const 297 { // Probability. 298 return m_p; 299 } 300 void set_success_fraction(RealType p) { 301 m_p=p; 302 } Line 296 is the getter method, I added the setter method at line 300. -- Kemin Zhou 858 366 8260

4 4

[Boost.GIL] GSoC 2020 Project 1 - Seeking Mentor
by Ayush Bansal 01 Feb '20

01 Feb '20

Hi, I am a final year undergraduate student from IIT Khraragpur. I was interested in the project “Image Processing Algorithms” to be developed during GSoC 2020. I was mainly interested in implementation of Morphological IP Algorithms, Normalising channels and De-noising filters. I have a good knowledge about most of these algorithms and have worked with a lot of them as a part of my BTech Term Project. In addition to the list of algorithms provided for morphology, I had some other filters which I think could be implemented easily such as - Boundary Extraction, Hole Filling, Thinning and Thickening algorithms. Similarly, for de-noising filters, I was wondering if filters such as Conservative Smoothing, Adaptive Filters etc. could be added to the list. For my competency test, I was interested in doing the implementation of convolution filter and use it to detect edges. However, I did not understand where should I be posting my submission for the same. I have done my previous internship at Google India, where I implemented my code in Google’s Production server in C++, thus I also have the experience of writing good industry level code. I wanted to know if someone would be willing to mentor me for this project. Thanking you in advance. Regards Ayush Bansal Fifth Year Undergraduate Student Department of Computer Science and Engineering IIT Kharagpur

2 10

[Boost.Real] Testing Boost.Real in Visual Studio
by Jai . 30 Jan '20

30 Jan '20

Hi, I would like to contribute to the upcoming Real library. I have cloned the library at BoostGSoC19/Real. I wanted to ask whether it is possible to directly test the library in Visual Studio, or do I have to use CMake to build the project first? Thanks, Jai

4 5

URL library?
by Vinnie Falco 30 Jan '20

30 Jan '20

Is there any interest in a URL library for Boost? This is something that has been requested for a while now, and I've finally gotten around to it. Key features: * Construct a read-only url::view from a string_view * Construct a modifiable url::value from a string_view - Mutate the parts (e.g. set_scheme) - Set encoded or decoded strings: url::value u; u.set_username("Fr ed"); u.set_encoded_password("pass%20word"); - Retrieve encoded or decoded strings: u.username(); // returns decoded std::string u.encoded_password(); // returns encoded string_view For servers, execution paths are provided to avoid all dynamic allocation. For example to retrieve the decoded username: url::static_pool<4000> sp; std::cout << u.username( sp.allocator() ); The std::basic_string returned by username() uses the specified allocator. A server can handle URLs without allocating any memory. There's some punycode conversion routines but I haven't figured out if they should be part of the library, or how they would manifest as APIs (for international domain names). You can perform calculations with URLs using an Allocator (default to std::allocator<char>), or you can use a container with "static storage" (e.g. fixed_string): url::static_value<4000> u; // 4000 char capacity The library is here: <https://github.com/vinniefalco/url> This is still a work in progress, and I'm open to feedback that might help me make better remaining design choices. Thanks

8 23

Re: [boost] Yet Another Container: DynamicArray
by Gavin Lambert 29 Jan '20

29 Jan '20

At 19:02 29/01/2020, Glen Fernandes wrote: >You shouldn't expect that. For any unique_ptr<T, D> you can only >expect that .get() gives you a D::pointer. For default_delete<T> >this might be T*. But it always depends on the Deleter. That seems like a significantly more annoying interface than std::shared_ptr uses. shared_ptr can hold fancy pointers too, but it happens explicitly via using fancy<T> rather than plain T, so the explicit indirection on usage is obvious too. Having that be an implementation detail of the deleter changing the effective "type" of the first template argument (which is what people think of as the type of the pointer, even if the standard disagrees) seems quite annoying. Maybe we should have a type-erased unique ownership pointer as well. I know the reason why we didn't was to avoid heap allocation or wasted storage for the common case, but there ought to be some happy middle ground. >The correct way to get a raw pointer from any >potentially-fancy-pointer x is: to_address(x) > >This can be boost::to_address (C++03 or higher), or >std::to_address (C++20 or higher) Hmm. This is news to me; I don't think I've read about it anywhere in conjunction with unique_ptr. Perhaps since it doesn't actually exist yet (most compilers are still mostly C++17). But eg. <https://en.cppreference.com/w/cpp/memory/unique_ptr>https://en.cppreference.com/w/cpp/memory/unique_ptr appears entirely mute on the topic. (There's a passing reference to fancy pointers but even that doesn't talk about it.)

3 2

Re: [boost] unique_ptr<T, D> and D::pointer and fancy pointers
by Glen Fernandes 29 Jan '20

29 Jan '20

Gavin, in case my explanation in that earlier reply wasn't clear: Given std::unique_ptr<Foo, D> p; 1. Users know that *p and p->x do the right thing by Foo. 2. p.get() will get them a D::pointer. This D::pointer might be Foo*, or it might be offset_ptr<Foo> or it might be alloc_ptr<offset_ptr<Foo>> or any other pointer-like type. To get a Foo* out of p.get() regardless of which of the above three it returns, you can call: Foo* q = std::to_address(p.get()); // C++20 in std, C++03 in boost Or, if you know that p is not a null pointer, you can also use: if (p) { Foo* q = std::addressof(*p); // C++11 in std, C++03 in boost } std::unique_ptr<T, D> was always designed for this (since C++11). Because not all pointers we use are raw pointers. An Allocator::pointer might not be X*, it might be offset_ptr<X>, or it might be aligned_ptr<offset_ptr<X>>. This property of unique_ptr is also unrelated to allocate_unique (which just leverages this with a fancy-pointer around the Allocator::pointer which in turn might be a fancy-pointer). But even today, users are using unique_ptr with non-raw pointers (like Allocators where Allocator::pointer is offset_ptr<X> instead of X*). They don't assume that p.get() returns a raw X* pointer. This might be a lesser known property of unique_ptr to some (especially those that do not work much with custom allocators), but this is the way it has always been and intentionally so. Glen

1 0

Yet Another Container: DynamicArray
by Christian Mazakas 29 Jan '20

29 Jan '20

I've been working on an AllocatorAwareContainer called `dynamic_array` and was wondering if there'd be any interest in including it in Boost. First and foremost, a link to the source code: https://github.com/LeonineKing1199/sleip `dynamic_array` is a heap-allocated array that can't be resized (without entirely re-assigning it). It's useful in cases where you'd normally use `std::vector` but have no need of `push_back`, `emplace_back`, or any of the other size modifiers that the container supports. These kinds of arrays are typically useful in I/O applications which normally only accept a pointer-size pair to write out to. Naturally the question arises, "why use `dynamic_array` in the year 2020 when we have `std::vector` and `boost::allocate_unique`?". `std::vector` imposes a constant storage cost of pointer, size, and capacity. `dynamic_array` only stores a pointer and a size making it slimmer in use-cases where there's no need of a separation between size and capacity. `dynamic_array` also supports constructors `std::vector` doesn't have. For example, `dynamic_array` is constructible from a Range and has a `noinit` constructor. `dynamic_array` even supports array objects which gives it another advantage. `boost::allocate_unique` is a significantly tougher class to beat because it boasts many of the same features: a dynamic allocation done using the supplied Allocator supporting `noinit` construction and array objects with a size (stored in the Deleter of the returned `std::unique_ptr`). And while it is true that `boost::allocate_unique` enables all of this, it still lacks a few key semantics. Namely, `dynamic_array` is copyable. It's also copy assignable and move assignable, including the case where the underlying allocators do not use the same memory resource and will instead perform a piece-wise move of the elements. It's arguable whether or not `std::unique_ptr` should support similar semantics so in the interim, `dynamic_array` is the next best thing. - Chris

8 25