- Boost - lists.boost.org

[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

[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