- Boost - lists.preview.boost.org

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

[Boost.Config] Should BOOST_FORCEINLINE depend on NDEBUG?
by dariomt＠gmail.com 29 Jan '20

29 Jan '20

Right now BOOST_FORCEINLINE does not depend on NDEBUG. This means that on Debug builds the code asks to be forced-inlined with optimizations disabled, which does not make much sense to me. This is reflected by a myriad warnings in msvc under level 4 warnings. In fact Multiprecision library works around this issue by defining their own macro BOOST_MP_FORCEINLINE which decays to just inline in Debug builds (boost/multiprecision/detail/number_base.hpp lines 25-29). I think this behavior should be adopted by BOOST_FORCEINLINE. I'm happy to do a PR if there is agreement from maintainers.

3 2

Re: [boost] Yet Another Container: DynamicArray
by Glen Fernandes 29 Jan '20

29 Jan '20

I wrote: > Yes quite. i.e. What you believe is not true about boost::allocate_unique. > > i.e. For auto p = boost::allocate_unique<T[]>(a, n); > assert(p.get().size() == n); > > This is because the unique_ptr stores a pointer adaptor around the > Allocator::pointer which also stores the size. > > So the pointer and size are stored together in the unique_ptr result. Note, that the size is only stored for allocate_unique<T[]>(a,n) but not for allocate_unique<T[N]>(a) since there the N is known at compile time. For auto p = allocate_unique<T[N]>(a); your p.get().size() will return N, but there's no need to store a size_t for N, so we don't. > To get the plain Allocator::pointer out of it you can use p.get().ptr() > > Or, for example, p.release().ptr() for someone who wants to manage > it themselves. Glen

1 0

New allocator that uses global memory
by Frederick Gotham 25 Jan '20

25 Jan '20

I propose a new allocator that uses global (i.e. static duration) memory. Here is my current experimental code: #include <cstddef> /* size_t */ #include <new> /* Only for bad_alloc */ static int this_translation_unit; /* This serves the same purpose as __FILE__ */ template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file = &this_translation_unit> class StaticAllocator { protected: static T buf[t_capacity]; public: typedef T value_type; template<typename U> struct rebind { typedef StaticAllocator<U, t_capacity, t_counter, t_file> other; }; T *allocate(std::size_t const n) { if (n > t_capacity) throw std::bad_alloc(); return buf; } void deallocate(T *, std::size_t) { /* Do Nothing */ } }; template<typename T, std::size_t t_capacity, std::size_t t_counter, int *t_file> T StaticAllocator<T, t_capacity, t_counter, t_file>::buf[t_capacity]; using std::size_t; #include <vector> using std::vector; #include <iostream> using std::cout; using std::endl; auto main(void) -> int { vector< char, StaticAllocator< char, 4, __COUNTER__ > > v; v.push_back('a'); v.push_back('b'); v.push_back('c'); v.push_back('d'); for (auto const &elem : v) cout << elem << endl; vector< char, StaticAllocator< char, 4, __COUNTER__ > > v2; v2.push_back('x'); v2.push_back('y'); v2.push_back('z'); for (auto const &elem : v2) cout << elem << endl; // Now try the first vector again for (auto const &elem : v) cout << elem << endl; } The trick I'm using with "this_translation_unit" compiles just fine on GNU and Clang, however it fails on Microsoft because the variable has internal linkage. I'm sure this can be done another way using Boost preprocessor stuff. The preprocessor macro "__COUNTER__" is available on every C++ compiler I know of. Frederick P.S. This is my second idea to the Boost development list. My first one is "istream_iterator_limited".

2 1

boost/asio/awaitable.hpp including <experimental/coroutine>
by Paps Olo 25 Jan '20

25 Jan '20

Hi, i've been trying to get the coroutine chat example to work, but it seems that in 1.72 and 1.71 boost/asio/awaitable.hpp does not compile when BOOST_ASIO_HAS_CO_AWAIT has been defined. Is there something i overlooked (i've been away from Linux development for some years...) or is boost really broken with this define? Which version should i try, or is there any sense in trying to fix this myself? Best regards papsolo

4 4

Re: [boost] dynamic_*<T>
by Glen Fernandes 24 Jan '20

24 Jan '20

Alexander wrote: > So if T[] and T[N] are valid, then T[N][M] should also be. This increases the scope greatly but has an incredible difficult questions to answer: What would operator[] return? I don't have a good answer... Simple questions that already have an answer: The same way shared_ptr<T[N][M]> works today. :) Its operator[] returns element_type& So: auto p = allocate_shared<int[5][1024]>(alloc); p[3][675] = 8; auto q = allocate_unique<double[][2][3][4]>(alloc, size); q[index][1][1][1] = 0.95; Then: dynamic<int[5][1024], Allocator> a(alloc); a[3][675] = 8; i.e. Making it work for T[N] also automatically makes it work for T[N][M]. Glen

2 1

[license] Boost license question
by Edward Diener 24 Jan '20

24 Jan '20

If some compiler vendor takes a version of Boost and makes changes to that version of Boost to suit the particular compiler, while distributing that version with full source code as an optional part of some release of that compiler, does this mean that the code is now proprietary for that compiler vendor ? Or does the code still remain open source so that a programmer can use the changes made to update his own version of a Boost release or provide PRs to some later release of Boost based on the code in the compiler vendor's release ?

4 6

[Boost][GSoC]New algorithm for multiplication
by Debajyoti Dasgupta 23 Jan '20

23 Jan '20

Sir/Ma'am, I am highly interested in working on the multiprecision big number types . I wanted to propose that since In the proposed project there is an increase in precision from 1000 to 10000 decimal digit , we can implement toom-cook algorithm instead of the standard karatsuba multiplication.Toom cook algorithm has a complexity of O(n^1.465) which is quite faster than karatsuba multiplication O(n^1.58). Please share your views on this. Thank you

2 2

Willing to take part in GSOC 2020 with Boost.
by Ram Nad 22 Jan '20

22 Jan '20

Dear Mentors, I am a second year undergraduate student from India. I would like to work with Boost.Multiprecision library. I have completed Programming competency test and would like to familiarise myself with the code base. It would be really helpful if you could guide me on where to start. Thanks You Ram Nad

2 1