- Boost - lists.preview.boost.org

GSoC 2020 application
by David Bellot 10 Feb '20

10 Feb '20

Hi Boost community, just to let you know that our application to Google Summer of Code 2020 has been submitted. Let's hope for the best now. To all potential mentors, please keep adding projects if you are willing to participate. It's a great program with great benefits for our Boost community. Best regards, David

3 2

[Boost Real] GSoC 2020 - Introduction
by Chirag Thakur 10 Feb '20

10 Feb '20

Hi everyone. My name is Chirag Thakur and I'm a newcomer to the Boost community. I want to contribute to Boost.Real. I have been an active participator in programming contests like ACM-ICPC and other online judges over the last two years and have good proficiency in C++. I want to get involved using Google Summer of Code 2020. How can I start? Regards Chirag Thakur

2 1

[Boost Graph Library] Possible succint data structure addition
by Joana Modesto Hrotko 09 Feb '20

09 Feb '20

Dear Boost community, I am a Master's student and currently working on my Master thesis. My Master Thesis consists in implementing the k2-tree data structure in C++ and one of the additional proposals for my thesis would be to integrate my code with the boost graph library.I believe this integration would bring great value to the boost library and also it would provide a better validation for my work. So my question is if this would be something of interest for the library to integrate with boost graph library. INFO ABOUT K2-TREE: The k2-tree have been proved successful to represent in a very compact way different kinds of binary relations, such as web graphs, RDFs or raster data. Binary relations can be an abstraction to represent the relation between the objects of two collections of different nature: graphs, trees, strings, among others. They can be used in several low-level structures within a more complex information retrieval system, or even replace one of the most used one: an inverted index can be regarded as a binary relation between the vocabulary of terms and the documents where they appear. Moreover, it can represent the relation between terms and web pages, or even social networks or the connection between the web pages in the Web, which is normally represented as a web graph. k2-trees have been also used in other scenarios, such as geographical and RDF data, or images. Brisaboa, Nieves R., et al. "Compressed representation of dynamic binary relations with applications." Information Systems 69 (2017): 106-123. Coimbra, Miguel E., et al. "On dynamic succinct graph representations." arXiv preprint arXiv:1911.03195 (2019). Thank you in advance for your attention Best regards, Joana Hrotkó

3 4

[graph] State of the README
by Mateusz Loskot 09 Feb '20

09 Feb '20

Hi, Today's post [1] about feature suggestion for the BGL made me browse a bit and noticed this curious notes in the README [2] "Bugs and feature requests can be reported through the Trac issue tracker (...) Here [3] is why Trac is still in use." Is this information up to date? Last (substantial) change to the README.md happened in 2016. The Trac use rationale linked [3] from the readme is from 2015. [1] https://lists.boost.org/Archives/boost/2020/02/248164.php [2] https://github.com/boostorg/graph/blob/develop/README.md [3] https://lists.boost.org/Archives/boost/2015/04/221780.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 4

[Boost.GIL] GSoC 2020 - FFT implementation
by deb 06 Feb '20

06 Feb '20

Hi, I am a third year undergrad from IIT Bombay. I am interested in PROJECT 1: Image Processing Algorithms for BOOST.GIL . I have gone through the Getting started with Boost, Modular Boost Overview and Contributing page(on git repository for boost.gil) to get a fair idea of how Boost works. I went over the boost Gil library looking for an implementation of FFT(Fast Fourier transform) but could not find one . Since it is listed as a suggested project topic for the GSoC 2020 , I was hoping to implement it as part of my GSoC competency test. I have a few questions though:- a. Should I try and implement 1D-DFT(using FFT) independent from 2D-DFT (which is the more popular among image processing algorithms) ? b. Should I submit the above mentioned algorithms as separate PRs or as a single one? I am choosing FFT over other topics since it is an essential part of many image processing algorithms like Wiener filters, tomographic reconstructions etc. I have worked with image processing algorithms before on college projects and I think that I will be able to pull it off as a GSoC competency test. Thank You. Debabrata Mandal CSE undergrad, IIT Bombay -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

6 11

Boost_VERSION widely different between old CMake and new CMake find_package
by Dimitri John Ledkov 05 Feb '20

05 Feb '20

I have the following CMakeLists.txt: project(Boost CXX) cmake_minimum_required(VERSION 3.0) FIND_PACKAGE(Boost COMPONENTS filesystem REQUIRED) message( ${Boost_VERSION} ) In Ubuntu 18.04 LTS (Bionic) this produces: cmake ../ -- The CXX compiler identification is GNU 7.4.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Boost version: 1.65.1 -- Found the following Boost libraries: -- filesystem -- system 106501 -- Configuring done -- Generating done -- Build files have been written to: /root/foo/build As in Boost_VERSION is set to 106501 In Ubuntu 20.04 LTS (Focal, devel release) which uses boost 1.71 with boost cmake files: -- The CXX compiler identification is GNU 9.2.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: filesystem 1.71.0 -- Configuring done -- Generating done -- Build files have been written to: /home/xnox/canonical/boost/debian/tests/srcs/filesystem/foo As in Boost_VERSION is set to 1.71.0 Now, lot of projects have Boost version comparison already and 1.71.0 is less than 106501. This creates problems for example when trying to detect and use new-style pythonXY components, filesystem v3 api, etc. For example I found in Ubuntu packages stanzas like: if (${Boost_VERSION} LESS 104400) Can we please fix Boost_VERSION in the new-style cmake to be compatible / same / similar / higher than the old Boost_VERSION string? -- Regards, Dimitri.

2 2

[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

[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

Anyone got AT commands work using asio serial port?
by JH 22 Jan '20

22 Jan '20

Hi, There are many boost serial port sample code out there, but none of them I can run AT command. I have a device connected to my ubuntu 18, I can run AT command on minicom to get correct response, but I could not get any AT response from boost serial port. Has anyone made it work? Thank you. Kind regards, - jh

5 11

New Boost Review Wizard: Mateusz Loskot
by Glen Fernandes 20 Jan '20

20 Jan '20

Our thanks to Mateusz for agreeing to help Boost with the formal review process. https://www.boost.org/community/reviews.html has been updated to say: > The role of Boost Review Wizard is currently played by: > * Mateusz Loskot (mateusz at loskot dot net) > * John Phillips (johnphillipsithaca at gmail dot com) > > Past Review Wizards (we thank you for your service): > * Ronald Garcia Glen

2 1

Optional library
by anshu khare 19 Jan '20

19 Jan '20

Hi I ran the following code: const std::string i = "some string"; boost::optional<const std::string&> str = i; cout << get_optional_value_or(str, "some other string") ; It gives the output as : some string Which is absolutely fine. But when I run const std::string i = {}; boost::optional<const std::string&> str = i; cout << get_optional_value_or(str, "some other string") ; The output is an empty string. Shouldn't it give "some other string as output" because if I run the same code with integer it gives the second parameter of get_optional_value_or() as output?

2 5

New Boost Review Wizard: Volunteers
by Glen Fernandes 18 Jan '20

18 Jan '20

We need a new Review Wizard to take Ron's place. The duties include coordinating with review managers, scheduling reviews, and updating the website accordingly. Or as https://www.boost.org/community/reviews.html#Wizard puts it: > * When a formal review is requested for a library: > ** Approve the review manager based on their participation in the Boost community, including the mailing list, previous reviews, and other forums. > ** Suggest a schedule, after checking (via private email) availability of the review manager and library author. > ** Finalize the schedule, once the review manager verifies the library is actually ready for review. > ** Resolve schedule slips or other issues with review managers and submitters. > * Maintains a schedule of both past and pending reviews, in the form of the Review Schedule web page. > * Resolves questions from review managers and library submitters, who sometimes want a third opinion on questions such as "Should we extend the review period because ...?" > * Monitors the general review process, and makes minor adjustments as needed, or queries the list about possible major adjustments. When we appoint the new Review Wizard, I can grant them access to boostorg/website and provide more details about how to update it. We would like someone who is a Boost library author or contributor if possible. Any takers? Glen

3 3

GSoC 2020 and Boost C++
by David Bellot 18 Jan '20

18 Jan '20

Hi Boost community, Boost C++ will apply again this year to be a mentoring organization for the Google Summer of Code. We are seeking mentors with good projects to join us and have the chance to mentor students from all around the world and contribute code to one of the Boost library. Applications for organization open tomorrow and are open until February 5th. We will apply as usual. In the meantime, help me and propose new projects, declare yourself as a potential mentors on the Boost mailing list and start editing the page at https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-2020 with your own project. Best regards, David

1 0

Potential Mentor's Interest in Boost GSoC2020
by Christopher Kormanyos 17 Jan '20

17 Jan '20

Dear Boost, A generic reminder that org applications GSoC 2020has reached me in another forum yesterday. I'm not the organizer of this, but a potential mentor.Do other potential mentors have suitable projectsand interest in mentoring? Based on previous years,interest this year seems less strong. But the timeto get involved is upon us. I posted one of my potential projects here: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code:-2020 ...And it has remained alone for almost 1 week. Best regards, Chris

4 4

Extension of math/complex library
by anshu khare 17 Jan '20

17 Jan '20

Hi mentors, I would like extend math/complex library in which the user will be able to compute roots of equation like z^n - a =0 where n,a € R+. Example : z^4 - 1 = 0 Anshu

1 0

(no subject)
by anshu khare 17 Jan '20

17 Jan '20

I verified it when I ran Cout<<fixed<<setprecision(20) << cos(7*pi/2) << endl; The output of the above line came out to be -0.000 In the earlier code when the output came as -1. 06911e - 50, I thought it to be like (-50) + (-1. 06911e ) which seemed a highly negative value to me.

1 0

Incorrect values of sin and cos
by anshu khare 17 Jan '20

17 Jan '20

cos(3*pi(cpp_bin_float_50>()/2)) does not give correct value. Only cos(pi(cpp_bin_float_50>()/2)) gives correct value. All odd multiples of cos(pi/2) do not give correct value. The issue with sin() as well. Anshu

4 7

Future directions for Boost.Math and Boost.Multiprecision
by pbristow＠hetp.u-net.com 16 Jan '20

16 Jan '20

Trying to obtain some user (and potential user) feedback, and guidance on future work, a discussion at https://github.com/boostorg/math/issues/303 has been started. If you (or your friends and colleagues) have ideas for mathy things like 'special' functions, statistical distributions, tools like integration, curve fitting, signal processing ... that the current libraries do not meet, please feel free to contribute to this wish-list collection of ideas. (This is not, of course, a promise to implement everything or indeed anything! But might help us to focus work on areas that have most value to users.) Paul

3 2

Worked on issue 49
by anshu khare 16 Jan '20

16 Jan '20

Hi I have worked on issue 49 of core library. Should I pull a request regarding the same?

3 2

(no subject)
by anshu khare 16 Jan '20

16 Jan '20

cos(3*pi(cpp_bin_float_50>()/2)) does not give correct value.

1 0

Contribution to core library
by anshu khare 13 Jan '20

13 Jan '20

Hello mentors, I would like to contribute to the core library of BOOST. I am working on windows. I cloned boostorg/core library. After cloning I found that there are many folders. Could you please tell which folder should I look up? Thank you Anshu Khare

4 5

Documentation of dynamic cast
by anshu khare 11 Jan '20

11 Jan '20

Hello mentors, Could you please provide the documentation and code of dynamic_cast?

2 1

[Astronomy] GSoC2020
by Pranam Lashkari 10 Jan '20

10 Jan '20

Hello, Earlier I was thinking of resting astronomy library for this GSoC and bring it to its first formal review after some development on my own cause it has been part of GSoC for 2 years now and still not reached to its first review and there are still many pending things before its first review. Since last month, I have started receiving many requests and ideas from the students about this library and many students are taking initiative and this may speed up the process of development. I still would like to know the opinion of the community before including this library in this GSoC. Thank you, Pranam Lashkari

3 2

boost range for non integers
by Wim Leflere 10 Jan '20

10 Jan '20

Hello, I was wondering why the (i)range function is limited to integers. https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/range/reference/r… It would be nice if it also supported floats. Or any 'incrementable' class, e.g. Date. Regards, Wim Leflere

2 2

New allocator uses global memory
by Frederick Gotham 10 Jan '20

10 Jan '20

I propose a new allocator that uses global (i.e. static duration) memory. Here's 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 am using with "this_translation_unit" works fine on GNU and Clang, however it fails to compile on Microsoft because the variable has internal linkage. I'm sure we can do this another way using something from the Boost preprocessor library. The preprocessor macro __COUNTER__ is available on every compiler I know of. Frederick P.S. This is my second idea posted to the Boost dev list. My first one was "istream_iterator_limited".

3 2

Willing to participate in GSOC'20 with boost
by soham mukherjee 10 Jan '20

10 Jan '20

Hi, I am Soham Mukherjee. I am willing to participate in GSOC-20 and was looking forward participating with this organization. Can someone please guide me on how to get started and linking me to some easy fixes and also documentations so that I can familiarize myself with the codebase. Thanks

4 5

Clone warnings in lexical_cast
by Tom Kent 09 Jan '20

09 Jan '20

I just ran a: git clone --recursive https://github.com/boostorg/boost boost_root and I got some warnings in lexical_cast: Cloning into 'D:/teeks99-09/boost_root/libs/lambda'... Cloning into 'D:/teeks99-09/boost_root/libs/lexical_cast'... warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/b1/102161720ea50668a5756828409400a4314744.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/8a/0a6c194259a9a3fa24ea3fb815899bfcbfed64.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/47/dd68ef6ee5c02257a57d03ac9e611a68893d0d.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/02/b86ef5bcc4574e5c03b75ed463dbb5ada446c9.temp': Invalid argument warning: unable to unlink 'D:/teeks99-09/boost_root/.git/modules/lexical_cast/objects/c2/b4875ef060ea7de75feceb1f20284766128325.temp': Invalid argument Cloning into 'D:/teeks99-09/boost_root/libs/local_function'... I don't think these are an issue necessarily but it might be something that can be cleaned up. Tom

2 1

[Graph] Large incoming changes to Boost.Graph master.
by John Maddock 08 Jan '20

08 Jan '20

Dear all, Boost.Graph has had no maintainer for some time, but the CMT has been busy fixing bugs none the less. Unfortunately, other than some trivial fixes to docs and some directory refactoring, nothing much has been merged to master in a good while . On the plus side, develop is now in a better tested tested state than IMO it has ever been, however the change set is rather large so the potential to mess up somebodies code is certainly there: https://github.com/boostorg/graph/pull/196. So... this is both a heads up, and a plea: if you have any mission critical code using the Graph library, could you please test against current develop and report any problems? If you don't want to mess about with git, download from https://github.com/boostorg/graph/archive/develop.zip and place zipfile-contents/libs/graph/include in your include path ahead of that for Boost-1.72. Many thanks, John.

1 0

What happened to Boost.Nowide?
by Alexander Grund 08 Jan '20

08 Jan '20

Hi, I'm a user of (a fork of) Boost.Nowide and already fixed some issues I found and was looking into getting them upstream. I also wanted to know, if it is finally in Boost. Unfortunately this does not seem to be the case. I found https://lists.boost.org/Archives/boost//2017/06/236475.php which accepted it into Boost. This is from mid-2017 and nothing has happened since. Does anyone know what the status of Boost.Nowide is? It seems the filestream parts are now incorporated into Boost.FileSystem. So it seems only cin/cout/cerr, the args wrapper and the C-functions (fopen, ...) are missing. Especially the first 2 are very useful in writing cross-platform code. Might those be integrated into some other Boost Library? Thanks, Alex

4 16

Retirement as Review Wizard
by Ronald Garcia 07 Jan '20

07 Jan '20

Dear Boosters and Boost Steering Committee, After roughly 14 years as a Boost Co-Review Wizard, I feel that the time has come for me to step down from the position, and make room for a new face with fresh ideas. It has been my pleasure to serve in this position for this time alongside first Tom Brinkman and now John Phillips. I look forward to seeing what the next 14+ years of Boost brings! Sincerely, Ron Garcia Boost Co-Review Wizard

8 7

Query on Project Multiprecision/Math GSoC 2020
by Christopher Kormanyos 06 Jan '20

06 Jan '20

Dear Boost Is there a place to post and describe a potentialGSoC 2020 project? We have a potential project for GSoC 2020. It involvessignificantly extending the precision of Boost.Multiprecisionand harmonizing these extensions and tests with Boost.Math.I have the proposal worked out in plain text and would liketo post it or share it. We have discussed this project (in PM) with the knownrecent authors and maintainers of Multiprecision and Math,and interest is strong. On a personal note, my name isChristopher Kormanyos, previous three-time Boost GSoCmentor. In previous years, I have also contributed to bothMath and Multiprecision. Thank you and kind regards, Chris

1 0

Re: [boost] Recommended way of generating documentation
by pbristow＠hetp.u-net.com 06 Jan '20

06 Jan '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Richard Hodges via > Boost > Sent: 1 January 2020 12:03 > To: boost(a)lists.boost.org List <boost(a)lists.boost.org> > Cc: Richard Hodges <hodges.r(a)gmail.com> > Subject: Re: [boost] Recomended way of generating documentation > > Treading carefully here as I'm new to boost library maintenance... > > > So that you can cross-reference the Doxygen reference with whatever > > other > documentation you have > > http://www.doxygen.nl/manual/autolink.html suggests that links to external URLs > are recognised by doxygen. Presumably linking to the correct place vis-a-vis > release/developer builds can be controlled with a macro in a generated Doxyfile? > > > And it's Doxygen to XML, XML to Boostbook. Then of course Boostbook to > Docbook, and Docbook to HTML. > > Other than the very pleasing boost documentation styling, is this seemingly > convoluted conversion route necessary? Is it not possible to configure a Doxyfile to > contain the correct styling? > > I have no knowledge of the evolution of boost documentation and have no axe to > grind, but as a newcomer it seems to me that there is a lot of 'unnecessary' > compication in the production of documentation. I appreaciate that there's no real > sense in revisting existing libraries, but for new ones wouldn't it be prudent to > choose the shortest possible path which involves the least learning and > maintenance? It depends on the size of the documentation. For 'trivial' documentation, the Doxygen and Markdown combination is acceptable, but I believe strongly that the best Boost documentation is done using the Quickbook toolchain (including Doxygen syntax comments to provide a references section). A killer feature of Quickbook is the ability to include code snippets from actual C++ examples that can be run, ensuring that what you get is what compiles and runs. As a mark-up language Quickbook is pretty obvious (apart from the gotcha of using indent-spaces as a way to add code sections - a common but quick'n'dirty markup feature that can cause some confusion). Paul

1 0

Boost ASIO
by live man 03 Jan '20

03 Jan '20

Hi, We have been using Boost for our firmware product which runs in ARM processor. However for development we make use of Visual Studio IDE. We also have our own TCP / IP suite which defines its own socket.h file. We are facing issue related to using Boost ASIO in Windows development platform. It seems that the library by default includes windows networking header files - which we do not want. Instead we want Boost ASIO to make our own library socket headers and declaration. We noticed that if we include Boost ASIO and our TCP / IP socket declaration we get re-definition error and compilation fails with lots of errors? Please let us know how we can resolve the issue with the objective mentioned above? Thanks in advance. Regards, Prakash

2 2

Google Summer of Codes 2020
by saloni garg 02 Jan '20

02 Jan '20

Hello, My name is Saloni Garg. I am an undergraduate student of B.tech in computer engineering. Currently, I am in my second year and I am looking forward to participate in this year's Google Summer of code 2020. So, I want to know, if Boost organization is planning to be a part of this year's Google Summer of codes 2020? Thank you! Saloni Garg

1 0

Recomended way of generating documentation
by Alexander Grund 01 Jan '20

01 Jan '20

Hi, I'm currently in the process of generating documentation in a Boost usable format and got a couple questions. The documentation is currently in-source in Doxygen format and has a markdown file for the start page. 1. Which aliases do I need and for what? I've seen boostdoc and boostrelease but couldn't find a description what and why they are 2. Where do the documentation files need to go? It seems using BJam naively outputs them to bin.v2 not to the libraries doc folder which I'd even see useful because generated files should not clobber the source tree 3. What benefit is there going from Doxygen (over multiple conversions) to boostbook? Can't I just go from Doxygen to HTML? 4. If the above: Calling `doxygen mylib.html` in BJam generates a mylib folder and a mylib.html redirecting into that folder. Both hardcoded to go into a subfolder of bin.v2. How is that useful/useable? Wouldn't I want a 'html' folder and an index.html redirecting to the index.html contained or no redirection file at all? 5. As I'm thinking about calling doxygen manually: Do I need to do anything so e.g. mylib shows up in boost/doc/html? Why is only a subset of the libraries there? Thanks for any help or pointers! Alexander Grund

6 5

Boost-GIL GSOC 2020
by Siddhartha Sen 31 Dec '19

31 Dec '19

Hello, I would like to propose an idea for GSOC 2020. I would like to re-implement pre existing features in Boost-GIL for example inverting an image, conversion from black and white to colour and vice versa, etc, but with the usage of parallel programming in order to improve the efficiency and speed things up. This is nothing but an idea merely, as I have some idea with parallel programming beforehand. Could anyone give me some guidance as in how to proceed with this? And also do you all think this is a good enough proposal? I already have built a couple of libraries for image conversion using openmp, but I am not sure whether they are boost compatible or not. Thank You.

2 1

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Andreas Wass 28 Dec '19

28 Dec '19

This my small review of STLInterfaces, and mainly iterator_interface > - Your name Andreas Wass > - Your knowledge of the problem domain I implement mainly iterators every once in a while, both at work and for personal projects. I have mainly used iterator_interface but used container_interface as well. > - Whether you believe the library should be accepted into Boost (be clear > about this) Yes, it helps cutting down on the amount of boilerplate to write. > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? The design seems solid > * Implementation? Looks solid as well, only had one issue with container_interface (see below). > * Documentation? It is ok. As someone who isn't implementing containers all that often it would be nice to have signatures as well as expressions listed in the container_interface documentation > - Did you attempt to use the library? If so: > * Which compiler(s)? MSVC 2017 and GCC 9 > * What was the experience? Any problems? One problem with container_interface. See https://github.com/tzlaine/stl_interfaces/issues/12 > - How much effort did you put into your evaluation of the review? About two hours implementing iterators and a container

4 5

[review][STLInterfaces] STLInterfaces review results
by Barrett Adair 26 Dec '19

26 Dec '19

Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: * Hadriel Kaplan - ACCEPT * Andreas Wass - ACCEPT * Rainer Deyke - ACCEPT * Arthur Gruzauskas - ACCEPT * Krystian Stasiowski - ACCEPT * Daniela Engert - CONDITIONALLY ACCEPT * Gavin Lambert - Technical comments First, a summary of the reviews: 1. Design Reviewers were unanimous in their appreciation for the design. Krystian had the only asterisk about the design, noting that derived class members should ideally be SFINAE-detected, where the library feature would SFINAE where the corresponding required derived feature detection fails. I have a different opinion about this, but we can discuss that elsewhere. 2. Implementation The container_interface destructor and the optional dependency on cmcstl2 were snags for multiple reviewers. Several compile errors were discovered that need to be addressed. 3. Documentation Reviewers found the documentation to be "ok". A common request was for better organization of derived-class requirements, particularly with the container_interface template. Reviewers also lamented the lack of training wheels for the subject matter. 4. Tests Hadriel noted the lack of non-copyable value_type tests, while Daniela noted the lack of Boost.Build support. Hadriel was the only one who commented on the quality of tests ("good"), and the only one who ran them. Arthur did his own testing, to satisfaction. I appreciate the presence of SFINAE-friendliness tests and the continuous integration. 5. Usefulness Reviewers appreciated the usefulness of the library. Arthur is "using it happily", while others found it "very useful", "fairly useful", or of "high" usefulness. However, Krystian's response implied that this library may not be as useful for containers needing extreme performance. The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. Conditions for acceptance: 1. Remove optional dependency on cmcstl2 (issue #27) 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) 3. Support Boost.Build (issue #25) 4. Replace googletest with Boost equivalent (issue #24) 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) 8. Make Concepts usage C++20-conformant (issue #13) 9. Remove the destructor in container_interface (issue #12) 10. Add tests for non-copyable value types (issue #30) Suggestions: 1. Explicitly document the signatures and return types of functions provided by base class templates (issue #23) 2. Mention the C++20 generator pattern in documentation (issue #19) 3. Document the library's interactions with Ranges (issue #18) 4. Remove unnecessary comments (issue #17) 5. Investigate compile error in VS2015 (msvc 19.0.3) due to issues with noexcept() operator in function overloading (issue #16) 6. Rename container_interface to sequence_container_interface (issue #15) 7. Change the 'contiguous' bool to an enum (issue #14) 8. Document the relationship between value_type operator== and containter_interface-defined operator== (issue #11) 9. Improve table/section names for better navigation of container_interface tutorial (issue #10) 10. Clean up BOOST_STL_INTERFACES_DOXYGEN usage (issue #28) 11. Split up fwd.hpp into multiple headers (issue #29) 12. Document optimization trade-offs of proxy_iterator_interface (issue #30) Rationale: 1. Condition #1 is, I feel, the appropriate default as review manager. If Zach feels strongly about keeping the optional dependency on cmcstl2, we should discuss. 2. Unless the library requirements webpage has fallen out of date, new libraries must still support Boost.Build. 3. A not-so-quick grep of current Boost libraries yields no `gtest` results. I assume that we do not allow googletest as the sole test framework in a library. 4. The other conditions should be self-explanatory. Thank you Zach for your contributions, and I look forward to working with you to add this library into Boost. Regards, Barrett Adair

2 2

[review] [STLInterfaces] STLInterfaces review starts today
by Barrett Adair 26 Dec '19

26 Dec '19

Dear Boost, The formal review of Zach Laine's STLInterfaces library begins now, and will run through December 19. Please participate in this review if you can. To submit a review, please reply to this email with the following information: - Your name - Your knowledge of the problem domain - Whether you believe the library should be accepted into Boost (be clear about this) In addition, you are strongly encouraged to answer the following questions: - What is your evaluation of the library's * Design? * Implementation? * Documentation? * Tests? * Usefulness? - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? STLInterfaces is a C++14 library targeting ISO standardization. The following templates are provided, all C++20-friendly: 1. iterator_interface - a modern version of the iterator_facade and iterator_adaptor parts of Boost.Iterator 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature 3. container_interface - a tool to eliminate boilerplate when writing new containers We would appreciate answers to these library-specific questions: - Do you like the name container_interface? sequence_container_interface is more precise, but seems a bit long. - Would you use something like container_interface, but for associative containers? If so, should it assume a node-based interface, a la std::map and std::set? This assumption would preclude alternative associative container-like types, such as flat_map. Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett

9 15

Re: [boost] [config][build] Doc missing in 1.72
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-24 Glen Fernandes wrote: > Yes. config.htm was a file in boostorg/config until recently. > > Now that it has been removed, meta/libraries.json's documentation > entry needs to be updated: > https://github.com/boostorg/config/blob/develop/meta/libraries.json#L5 > > From "config.htm" to "doc/html/index.html". > > Glen Fixed on develop: https://www.boost.org/doc/libs/develop/libs/libraries.htm (The Config link now goes to the Config documentation). Glen

4 4

Merry Christmas All...
by Ggh 25 Dec '19

25 Dec '19

Hi, Merry christmas to all of you. Happy holidays Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

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

GSoc 2020
by Aniswar SK 19 Dec '19

19 Dec '19

Hello everyone, I am Aniswar Krishnan, a 2nd year Computer Science student at Indian Institute of Technology, Madras. I am have been coding in c++ and python for the past 15 months. I am interested in Mathematics and Algorithms and have done courses on same along with Data Structures, Linear Algebra. I got interested int the projects like Boost.Real and Boost GIL and would like to contribute more to the community. Please guide me and share the relevant resources needed. Will be grateful. Regards, Aniswar Krishnan II Year Computer Science IIT Madras Chennai, Tamil Nadu

3 2

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

18 Dec '19

I've fixed the macros in: * boostorg/multi_array * boostorg/iterator * boostorg/parameter * boostorg/polygon Glen

2 1

What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed
by Niall Douglas 18 Dec '19

18 Dec '19

Acting on guidance given to my recent supply to this list of unprefixed macros, namespaces etc injected into the global namespace by Boost, I have logged a list of all issues with each library, and linked to all those from a single issue logged at https://github.com/boostorg/boost/issues/352. A problem has arisen which requires input from boost-dev. Some Boost libraries define as part of their public API a non-BOOST_-prefixed macro which changes the definition of their header files e.g. PHOENIX_LIMIT (just to be clear, Phoenix is not the only library doing this) If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing code using Boost which sets PHOENIX_LIMIT would potentially *silently* break. What we could decide to do instead is: #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif Or one could just leave PHOENIX_LIMIT named as is. What would Boost developers prefer we do? Niall

8 19

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Hadriel Kaplan 18 Dec '19

18 Dec '19

Howdy, For this review I've really only tried out the iterator_interface part. I'm sorry I can't provide feedback on the container_interface nor view_interface, as I just don't have the free cycles. > - Your name Hadriel Kaplan > - Your knowledge of the problem domain I've been using boost's iterator_facade and adaptor for a long time; I've written my own custom iterators as well, of both traditional and proxy-types. The usual stuff. > - Whether you believe the library should be accepted into Boost (be clear about this) Definitely. It could use word-smithing and minor cleanup stuff, but presumably that happens later. (?) > - What is your evaluation of the library's > * Design? Good overall. > * Implementation? Good. I've got some nitpicks, but honestly none are a big deal. minor nitpicks: 1) I didn't use the proxy_iterator_interface one, only looked at the code. The proxy_arrow_result storing a local T value that it only returns a pointer to, means it's not optimal in some cases. Obviously for something like std::vector<bool> it won't matter, but some value-types are not so lightweight. On the other hand, it looks like we can specialize this for our type (or not even use proxy_arrow_result to begin with)? 2) Can the stuff in fwd.hpp be split out? I could be wrong, but I don't think most of it is needed/used by iterator_interface, and only used by the other two, correct? Reducing what gets included would be nice, for people who don't need the container/view stuff. The old boost iterator_facade/adaptor headers included so much that it drove some people to stop using them; for example see the comments here: https://github.com/facebook/folly/blob/master/folly/detail/Iterators.h 3) This lib hasn't been tested for C++20, and obviously can't be yet, but it makes assumptions that it can safely replace some of its internals with C++20's new ones. Things like concepts and ranges. I'm not sure that's advisable, until all the major compilers support them and can be tested. It would be a shame if people using this lib can't upgrade to C++20 because it breaks this lib, until they upgrade boost as well. (not a big deal, just more noting it) 4) The files use a macro to control doxygen output. Is this still required for boost libs? Doxygen has had the cond/endcond commands for a long, long time. It's kinda ugly to see these macros, and kinda silly that everyone's compiler will be evaluating them all the time. (I know that's super-nitpicky) 5) I assume all the _has_include(<stl2/ranges.hpp>) checks will be removed, since that's a thirdparty header? 6) This lib requires C++14, but I don't see a macro checking that anywhere and providing a simple error to the user. 7) I can't decide if the BOOST_STL_INTERFACES_STATIC_ASSERT_ITERATOR_TRAITS() thing is a good idea or a waste of time. I tried it, it passed. But of course it did, because it's just checking that I got the API that I told iterator_interface to create, no? This just seems like needless repetition to me. I mean if I screwed it up to begin with, I'll screw it up in this macro too, no? But maybe I'm missing something obvious. (could be - it's getting late) > * Documentation? It's OK. I enjoyed some of the humor. :) It's missing some info for things that are customization points. For example base_reference() is shown in an example, but not really documented anywhere as far as I can tell. The tables aren't as useful/explanatory as one would hope. I mean I knew what they meant, but I'm not sure someone newer to this area would. (but then again, that's what blogs/articles are for I guess) I think it might also help if there were some explanation for what happens under-the-hood, in terms of what public methods get auto-generated from what, for which iterator types. For example, it's surprising that for a bidirectional iterator the user defines operator==(), but not for random-access iterator. (that particular case happens to be mentioned in a note, but you get my point) There are also typos and such, but I presume that gets checked later. > * Tests? Good. I copied them over and ran them as well. (but not the v2 tests, nor the ones for container_interface or view_interface) I think it would be better if there were some tests for iterator_interface with non-copyable value-types. Testing it only for `int`s is cheating. :) Also, random question: for the container_interface, did you try using it with the boost::fixed_string (or static_string, or whatever it's called)? I mean that _is_ a contiguous container, and it's in boost review too, so might it be a good test candidate? :) > * Usefulness? Very useful. iterator_facade/adaptor were showing their age. It's time for something new and shiny. I was happy that it reduced the number of functions we needed to implement in our current usages from 5 to 3. > - Did you attempt to use the library? Yup. I replaced three existing boost::iterator_facade usages in my company's code-base with this one, to try it out. Ran our unit tests with and without valgrind as well. But to be honest these weren't very complicated iterators. I did _not_ try replacing boost::iterator_adaptor, but I hope to try that eventually. > * Which compiler(s)? (old ones, so I could build my employer's codebase and run all their unit tests...) 1) gcc 7.3.1 with c++17 2) clang 5.0.0 with C++17, using gcc's libstdc++ Both using boost 1.55 (sorry!), with the stl_interfaces headers copied over manually, without using the CMake files in the github repo. Neither compiler has the early Concepts support. > * What was the experience? Any problems? Not really. The hardest part was figuring out the new model of what the derived had to define, compared to iterator_facade. (i.e., I was so used to the old model that it took me a bit to grok this one) > - How much effort did you put into your evaluation of the review? Only a few hours, maybe 4-5 total. Sorry, I wish I had more free time. :( > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. I'm not sure the length matters much for this use-case, as it's a one-time thing (generally), and not used by users of the actual container; and can anyway be aliased. (I mean, the "stl_interfaces" sub-namespace is annoying too, but it's not a big deal in my opinion) > - Would you use something like container_interface, but for associative > containers? If so, should it assume a node-based interface, a la std::map > and std::set? This assumption would preclude alternative associative > container-like types, such as flat_map. Yes I think so, depending on what it did... but for *unordered* ones (i.e., hash-maps/sets), rather than rb-trees. I often find myself encapsulating them, and then having to write a lot of boilerplate public member functions. And several functions can be boiled down for hash-maps. For example count() and contains() can just use find(). I don't know why an unordered_container_interface wouldn't be do-able, including heterogenous lookups, for various hash-map/set flavors. (except, of course, that boost::unordered_map/set's API is different than std's for heterogeneous lookup; which is unfortunate) -hadriel

1 0

[review] [STLInterfaces] STLInterfaces iterator_interface mini mini review
by Arthur Gruzauskas 18 Dec '19

18 Dec '19

On Wednesday, 11 December 2019 11:21:23 AM AEDT Barrett Adair via Boost wrote: > Dear Boost, > > The formal review of Zach Laine's STLInterfaces library begins now, and > will run through December 19. Please participate in this review if you can. > To submit a review, please reply to this email with the following > information: > - Your name Arthur Gruzauskas > - Your knowledge of the problem domain I've written a number of iterator interfaces over the years. Nothing fancy, but have dipped my toes in iterator implementation. > - Whether you believe the library should be accepted into Boost (be clear > about this) ACCEPT, simply because I am using it happily. but I have only used container_interface, not the rest. > > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? simple interface, small learning curve, great value for effort. A small number of methods to implement the essential concepts. A small enough concept chunk to be easily manageable. simple to use, just copied the code in the readme.md and adapted it. > * Implementation? worked for me. I didn't examine the code much. I like its layout and it looks clean to me. > * Documentation? The readme.md with that simple example was enough for me to adapt the intro sample iterator to my code. I note the example has been criticised by Gavin Lambert a few posts ago. But I love it as it made everything simple and clear. Reading the main doc page filled in a few conceptual gaps, but that readme.md gave me the overview that made the rest easy. > * Tests? So far brief tests have all worked well. I did not exhaustively test the iterators. They also worked fine in a couple STL algorithms. Again, I have only dealt with iterator_interface.hpp > * Usefulness? My experimental class would have stalled for some time if this easy iterator interface had not been there. Encouraged, I'm now looking at using it for more complicated structures. > - Did you attempt to use the library? If so: > * Which compiler(s)? clang-8 for c++17 on debian linux. > * What was the experience? Any problems? very straightforward. a few small glitches, as I just grabbed iterator_interface.hpp and fwd.hpp and made small changes for it to work inside my project. https://github.com/tzlaine/stl_interfaces/issues describes two minor issues, which could be well related to me just grabbing those 2 files only, outside the boost structure that would normally sustain it. > - How much effort did you put into your evaluation of the review? Several hours reading, adapting and getting it working for me. > > STLInterfaces is a C++14 library targeting ISO standardization. The > following templates are provided, all C++20-friendly: > > 1. iterator_interface - a modern version of the iterator_facade and > iterator_adaptor parts of Boost.Iterator > 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature > 3. container_interface - a tool to eliminate boilerplate when writing new > containers > > We would appreciate answers to these library-specific questions: > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. It doesn't clash with anything in my mental namespace, so I'm happy with the name container_interface. BTW, I have not used container_interface, I just saw it now and had a look. I can see this simplifying some upcoming containers, and will certainly be giving it a go. view_interface is not something I have a need for currently. > - Would you use something like container_interface, but for associative > containers? > If so, should it assume a node-based interface, a la std::map > and std::set? This assumption would preclude alternative associative > container-like types, such as flat_map. > > Code: https://github.com/tzlaine/stl_interfaces > Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html > > Thanks, > Barrett > My one small concern is in the required method: constexpr auto operator-(repeated_chars_iterator other) const noexcept instead of: constexpr auto operator-(const repeated_chars_iterator& other) const noexcept I may soon have a need for an iterator that holds a lot of state, and copying that iterator for each subtraction makes me wonder about a performance penalty in inner loops. It is not a dealbreaker for this review, and I didn't examine Zach's tradeoffs for doing it this way. I see many of my use cases where this approach will be fine. This is my first review, incomplete as it is, mainly motivated because no one else has done one yet, and because I found iterator_interface useful and want to encourage Zach for this lovely simplifying interface. Thanks very much, Zach. Arthur

3 4

Unmerged change in boostcpp.jam
by Peter Dimov 17 Dec '19

17 Dec '19

boostcpp.jam on develop contains the following patch, which is not merged to master: diff --git a/boostcpp.jam b/boostcpp.jam index efc41c1ed..299401778 100644 --- a/boostcpp.jam +++ b/boostcpp.jam @@ -607,7 +607,7 @@ rule address-model ( ) return <conditional>@boostcpp.deduce-address-model ; } -local deducable-architectures = arm mips1 power sparc x86 combined ; +local deducable-architectures = arm mips1 power riscv s390x sparc x86 combined ; feature.feature deduced-architecture : $(deducable-architectures) : propagated optional composite hidden ; for a in $(deducable-architectures) { @@ -618,11 +618,13 @@ rule deduce-architecture ( properties * ) { local result ; local filtered = [ toolset-properties $(properties) ] ; - local names = arm mips1 power sparc x86 combined ; + local names = arm mips1 power riscv s390x sparc x86 combined ; local idx = [ configure.find-builds "default architecture" : $(filtered) : /boost/architecture//arm : /boost/architecture//mips1 : /boost/architecture//power + : /boost/architecture//riscv + : /boost/architecture//s390x : /boost/architecture//sparc : /boost/architecture//x86 : /boost/architecture//combined ] ; This seems to add support for "riscv" and "s390x" as architectures. Should this be merged to master?

1 0

Test Matrix not Updating
by Michael Caisse 16 Dec '19

16 Dec '19

We are aware that the test matrix has not been updating. The problem is caused by a server that we do not control. Things should be resolved in the next couple days. Thank you for your patience and sorry about the disruption. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Enabling warnings for library sources and tests but not for dependencies
by Alexander Grund 15 Dec '19

15 Dec '19

Hi, I want to build at least the tests but better also the library sources itself with warnings enabled and warnings-as-errors to avoid regressions. >From BoostAssert I found the following snipped added to the top of test/Jamfile.v2: project : requirements <warnings>pedantic <warnings-as-errors>on ; Further down I have a dependency on BoostFilesystem like: run test_stdio.cpp : : : <library>/boost/filesystem//boost_filesystem ; But now the build of BoostFilesystem fails: gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-5.4.0/release/cxxstd-11-iso/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:217:48: error: unused parameter 'buffer' [-Werror=unused-parameter] Is there any way to restrict the warnings to my project only? Or at least the warnings-as-errors option? Is there a way to set warnings-as-errors via b2 command only for this library? This would avoid putting it in the Jamfile which could affect end-users, but having it on CI is actually enough. Alex

2 3

bug-fix release 1.72.1?
by Oliver Kowalke 15 Dec '19

15 Dec '19

Hello, unfortunately I accepted a faulty pull request and the commit that reverted it was not included into release 1.72 (for instance spawn() of Boost.Asio will fail to compile). Oliver

3 4

Assuming maintainership of boostorg/io
by Glen Fernandes 15 Dec '19

15 Dec '19

I'd like to take on maintainership of IO, as suggested by Peter. So far, I've already: * Implemented the Fundamentals TS v2 ostream_joiner as boost::io::ostream_joiner * Converted the documentation to Asciidoc * Updated the test cases to use Lightweight Test and build faster * Updated the CI configurations I also plan to: * Finish the boost::io::quoted implementation started by Beman but currently in detail. i.e. Update and improve the implementation. Add better documentation and more tests, and make it non-detail (public). * Migrate my boost::ostream_string facility from Boost.Utility (which is more general purpose) to Boost.IO (because, well, IO). * Make some minor improvements to the implementation of boost::io::ios_state. Glen

2 1

Re: [boost] Assuming maintainership of boostorg/io
by Bjorn Reese 14 Dec '19

14 Dec '19

On 2019-12-14 17:31, Glen Fernandes via Boost wrote: > I'd like to take on maintainership of IO, as suggested by Peter. +1

1 0

Attn: Maintainer of boost/bind.hpp
by Niall Douglas 13 Dec '19

13 Dec '19

In boost/bind.hpp there is injection of a boost namespace contents into the global namespace: ```c++ #include <boost/bind/bind.hpp> #ifndef BOOST_BIND_NO_PLACEHOLDERS #if defined(BOOST_CLANG) # pragma clang diagnostic push # if __has_warning("-Wheader-hygiene") # pragma clang diagnostic ignored "-Wheader-hygiene" # endif #endif using namespace boost::placeholders; #if defined(BOOST_CLANG) # pragma clang diagnostic pop #endif #endif // #ifndef BOOST_BIND_NO_PLACEHOLDERS ``` The fact that Boost actually disables the relevant compiler warning makes this particularly insidious. No modern C++ library should ever do "using namespace" into the global namespace in its public headers. Please fix this in the next release of Boost. Niall

2 4

Attn: Maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception
by Niall Douglas 13 Dec '19

13 Dec '19

Dear maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception, Please find attached a list of macros in your libraries without BOOST_ prefixing, as is required by Boost library guidelines. If you could fix these promptly, it would be appreciated. Niall

1 1

Re: [boost] [release] Boost 1.72.0 has been released
by Glen Fernandes 12 Dec '19

12 Dec '19

Andrey wrote: > In release notes, New Libraries says TODO. Also on the main page it showed a blank list of updated libraries. Both should be fixed now: https://github.com/boostorg/website/commit/3f37b654d7126c0ad312e50d227c03d2… https://github.com/boostorg/website/commit/7c897e8c768cf28113ba07488a6b5030… Glen

2 1

[release] 1.73.0 open for merging
by Marshall Clow 11 Dec '19

11 Dec '19

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] Boost 1.72.0 has been released
by Marshall Clow 11 Dec '19

11 Dec '19

Release 1.72.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.72.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.72.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse

3 2

[release] Boost 1.72.0 Release Candidate 2
by Marshall Clow 10 Dec '19

10 Dec '19

The second release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: 247a91dd7e4d9dd3c4b954b532fbc167ba62dc15ab834e5ad893d7c3f9eb5f0f ./boost_1_72_0_rc2.7z 59c9b274bc451cf91a9ba1dd2c7fdcaf5d60b1b3aa83f2c9fa143417cc660722 ./boost_1_72_0_rc2.tar.bz2 c66e88d5786f2ca4dbebb14e06b566fb642a1a6947ad8cc9091f9f445134143f ./boost_1_72_0_rc2.tar.gz 8c20440aaba21dd963c0f7149517445f50c62ce4eb689df2b5544cc89e6e621e ./boost_1_72_0_rc2.zip Changes since RC1: * A change to Boost.Proto that would cause compilation failures on the latest MS compiler. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

2 4

Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 10 Dec '19

10 Dec '19

Hi, I was wondering whether there is any interest in exploring a C++20 single header/single module, macro-free Unit Testing Framework with no dependencies? Github: https://github.com/boost-experimental/ut Additional links: - Try it online: https://godbolt.org/z/uVDxkW - Benchmarks: https://github.com/boost-experimental/ut#benchmarks - How it works?: https://github.com/boost-experimental/ut#how-it-works Thanks, Kris

8 30

Re: [boost] [STLInterfaces] only three operations?
by Zach Laine 09 Dec '19

09 Dec '19

On Mon, Dec 9, 2019 at 12:55 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > > > pon., 9 gru 2019 o 17:32 Zach Laine <whatwasthataddress(a)gmail.com> > napisał(a): > >> >> >> >>> Same with the iterator in the flight map: >>> >>> >>>> https://github.com/tzlaine/flat_map/blob/master/implementation/flat_map#L266 >>>> >>> >>> According to C++17 requirements this shouldn't have been a >>> random_access_iterator. >>> >>> Also, std::ranges::sort() will not work with it. But this is not >>> directly related to `iterator_interface` >>> >> >> I don't know why you think that. ranges::sort() is designed to work with >> std::random_access_iterator, which is designed explicitly to support proxy >> iterators. Casey and Eric have assured me that this "just works". Do you >> know of a reason why it does not? If so, you've spotted a defect, and we >> should file an LWG issue immediately. >> > > Not sure if it is a defect. An iterator that returns a proxy as > ::reference can be a valid random_access_iterator. However, > std::ranges::sort(), apart from a random_access_iterator requirement, has > one more requirement: sortable<>: (http://eel.is/c++draft/sort) which > boils down to indirectly_writable ( > http://eel.is/c++draft/iterator.concept.writable) This last concepts > puts severe restrictions on proxy types. For instance you should be able to > assign to them when they are const-qualified. So a type like std::tuple<> > of references will not work. But you will be able to design a sufficiently > bizarre proxy type that will work with std::ranges::sort(), So in a way it > will work with *some* reference proxies. > Ok, I just realized this somehow drifted off-list. Re-adding the list... This is the definition of indirectly_writable: template<class Out, class T> concept indirectly_writable = requires(Out&& o, T&& t) { *o = std::forward<T>(t); // not required to be equality-preserving *std::forward<Out>(o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*o) = std::forward<T>(t); // not required to be equality-preserving const_cast<const iter_reference_t<Out>&&>(*std::forward<Out>(o)) = std::forward<T>(t); // not required to be equality-preserving }; All you need to make this work is a reference type for which all those are well-formed. If you pick std::tuple, it all just works. If you pick std::pair, only the first two expressions in the requires expression work. You can easily define UDTs for which this concept works too, of course. Zach

1 0

Interest in an audio filtering / algorithm Library?
by Vinnie Falco 09 Dec '19

09 Dec '19

Is there any interest in having a new libraries for Boost that is focused on the audio domain (but with portions applicable generically)? I'm thinking about a library that does stuff like: * finite impulse response filtering * infinite impulse response filtering * time stretching, resampling * audio synthesis * audio algorithms * mixing * plenty of ready-to-run filters: - low pass, high pass, band pass - echo, reverb, flanger, phaser and the like This is a pure math library, no actual audio. To get an idea of the algorithms and use-cases check out my DSPFiltersDemo program (press Download Now): <https://github.com/vinniefalco/DSPFiltersDemo> Please note, my library is not what is being proposed, this would be a new library from a domain expert (not me). Thanks

7 8

[review][fixed_string] review period finishes today Dec 8
by Joaquin M López Muñoz 08 Dec '19

08 Dec '19

The review period of candidate Boost.FixedString finishes today, Dec 8. Many interesting subjects have been discussed about during these two weeks and I have quite a bit of material to digest before publishing the final review result plus further action points. I expect to be able to do so during the following week. Thank you to all the people who have contributed their reviews and comments and to Krystian and Vinnie for submitting their work and enduring the famously severe review ordeal. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

2 1

Re: [boost] Boost GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Thanks a lot for forwarding my email to the boost GIL list. I will check it out. What I meant by conversion, however was primarily converting an image to negative and greyscale. As you may already know, the two pf them are pretty similar and OpenMP has shown how incredibly fast the process can be using more threads. I just feel GIL would benefit a lot from using parallel programming. On Sun, 8 Dec, 2019, 5:30 PM , <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > > > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > > > Today's Topics: > > 1. Re: [fixed_string][review] Review of fixed_string (Rob Stewart) > 2. Re: Extending GIL (Mateusz Loskot) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 07 Dec 2019 13:23:51 -0500 > From: Rob Stewart <rstewart(a)ptd.net> > To: boost(a)lists.boost.org,Phil Endecott via Boost > <boost(a)lists.boost.org> > Cc: Phil Endecott <spam_from_boost_dev(a)chezphil.org> > Subject: Re: [boost] [fixed_string][review] Review of fixed_string > Message-ID: <142EED34-B802-4381-9FF9-C9FE999BA0F9(a)ptd.net> > Content-Type: text/plain; charset=utf-8 > > > > On December 5, 2019 9:35:35 AM EST, Phil Endecott via Boost < > boost(a)lists.boost.org> wrote: > > Peter Dimov wrote: > > > - a function that checks whether the remaining capacity is at least > > n should > > > be added. I suggest the name > > > > > > bool can_fit( std::size_t n ) const noexcept; > > > > > > although my previous choice of "has_capacity_for" has merit too. > > I suggest the simpler "fits". > > > Make this a free function template and you can use it with other > > containers: > > > > template <typename CONTAINER> > > bool can_fit( const CONTAINER& C, typename CONTAINER::size_type n ) > > noexcept > > { > > return C.capacity() - C.size() >= n; > > } > > That's a nice idea, especially with the name "fits". :) However, if you > reverse the parameters, "fits_in" would be a better name as it indicates > the argument order. > -- > Rob > > (Sent from my portable computation device.) > > > ------------------------------ > > Message: 2 > Date: Sun, 8 Dec 2019 01:25:04 +0100 > From: Mateusz Loskot <mateusz(a)loskot.net> > To: boost(a)lists.boost.org > Subject: Re: [boost] Extending GIL > Message-ID: > < > CABUeae_cupOMOhCNvvHaeruX2ksycHhVKkHJbtCSCLr-kW-XkA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Sat, 7 Dec 2019 at 01:12, Siddhartha Sen via Boost > <boost(a)lists.boost.org> wrote: > > > > Having looked up this repository : > https://github.com/boost-gil/gil_threaded, > > I feel the idea was the same, but a lot of improvement can be made. > > Good, sounds like you may have a plan in mind > > > Also, there was no provision for image conversion, which I feel > > Please, you need to be more specific here. > What kind of conversion do you mean: color, channel/pixel type, format,...? > > p.s. I forwarded your post to the GIL mailing list > https://lists.boost.org/boost-gil/2019/12/0362.php > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > ------------------------------ > > End of Boost Digest, Vol 6271, Issue 1 > ************************************** >

2 1

[release] 1.72.0 post-beta merges
by Michael Caisse 08 Dec '19

08 Dec '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy>

11 31

[range] Trying to extend boost::range::combine to std::tuples
by Andres Llopis 08 Dec '19

08 Dec '19

Hi everyone, I am trying to make my own version of combine so that it works also with std::tuples. Someone on slack suggested that the zip iterator should be able to handle it properly. My attempt however fails when trying to use the metafunction tuple_of_references::type for the std::tuple of iterators. This is what I tried (https://godbolt.org/z/Ymjtvn) (Please excuse any style problems, this is my first post) namespace myns { using boost::iterators::zip_iterator; using boost::iterator_range; template<typename IterTuple> class combined_range : public iterator_range<zip_iterator<IterTuple> > { typedef iterator_range<zip_iterator<IterTuple> > base; public: combined_range(IterTuple first, IterTuple last) : base(first, last) { } }; template<typename... Ranges> auto combine(Ranges&&... rngs) -> combined_range<decltype(std::make_tuple(std::begin(rngs)...))> { return combined_range<decltype(std::make_tuple(std::begin(rngs)...))>( std::make_tuple(std::begin(rngs)...), std::make_tuple(std::end(rngs)...)); } }

3 5

Extending GIL
by Siddhartha Sen 08 Dec '19

08 Dec '19

Having looked up this repository : https://github.com/boost-gil/gil_threaded, I feel the idea was the same, but a lot of improvement can be made. For example, by using OpenMP, I feel the computational performance can be massively improved and that too, not requiring any extremely sophisticated hardware. Also, there was no provision for image conversion, which I feel is a very good extension. What do you all think?

2 1

[fixed_string][review] Review of fixed_string
by Peter Dimov 07 Dec '19

07 Dec '19

This is my review of FixedString. * Summary The library should be ACCEPTED. It's useful, for more than one domain, and specifically where compile-time string manipulation is concerned, everyone needs to reinvent it. The name fixed_string is fine as is. Alternatives exist, but I don't see any of them as unquestionably better, and one becomes accustomed to "fixed_string" after a very brief period. Throwing on exceeding capacity is fine as is. A function should be provided to check the remaining capacity, because writing this check by hand is very easy to get wrong, and in fact the library throughout its implementation consistently gets it wrong. * Documentation The documentation is adequate, but I don't find the reference convenient. I would prefer a synopsis that contains the entire class definition of `fixed_string`, so that I can see the various overloads at a glance. Instead, the synopsis only gives me the declaration of `fixed_string`, without even telling me what namespace it's in. (It also gives me `basic_string_view`, also without mentioning the namespace.) The current layout is fine if I want to look up a specific function by name. The format should ideally follow the standard library, with Throws and Expects clauses (the latter instead of "undefined behavior unless".) It's not documented when constructors and assignment operators throw. * Design - static_capacity should be removed; capacity() and max_size() should be static constexpr. - all nonthrowing functions should be marked `noexcept`. - initializer_list<CharT> overloads are of dubious utility. I know that the design copies std::string here, but I think that we should deviate and not provide them. - substr() should return a fixed_string, subview() a string_view (as already implemented.) - operator+ should be provided, only for arguments with capacity known at compile time (fixed_string<N>, CharT and CharT const (&)[ N ]), with the capacity of the result being the sum of the capacities of the arguments. This is not very useful for long strings, but it's fine for short strings, useful for compile-time manipulation, and useful in simple cases such as to_fixed_string( n ) + " bytes written". - a function that checks whether the remaining capacity is at least n should be added. I suggest the name bool can_fit( std::size_t n ) const noexcept; although my previous choice of "has_capacity_for" has merit too. This is, in my opinion, an absolutely necessary addition, because of my already-stated observation that the check is almost always gotten wrong. Here for instance is an example: if(size() + count > max_size()) BOOST_FIXED_STRING_THROW(std::length_error{ "size() + count > max_size()"}); The correct way to write it is max_size() - size() > count, which avoids the integer overflow in size() + count. In this case, passing count = (size_t)-1 will pass the check (when size() > 0) and then lead to undefined behavior. This makes the utility of reserve() dubious, because it basically invites one to get it wrong, but I think we should retain it for consistency. - everything should ideally be constexpr. The problem here is that constexpr requires initializing all elements, and this will heavily penalize runtime uses of f.ex. fixed_string<512>. On compilers with __builtin_is_constant_evaluated (gcc 9, clang 9) we should use that; otherwise, it might be worth it to create a specialization for N < some suitable upper limit. Again, any nontrivial string manipulation at compile time basically requires a fixed_string. * Implementation The physical separation of the library into three headers is inconvenient. A single header would make it possible to include the library directly on Godbolt via https, which is useful for both demonstrations and analysis of the generated code. In addition, hunting down the definitions is irritating for people reading the code. The reverse is true for the tests; they should be split into files each testing a logical group, such as constructors, assignment, append, and so on. The helper functions "testAS", "testI" and so on make reading the tests unnecessarily cryptic (and is quite annoying for reviewers.) They should have been named "test_assign", "test_insert". It's generally better to use `BOOST_TEST_EQ(s.size(), 0);` instead of `BOOST_TEST(s.size() == 0);` because the former prints the values on failure, which often gives clues as to where the error is. The test functions shouldn't be in the boost::fixed_string namespace. Users don't write their code in this namespace, so the tests don't test what users use. All capacity checks should be either audited for correctness and fixed, or use the proposed can_fit addition. Instead of repeating BOOST_FIXED_STRING_THROW(std::length_error{ "n > max_size()"}); in every function, which leads to it being inlined there repeatedly, this could use a helper function void throw_length_error( char const * msg, boost::source_location const& loc ) { boost::throw_exception( std::length_error( msg ), loc ); } taking advantage of the new boost::throw_exception overload that takes a source location as documented in https://www.boost.org/doc/libs/develop/libs/throw_exception/doc/html/throw_…. A variation could take `n` as an argument and compose a message containing it, f.ex. void throw_length_error_fmt( boost::source_location const& loc, char const * fmt, ... ); #define BOOST_FIXED_STRING_USE_BOOST should go, as already mentioned. Since the library requires C++11, there's no need to use BOOST_STATIC_ASSERT. static_assert is fine. Unless of course we backport it to C++03, which might be doable, although of questionable utility. Checking for overlap and using Traits::copy instead of Traits::move isn't needed. Traits::move does the same check anyway, so there's no gain, just an opportunity to get the check wrong and introduce undefined behavior. "The behavior is undefined if `count >= npos`" doesn't seem necessary. In this case, count will be bigger than max_size() and the constructor will throw std::legth_error. There's no reason to gratuitously introduce undefined behavior. All "undefined behavior" cases should consistently BOOST_ASSERT.

4 4

[nowide] Future
by Artyom Beilis 07 Dec '19

07 Dec '19

The nowide library was reviewed and accepted into Boost almost 3 years ago. I implemented most of fixes required under Review Fixed branch https://github.com/artyom-beilis/nowide/tree/reviewfixes Unfortunately I don't have any capacity to do maintenance for it on all various platforms: MSVC, mingw. cygwin etc mostly because virtually I don't develop on Windows and any time I need to go there I need to figure it out from the beginning (installations, environment, msvc) and I don't even have windows machine in my hands (all done in VM) I realized that I'm not windows developer any more and it would be impossible for me to complete the mission of maintaining the code mostly due to personal reasons and lack of development resources. I deeply regret wasting the time and effort of so many boost developers who invested to review. I understand that it is highly desired library but I just can get the job done I seek for your advice. Do I need to seek for an another maintainer or withdraw the library entirely? Once again sorry for disappointing the community and people who were invested in this library. Artyom Beilis

6 10

[review][fixed_string] End of review period approaching and a plea
by Joaquin M López Muñoz 06 Dec '19

06 Dec '19

The review period for candidate Boost.FixedString finishes tomorrow, Dec 4. There's an ongoing lively discussion on many aspects of the library, which is very good, but only three of you have cast your acceptance/rejection vote, which is not good. This is a gentle petition to the people engaging in the review who haven't voted yet: Vinícius, Nevin, Mike, Andrzej, JeanHeyd, Hans, Peter, Julien, Andrey, Tim, Gavin, Emil, (and anyone who might be still lurking) to please submit a review with an explicit vote. If you feel like you need some more time to do the work, I think we are in a position to extend the review period, but please express your intentions before I ask the review wizards. Thank you! Joaquín M López Muñoz Review manager for candidate Boost.FixedString

13 35

[release] Boost 1.72.0 Release Candidate 1
by Marshall Clow 05 Dec '19

05 Dec '19

The first release candidates for the 1.72.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.72.0/source/> The SHA256 checksums are as follows: fcd8b598bc63ae7bbd3e72635d95b9d749ef65f4e5342c24445ea1fb9d417ac3 boost_1_72_0_b1_rc1.7z f6a527a261e273bfd2b6161d359ab9fb53c1795239c696f501a62f575cd30bda boost_1_72_0_b1_rc1.tar.bz2 8e591146d39e8cb45c74540aae26ae6321b1e83ab1b12e236dd117f93475ceb9 boost_1_72_0_b1_rc1.tar.gz 3425e7bfd49a6ad70aa7e82c1c740f7821eb58d14604b133be4dfbcdc0c58e3a boost_1_72_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

3 10

[review][fixed_string] Andrzej's feedback
by Andrzej Krzemienski 05 Dec '19

05 Dec '19

Hi Everyone, This can hardly be called a review, as I didn't look thoroughly at the implementation. (I only checked what happens on the resize() over the capacity(), as this was not clear from the docs.) I think that ultimately the library would be a useful addition to Boost, however I would not like to rush it before its design is fully baked, and my impression is that it isn't yet. Therefore my recommendation would be to REJECT the library at this point, and encourage the authors to resubmit it for the second review once the design goals and design decisions have been clearly settled and communicated. My vision of a review is that we: 1. First evaluate the design goals, whether they are worth pursuing 2. Then we evaluate the design *against* those goals. 3. Then we evaluate the documentation and implementation *against* the design and goals. I cannot even go to #3, as to me #1 is missing some parts. There are different possible goals: 1. Treat this new string as many other STL sequence containers with variable size. In particular, users use it as if its max_size() were infinite, and are prepared that at some point an exception might be thrown. 2. Treat it as a "drop-in replacement" for std::string with no-heap-alloc guarantee. 3. Make something suitable for embedded systems where the user provides the guarantee: "I will never make the size() of this string go above this value. If I did, it would be plain clear that the program is not doing what it was supposed to." These goal 3 is in clear conflict with either 1 or 2. This becomes clear when we consider what should be the response to doing a resize() over capacity(): a precondition violation or a normal course of action signaled by an exception. The authors should make a choice which of these goals is not supported and communicate it clearly from the outset in the docs. I think this decision has already been made: the library was extracted from Boost.Beast and there the purpose must have been clear. It is just that it is not communicated in fixed_string library. Any decision is good. In C++ performance trade-offs are part of the contract (interface), so there is room in Boost for many strings: small strings, short codes, fixed size strings, fixed capacity strings. But for each library it should be clear what trade-offs were chosen and why. We have a situation that there exists static_vactor in Boost, which defines the resize() over capacity() to be a precondition violation. And fixed_string needs to provide some response to this fact: why did you choose a different design? I consider the choice of name to be part of the design: you cannot assign the name before you have decided on the goals. "static_string" might be a good name if you chose the same trade-offs as static_vector. But if you make different trade-offs, it might be better to use a different name. Making a resize() over capacity() a precondition violation is a *feature* useful for bug detection and I do not consider it a valid argument that "library will throw exceptions and if you never resize() over capacity() you will never see exceptions or std::abort()". If this is a precondition, then I expect of a library to put some BOOST_ASSERT() or _builtin_unreachable() in those paths to enable better bug detection. I find the goal "a drop-in replacement for std::string" invalid. You surely mean only a drop in replacement for some subset of usages. I guess this subset comes from the usage in Beast, and I would expect that it is clearly outlined what this subset is. One of the operations on strings that I use most often is operator+, so when I hear that this operation is not implemented in a class that claims to be a drop-in replacement for string, I see a contradiction. There might be valid reasons not to provide operator+, but the documentation cannot state that this is a drop-in replacement for std::string. I think that only after the above issues have been sorted out can we have a review of the implementation and the documentation. One remark about documentation is that I was not able to find what `resize()` over `capacity()` does. This is the most important information that I was after. anything else is more less intuitively clear from the analogy to std::string. I hope that this feedback doesn't sound discouraging. I appreciate the work Krystian and Vinnie have put into making this submission, and I would like to see this library ultimately included in Boost. Regards, &rzej;

7 27

iostreams gzip_compressor
by Kemin Zhou 05 Dec '19

05 Dec '19

I have been using the compressor and decompressor for a while now. One of the issues is the performance not sufficient for large data operations. The underlying zlib library is single-threaded, and there is a parallel version implementation at application level https://zlib.net/pigz/ pigz. When working with large file compression and decompression it usually take 8 hours to do the job. If I can use multi-threaded version then it usually can be done within one hour. There is a strong need to use multi-threading to speed up this process for me. I would appreciate that someone can implement this feature. If not I can work on this project. Not sure what's the best way to go about this. -- Kemin Zhou 858 366 8260

1 0

[fixed_string] Copying/comparing entire strucutre
by Phil Endecott 05 Dec '19

05 Dec '19

Dear All, Considering small-capacity fixed_strings like the example that I gave previously: struct NameAndAddress { static_string<14> firstname; static_string<14> surname; static_string<30> address_line_1; static_string<22> city; static_string<10> postcode; }; I have been looking at how best to copy and compare them. For small-capacity strings, and also for large-capacity strings when their size approaches the capacity, it will be quicker to unconditionally copy/compare everything, including the unused bytes beyond the end, rather than looping over just the current size. I've tried a very crude benchmark based on this: struct string { uint8_t size; std::array<char,N> data; }; extern void copy_all(string& dest, const string& src) { dest = src; } extern void copy_size(string& dest, const string& src) { dest.size = src.size; std::copy(src.data.begin(), src.data.begin()+src.size, dest.data.begin()); } Results will depend on the architecture but I found that for N < 64 it was probably always best to copy_all(). For N==255, time for copy_all() and copy_size() is about equal when the container is half full. Things are more complicated for operator== because of the unused bytes. It would be necessary to initialise everything to 0 and maintain that during e.g. erase() and assign(). I haven't tried to benchmark that but I suspect the trade-off would be similar. operator< is a mess due to endianness. I don't know whether any compilers or memcmp() implementations are smart enough to use byte-swap instructions to process data 4 or 8 bytes at a time. I don't think I'm suggesting that this should necessarily be implemented in fixed_string, at least not without lots more investigation, but it does illustrate more of the trade-offs that exist between different applications. Regards, Phil.

2 1

[ Review ] [ fixed_string ] Accept
by JeanHeyd Meneide 05 Dec '19

05 Dec '19

Dear Boost, This is a review of boost.fixed_string. It is my first review, so take it with a grain silo's worth of salt. ------------- Summary 📝 -------------- Accept fixed_string. It's about ---------------- What I Did ⚙️ ---------------- - I ran its tests, VS 2019 i686 and x86-64 | VS 2017 i686 and x86-64 | MinGW 9.2.0 i686 and x86-64 - I put it inside itsy.bitsy (https://github.com/ThePhD/itsy_bitsy) and used it as an underlying container in its tests. - I put it inside my private text repository as an underlying container to hold code units for several different encoding schemes and it work (https://github.com/ThePhD/text-dev | far-behind implementation at https://github.com/ThePhD/text) - I generally messed around with it in a basic main.cpp file and read the docstrings and docs while comparing it to cppreference. -------------- Strengths 💪 -------------- +1 - Follows std::string's container design nicely, making it easy to program around and know what to expect from the outset. (Side note: ignore whoever said to remove the initializer list ones: I used all of them. It's necessary to be considered a SequenceContainer (https://en.cppreference.com/w/cpp/named_req/SequenceContainer).) +1 - Works with all character types. char, wchar_t, char16_t, char32_t, and -- in C++20 mode -- char8_t for the compilers that have it. +1 - insert, erase, clear, push_back, push_front meet specification I flexed it by inserting it as part of itsy.bitsy's tests and using it as one of its sequence containers. +1 - docs are straightforward. +1 - iterators work just fine. I tested it using itsy.bitsy as an underlying container for a reference_wrap'd bit_view as well as a stress testing it under my phd::text implementation. It worked fine as an underlying container for UTF8, UTF16. UTF32, and UTF-7-EBCDIC storage. +5000 - Standalone. I wish more Boost libraries were packed this way. I can make it not depend on Boost as a whole; great for dropping into random codebases and using as a replacement. Also compiles faster for those of us who have C++17+ capable compilers. ------------------- Weaknesses 🤒 ------------------- -1 - Naming. fixed_string<500> works, wfixed_string<500> doesn't, basic_fixed_string<char, 5000> doesn't either. It uses a different naming scheme from the standard, and led me around in circles on first use until I forced myself to read the template head of the class declaration. But it's Boost, so we can afford to be different and stuff. Just don't do static_vector. :D -0 - operator+ I wanted it. It wasn't there. I can see why, since you would have to pessimistically expand the size to the max between the two. Do enough additions and you can explode the final result's stack size several, so this isn't really a loss. Besides,-0 is just 0 on any reasonable 2's complement machine. -0 - noexcept It's 2019, everyone's getting on the noexcept train. Don't let it leave you behind! -2500 - Constexpr is lacking. I could not compile any of itsy.bitsy's constexpr, compile-time, or static_assert tests. I could not compile any of the static_assert tests from latest private text development. This prevents a wide range of applications, including my failure to substitute boost.fixed_string for Hana's Fixed String implementation in CTRE and failure to use fixed_string as a compile-time buffer for encoded and decoded text. -------------- Misc. -------------- - I see you added subview, very nice. 👏 - substr should continue to return a fixed_string. - The empty optimization and size optimization is important. Don't listen to anyone who tells you fixed_string<0> should report false for std::is_empty_v<fixed_string<0>>. I spend LITERALLY MILLIONS OF YEARS (definitely literally) programming special __ebco<T, tag> or slapping [[no_unique_address]] on things to cut down on memory sizes. Please don't cause a cascade of bloated size with MSVC's current crappy base class """optimization""" rules (the new, better ones are still opt-in because yay, ABI breaks). The closer things are to being small enough or trivial enough that they get register-passed, the better. - Speaking of the size optimization, MSVC's standard string also employs a trick where they shove the size in the last CharT. May be of use to you here, but probably not worth the efforts. -------------- Unrelated -------------- The following is boring things not related to the review but stated here for extra flavor that can be completely ignored: - Boy that CMake file hurts my feelings. I fixed it up so I could use it with add_subdirectory. It promised me an easy integration and smacked me upside the head instead. But at least I could get the tests going soon enough. Maybe don't commit it, it gives the impression it's for public consumption (it's not). - Tests are slightly inscrutable, better names would be nice. - For constexpr: use a union of { char derp; CharT value; } and value-initialize the char. Provide iterators that walk over the union and on deref directly handle you the CharT& lvalue reference. .data() is unimplementable as constexpr like this but who cares: you have a constexpr begin() and that's what people should be using. .data() is for type-punning shenanigans. - You should turn up the warnings on MSVC: there's a few places where there's an implicit narrowing thanks to going from size_type (std::size_t) to smallest_width_t and MSVC gives a snippy warning. Overall, yay! Try to get the constexpr stuff in quick; that's what's going to make this library interesting to use for C++20 and beyond, and have Boost libraries start being things to look forward to, rather than representing the Old, Boring Establishment that I reach for when I hear the words "Sea Plus Plus Oh Three". Great Job, JeanHeyd Meneide

3 3

[release][proto]: MSVC 19.24.28314 (VS 2019 16.4.0) )won't compile proto's generate.hpp
by Löw, Tobias (STEAG Energy Services GmbH) 05 Dec '19

05 Dec '19

Hi, the latest MSVC version (shipped with VS 2019 16.4.0) doesn't compile boost/proto/generate.hpp since there is an old MSVC-fix, which is no longer needed, and now even produces errors. The "develop" branch of proto contains a fix for that since 2015 (!) but it never made it to the master branch. (https://github.com/boostorg/proto/issues/20) Could some please merge it over to make it into release 1.72 - would be really great! Tobias

1 0

[review][fixed_string] FixedString review starts Nov 25
by Joaquin M López Muñoz 05 Dec '19

05 Dec '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library will take place November 25 - December 4, 2019. This is an early call for you to consider participating in the review. Feedback and constructive criciticism from experts and not-so-experts alike is very much welcome. FixedString being a relatively small and straightforward library, you will find it very easy to familiarize yourself with it and contribute back to the community. FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string If you feel like reviewing FixedString you can start now prepping --though I'd ask you to refrain from submitting actual reviews till Nov 25. Read the docs, download/fork the code, read/run it, maybe try integrating it into some project of yours, ask questions to the authors, preferrably on Boost or Boost Users mailing lists. The FixedString initiative arose from a very lively discussion within the community: https://lists.boost.org/Archives/boost/2019/09/246943.php , so I sincerely hope this review will be a fruitful, crowded one. Don't let me down! Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

5 5

Generic Image Library
by Siddhartha Sen 05 Dec '19

05 Dec '19

Being new to this, I have tried looking up the functionalities of GIL. I was thinking of implementing the addition of negative image conversion as well to GIL, incorporating the usage of parallel programming using OpenMP library. Is there any demand for that? I feel that parallel programming will massively improve the computational efficiency of GIL.

2 1

[review][fixed_string] review period extended to Dec 8
by Joaquin M López Muñoz 05 Dec '19

05 Dec '19

After conversation with the review wizards, the review period for candidate Boost.FixedString is extended till Sunday, Dec 8. Hopefully this will allow for some more reviews to come in and for the ongoing discussions to stabilize. So, if you're considering to submit your review, now is the time to reserve some time to do so. Thanks to everybody who has contributed so far, it is a very productive review we're having. Joaquín M López Muñoz Review manager for candidate Boost.FixedString

1 0

Re: [boost] [fixed_string][review] Review of fixed_string
by Peter Dimov 05 Dec '19

05 Dec '19

> - everything should ideally be constexpr. The problem here is that > constexpr requires initializing all elements, and this will heavily > penalize runtime uses of f.ex. fixed_string<512>. On compilers with > __builtin_is_constant_evaluated (gcc 9, clang 9) we should use that; > otherwise, it might be worth it to create a specialization for N < some > suitable upper limit. Wait, I have an idea. template<std::size_t N> struct fixed_string { private: std::size_t size_ = 0; union { char first_ = 0; char data_[ N+1 ]; }; public: fixed_string() = default; }; Now default initialization sets just the first char to zero, as we want, and value initialization initializes all data_ to zero and is constexpr. auto f1() { fixed_string<24> s; return s; } auto f2() { constexpr fixed_string<24> s{}; return s; } https://godbolt.org/z/uhf4S4 I don't know if that's defined behavior or not, but if it isn't, it better be.

2 1

[review][fixed_string]
by Peter Koch Larsen 04 Dec '19

04 Dec '19

Dear boosters Here is my review of fixed_string > - What is your evaluation of the design? I have just completed a similar but much less ambitious design - about 700 LOC in total. The purpose is to replace char string[N] representing string in an ageing code base that is C++98 currently and partly embedded. My design does support a partial compatibility with std::string but that was not the primary goal. The interface compatibility of std::string is a nice feature, but I do not see a reason to attempt to make it a drop-in replacement. The non-compatibility with char[N] is missed by me and probably also some other in the embedded domain. It would be nice if fixed_string<N> had size = N + 1 for char types. > - What is your evaluation of the implementation? Nice and clean. As others have noted, constexpr and noexcept support would be nice. I would also prefer if I could have an option that does not require usage of exceptions, perhaps as a configuration option. Specifically, I would like to be able to control error handling (terminate instead of throw, ability to react to undefined behaviour). Also, I would like to have more forgiving functions that could return the status of failing operations. > - What is your evaluation of the documentation? Nice and clean. > - What is your evaluation of the potential usefulness of the library? If the interface could be extended, It could potentially be useful to many - and to me - if I manage to convince my company to ugrade to C++17. So to summarize: 1) compatibility with char[N]: this requires that the size member is removed. In my source, I still have an O(1) size implemented by having data[N] give the free space in the string. If data[N] == 255, this indicates that the real free size is stored in the elements data[N - 1] and below. There are many ways to encode that length portably. 2) append and assign could have companion functions, that behave in spirit like strncpy/strncat. I have named these function try_append and try_assign. 3) Errorhandling strategy available. > - Did you try to use the library? With what compiler? Did you have > any problems? No, just reading code. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About three hours reading and writing this comment. > - Are you knowledgeable about the problem domain? Yes. > > And finally, every review should answer this question: > - Do you think the library should be accepted as a Boost library? The constexpr and noexcept parts should be fixed and compatibility with char[] would be nice. But yes, it should be accepted.

1 0

How to handle NULL string for UTF conversion function
by Alexander Grund 04 Dec '19

04 Dec '19

Hi, in my work on Boost.Nowide I encountered a valid NULL string and am unsure how to handle it. Context: Every wrapper functions is basically implemented like: int fFOO(const char* s){ wstackstring const ws(s); // Converts UTF-8 to wchar-buffer/string return _wfFoo(ws.c_str()); } Similar functions like `std::wstring widen(string-or-const-char-ptr)` are provided which can be used like `return _wfFoo(widen(s).c_str());` in the example above. All was fine, because (IIRC) calling e.g. `fopen(NULL)` is not allowed anyway. However `freopen` DOES allow a NULL for the string. So now I'm left with a couple options and would like some opinions on them: 1. Make (w)stackstring aware of NULL input and if default constructed or with NULL return NULL for c_str(). Makes it easy to use as one could even say `return _wfFoo(wstackstring(s).c_str());` w/o any checks but would be inconsistent with the `widen` functions which convert the passed pointer into a std::(w)string and hence require != NULL 2. Disallow NULL (via assert) for all conversions and require manual checking. Best usage would then probably be to ditch the temporary and do `return _wfFoo(s ? wstackstring(s).c_str() : NULL);` 3. Just like 1. but rename (w)stackstring to e.g. (w)cstring (or ncstring/wcstring, or narrow_cstring/wide_cstring) to highlight that it acts like a C-String (and can be NULL as opposed to empty but never NULL) 4. Ditch stackstring entirely. It was complained about by Zach during the review although defended by the author as "stackstring is barely on-stack buffer optimization - it isn't general string and never intended to be so. It isn't in details because it can actually be useful outside library scope." So this would worsen performance a bit as usual SSO are to small for common filenames. Thanks for reading and any insight is welcome! Alex

6 5

[fixed_string] Gavin's review
by Gavin Lambert 04 Dec '19

04 Dec '19

This is my review of the proposed FixedString library. - Do you think the library should be accepted as a Boost library? Yes, I think it should be ACCEPTED into Boost. Regarding the bikeshedding of the library/class name itself, I prefer "fixed_capacity_string", as the most accurately descriptive name I can either think of myself or that I have read posted by others. I don't think we should be afraid of longer class names, even for vocabulary types. People can always alias them to something shorter to save typing. (Second choice would be "array_string", although that risks misinterpreting as "string_array", which is something entirely different. "stack_string" is another possibility, though might be misleading if contained within another object on the heap.) - What is your evaluation of the design? Overall, looks good. I agree with the motivations for creating such a type in the first place. I would prefer if it didn't reinvent some existing storage concepts already provided by boost::static_vector (and I don't entirely buy the "reduce dependencies" arguments); however there are some other justifications for this that I do consider valid (such as static_vector not being constexpr). As previously noted, I think implementing substr to return a string_view is a mistake; this will cause lifetime problems if someone tries to drop-in replace a std::string in existing code (which was one of the motivating use cases). I'm happy with this being implemented as a new method "subview". (Maybe std::string should do the same thing...) However I still disagree with the choice to also provide "substr" but with a fixed_string return type. Its semantics (with regard to the capacity of the returned string) are still sufficiently different from std::string as to make its usage confusing and poor-performance-prone. With the method omitted, someone attempting a drop-in-replacement will get an error and will need to decide how best to handle it (usually by using subview, but this may require other changes to extend lifetime, which is why spelling subview as "substr" was bad). And if they really want a copy of the substring, they can still do that via subview simply by assigning it to a fixed_string variable -- this would also require them to explicitly choose an appropriate capacity, which I regard as a good thing. For similar reasons to the above, my preference is also to entirely omit operator+ (as in the current design). The consumer can decide how to rewrite things to use operator+= instead. (While there are ways to implement operator+, as has been discussed, all of these come with hefty caveats and I don't think a compromise is sufficiently safe.) - What is your evaluation of the implementation? I did not have time to do more than glance at the implementation. Although I did previously note (thanks to Deniz for calling attention to it) that the unconditional #define BOOST_FIXED_STRING_USE_BOOST in config.hpp is not the correct usage for configuration defines in Boost. I also think that this could make better use of Boost.Config's existing defines -- while a stated goal was to also produce a standalone library, this could be done by using Boost.Config inside of Boost and using a standalone mini-config header with equivalent defines only for the standalone build. I'm also dubious about the division of implementation between three identically-named header files. Unless this is required for avoiding-ugly-docs reasons I think it would be preferable to merge these into a single header -- and perhaps only a single header, where Boost.Config is used. Finally, though, I wonder if perhaps a variation of this type should be implemented which has as storage only the array itself without a separate size member. This might better serve some serialization or I/O scenarios (as a drop-in replacement for a raw char array), although with the caveat that it would probably have to rely on strlen-equivalents and thus could not contain embedded nulls (which is why it should be a separate type, if implemented, as this is a larger departure from std::string). As this would also typically have a smaller capacity than other use cases it could do things like zero-init which might be too expensive for the general-purpose fixed_string, but which can be very helpful for serialization scenarios. - What is your evaluation of the documentation? The documentation is very short, but seems sufficient for the small scope of the class. - What is your evaluation of the potential usefulness of the library? I think it will be extremely useful. I do wonder if an immutable_string type would also be useful (especially for constexpr), but that could be a separate library. - Did you try to use the library? With what compiler? Did you have any problems? I did not try it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading. Probably a couple of hours in total spread over the entire review period. - Are you knowledgeable about the problem domain? Yes, I frequently work on code where heap allocation is constrained or disallowed. And with strings.

3 2

[review][fixed_string] FixedString review starts today
by Joaquin M López Muñoz 04 Dec '19

04 Dec '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library starts today November 25 and extends up to December 4. Description FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. Repo and docs GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string Review questions Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? I invite you to submit your review, either publicly to the developers or the users lists, or else, if for whatever reason you don't want to go public, directly to me. Thank you for investing your time on reviewing Krystian and Vinnie's work and for contributing to the advancement of Boost. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

11 39

Error handling benchmarks: LEAF, Boost Outcome
by Emil Dotchevski 02 Dec '19

02 Dec '19

I wrote a benchmark program for LEAF and Boost Outcome. Here are the results: https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md

3 4

Reminder: Master branch closes for the 1.72.0 release on Wednesday
by Marshall Clow 02 Dec '19

02 Dec '19

See the calendar at https://www.boost.org/development/ -- Marshall P.S. Don't forget the release notes!

3 5

Interest in making template programming imperative?
by Tianjiao Yin 02 Dec '19

02 Dec '19

Hi there, Is there any interest in library that makes template programming imperative. Basically it provides following API VAR(T); // define a variable T SET(T, Type1); // Assign T = Type1 GET(T); // This macro will be expanded to Type1 SET(T, Type2); // Re-assign T = Type2 GET(T); // This macro will be expanded to Type2 The same idea applies to constexpr variable as well. I.e. it's possible to re-define constexpr variable after initialization, though this functionality is not implemented yet. - Github: https://github.com/Mizuchi/tm - Try it online: https://godbolt.org/z/yfQb4K Thanks, Tianjiao

1 0

Fixed String review
by Phil Endecott 02 Dec '19

02 Dec '19

Dear All, Here is my review of the proposed Fixed String library. In summary I think this would be a useful thing to have in Boost, but there are a few issues with the code as it currently stands. This is based on studying the code and docs and the previous mailing list discussions in September; I haven't actually tried to use the library. Firstly regarding the name, I would much prefer static_string for consistency with boost::container::static_vector and with P0843. Note that static_vector was the preferred name in an LEWG poll, according to P0843. It's true that "static" is an ambiguous word that does not really convey what is different about this string, but then neither does "fixed" in my opinion; "fixed capacity" would, but just "fixed" sounds more like "immutable" to me. On the subject of P0843, it it worth reading as it contains some useful links and rationale: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0843r2.html Also a more recent r3 update and reference implementation: https://github.com/gnzlbg/static_vector Here are the features that I think are missing, in no particular order; apologies if some of this does exist but I've missed it: - Much more of it should be constexpr. See P0980R1. That mentions that some of char_traits needs to be constexpr as a prerequisite, but even without that things like size() and empty() can be constexpr. There is also a question of whether all of the elements must be initialised (to 0) by the ctor to be constexpr, which could be costly for a large but sparse container, though it does mean that subsequent push_back()s don't need to store terminators; I don't understand all the issues involved here. (I note a comment in the docs suggesting the lack of constexpr may be temporary.) - In the same vein, more of it should be noexcept - why aren't empty() and size() ? - You can add a specialisation for size 0 that turns it into an empty struct. - You can add a string literal operator"". - You can add std::hash overloads. There are various possibilities for what should happen if the capacity is exceeded, including throwing an exception, asserting, and allowing undefined behaviour. I'm not sure what I would really prefer though I think I'd be more likely to assert() than to throw. See P0843r2 again which discusses this. Regarding your deviations from std::string: operator+ has been omitted because you consider it's not possible to determine a reasonable return type; isn't it just size N+M ? Do you reject that just because it could end up rather large after a sequence of additions? I'd agree if it were N*M but not really for N+M. Have I missed something? You've chosen to return a string_view from substr(). I think that's a bit dangerous; code that does "auto a = s.substr(...)" could end up with a dangling view when s is a fixed string; this makes it more difficult than it should be to migrate from one string type to another, or to write generic code. Regarding the docs, it would be great if the reference could have some highlighting (e.g. bright red?) for the few places where it differs from std::string. My own use for this sort of string has often been to store very large numbers of small strings when total memory usage has been a concern. (A good example would be an textual ID code of some sort, like a postal code or an airport code etc.) For this case, the 8-byte overhead for the size_t length field is a concern; I'd like a static_string<6> to need only 8 bytes total. I suggested changing this to the minimum size needed to store values 0 to N in the previous email discussion, but that hasn't been implemented. My initial thought was that static_string should be implemented on top of boost::container::static_vector<char>. My rationale for that was that static_vector is well-established and doesn't need to be re-implemented, and that a string_facade that adapts a vector<char>-like interface into a string-like interface would be a useful component in its own right. (I've tried to write something like this myself, but it gets tedious very quickly writing out all of those special string methods.) But then I discovered that actually boost::container::static_vector is not implemented as a simple size,data[] pair; apparently it contains pointers to its own storage. So it isn't even trivially- copyable. Now that I know that, I wonder if what we really need is a low-storage-overhead static_vector "done properly" (like the P0843 reference implementation), with a string_facade to make static_string from static_vector<char>. On balance, my view is that this proposal is promising but not quite ready yet. I suggest that the authors should be asked to come back in a few months with a revised version. My preferred design would be an improved static_vector and a string_facade that converts it into a static_string, but if they don't want to do that then simply tidying up the constexpr, noexcept and hash issues would be minimally sufficient. Regards, Phil.

9 23

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 02 Dec '19

02 Dec '19

> This one at least does something: > > http://quick-bench.com/g_-BAIENMHQ1Pi1d136FBdp0idQ > > It still measures nothing though; the string isn't actually written. Finally, this one actually bothers to write the characters: http://quick-bench.com/-FUFkLtQeEa3brMf-y139G3Bbcg Quickbenches aren't very representative.

1 0

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 02 Dec '19

02 Dec '19

> Wait, I forgot to increment the size! > > http://quick-bench.com/sI71NY7OpQ8ft27HpELko8q_4xM > > Not much improvement anyway. This one at least does something: http://quick-bench.com/g_-BAIENMHQ1Pi1d136FBdp0idQ It still measures nothing though; the string isn't actually written.

1 0

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 02 Dec '19

02 Dec '19

> > Zach Laine wrote: > > Ok, I tried this myself on Quickbench: > > > > http://quick-bench.com/WZPNHFBKI-hFxThBYRZVjndtBho > > I tried to fix that to add the null terminator, but as a result both > push_backs were entirely optimized away. > > http://quick-bench.com/DtPR9Yov1TSzUFeYRx0ipVvUYBk Wait, I forgot to increment the size! http://quick-bench.com/sI71NY7OpQ8ft27HpELko8q_4xM Not much improvement anyway.

1 0

Boost 1.69 on Fedora/PPC64LE: tests results
by REIX, Tony 02 Dec '19

02 Dec '19

Hi, I'm testing Boost v1.69 on Fedora 31 / PPC64LE , as explained at: https://www.boost.org/development/running_regression_tests.html And I see many errors: 1 Failed test out of about 11 Run tests: # cd status # ../b2 ... Passed 101532 tests Failed 10368 tests 90.7% of tests completed sucsessefully Passed 1188 tests Failed 15 tests 98.8% of tests completed sucsessefully I do not know what I made wrong. So, since I do not see any Fedora/PPC64LE machine in the BuildFarm: https://www.boost.org/development/tests/master/developer/summary.html I'd like to know where I could find the summary of the official tests of Boost 1.69 on Fedora/PPC64LE. Thanks/Regards, Tony Reix

1 0

Matrix Multiplication
by Siddhartha Sen 01 Dec '19

01 Dec '19

Having gone through quite a few libraries, the ones that intrigued me the most are Boost.Algorithms and Boost.GIL. I had an idea for Boost.GIl in fact. Basically what I wish to propose(please do correct me if it already exist) is a library that will have the functionality to convert a image to a negative one (I found the conversion of colour image to black and white functionality, but not this). Also, the process can be massively sped up by the incorporation of parallel programming paradigms like OpenMP. Do let me know what you guys think about this.

1 0

[fixed_string] Why "fixed" rather than "static"?
by Andrzej Krzemienski 29 Nov '19

29 Nov '19

Hi Everyone, First, I would like to thank Vinnie and Krystian for writing and sharing the library. While this is not a review, I would like to share a thought about the choice of name. Given that we have static_vector, which seems to be doing a similar thing, why was this library called fixed_string rather than static_string? I note that name fixed_string has some potential to mislead the users as it might imply that it is the size that is fixed (like "a string that always stores 2-letter country codes"). I am not saying that the name choice is wrong. I would just want to see the rationale. Regards, &rzej;

5 8

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 29 Nov '19

29 Nov '19

> and yes, you can write code that will be correct if op+= doesn't check. Maybe you can, but I apparently can't. This is what I just wrote: void my_append( fixed_string<512> & s, std::string_view s1, std::string_view s2 ) { if( s.size() + s1.size() + s2.size() > s.max_size() ) throw std::length_error( "" ); s += s1; s += s2; } Is this correct? (Spoiler: no.)

2 2

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 29 Nov '19

29 Nov '19

> https://godbolt.org/z/Z37Pmx > https://godbolt.org/z/CXHRKQ I forgot to maintain a 0 terminator in this sketch; it's even worse with it. .L5: add rax, 1 movzx ecx, BYTE PTR [rdx] cmp rax, 512 ja .L11 add rdx, 1 mov BYTE PTR [rdi+7+rax], cl mov BYTE PTR [rdi+8+rax], 0 mov QWORD PTR [rdi], rax cmp rsi, rdx jne .L5 https://godbolt.org/z/nhYZQY .L3: movzx ecx, BYTE PTR [rdx+rax] mov BYTE PTR [rdi+8+rax], cl add rax, 1 mov BYTE PTR [rdi+8+rax], 0 mov QWORD PTR [rdi], rax cmp r8, rax jne .L3 https://godbolt.org/z/pGJRWs

1 0

Re: [boost] [review][fixed_string] FixedString review starts Nov 25
by Peter Dimov 28 Nov '19

28 Nov '19

> Also, a synopsis section in the documentation might have been nice, to > allow one to see all the declarations in one place. (Admittedly, the main > header does serve that purpose somewhat.) I join the others in noting the pervasive lack of constexpr and noexcept. Even the default constructor isn't either. Can't think of a reason why it would throw. (The lack of constexpr is much easier to explain.) Also, Traits template parameters were wrong in C++98, and they remain wrong today, even though the committee has propagated that mistake into string_view.

2 1

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 28 Nov '19

28 Nov '19

> I would "precondition" `op+=( char const (&)[ M ] )` (and op=) by failing > at compile time when M > N, because the size is known, but in > fixed_string's case, the size isn't known. No I wouldn't. :-) The size isn't known in this case either. It's better to diagnose_if the whole thing.

1 0

[STLInterfaces] only three operations?
by Andrzej Krzemienski 28 Nov '19

28 Nov '19

Hi, While the formal review of STLInterfaces has not yet started, some early feedback may be of help. The idea to implement relational operators from binary operator- for random_access_iterator looks too clever for me. Maybe this deserves a mention in the documentation it is from operator- that the library will generate all relational ops. For non-contiguous random_access_iterators (like in deque) it might be suboptimal to do it this way: a directly provided operator== might be faster than the one synthesized from operator-. Of course, I can provide the 6 relops operators myself, but I could have only 2 if the facade were capable of generating operator!= from operator== (and similar). Could operator!= for random_access_iterator be generated from operator!= ? Regards, &rzej;

3 5

[FixedString] Deniz' review
by Deniz Bahadir 27 Nov '19

27 Nov '19

This is my review of Krystian Stasiowski and Vinnie Falco's FixedString library. The important question and its answer upfront: - Do you think the library should be accepted as a Boost library? I think it should be ACCEPTED into Boost. It is a very small (almost trivial) library and in the beginning I was not sure if it really should go into Boost. However, for me it looks like a useful building-block, so I vote ACCEPT. And if I remember correctly Vinnie said he is already having some other libraries using it which he wanted to propose for Boost later, so there seem to be some real use-cases for it already. Besides, Boost already has some other smaller building-block libraries, so FixedString should be in good company. On a side-note: It would be helpful for the Boost library documentation overview (e.g. https://www.boost.org/doc/libs/1_71_0/) to allow more views/sort-orders for listing available Boost libraries than the views/sort-orders which are already there. (Having "building-blocks" and especially "newer C++ standard features for C++03" or similar "standard compatibility" categories for the Boost libraries comes to mind.) OK, now back to the review. - What is your evaluation of the design? The overall design looks straight forward. `boost::fixed_string`'s API resembles that of `std::string` and only the internal representation differs largely. This looks like the correct design for the aimed purpose of this library (to provide a dynamically resizable string with compile-time fixed capacity.) - What is your evaluation of the implementation? The implementation looks solid and also straight forward. However, I have some remarks to make which you can read further down in this email. - What is your evaluation of the documentation? The documentation is quite small, except for the reference section. This, however, should be fine considering the very simple and small focus which FixedString has. Regarding the "Iterators" section, it was not clear to me on first read for which string type the iterators are invalidated when moving/swapping. I think, `boost::fixed_string` is meant and not `std::string`, but that was not obvious from first read and the wording should probably be improved there to be unambiguous. (Maybe make this clear by speaking of "FixedString" or "fixed_string" instead of just "string".) - What is your evaluation of the potential usefulness of the library? For the use-cases mentioned in the "Motivation" section of the documentation it seems to be useful. All other use-cases I could think of are specializations of the mentioned use-cases. - Did you try to use the library? With what compiler? Did you have any problems? No, I have not tried to use the library. However, I am curious to know if Boost.String_Algorithms can operate on `boost::fixed_string`, too. If not, it would be nice for the code of FixedString and/or Boost.String_Algorithms to be modified in such a way that they can inter-operate with each other. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the documentation, but the reference section I merely visually scanned through. (I assume, there are no mistakes in it, as they mainly resemble the API of `std::string`.) I looked at the implementation but did not look at all function implementations in all depths. I, however, looked at the CMakeLists.txt file, too, and have some remarks for it (see below). Overall, I probably spent about 1.5 hours for the review, not including the writing of this email. - Are you knowledgeable about the problem domain? Only as far as it gets if you are a general user of `std::string`. I have the following additional remarks: * `boost::to_fixed_string` / `boost::detail::max_digits`: - Is the returned `boost::fixed_string` type of `boost::to_fixed_string` large enough to also hold the (plus) sign of an unsigned integer (if a user might want to append it later)? (Reading the comment and implementation of `boost::detail::max_digits` I assume the answer is yes.) Maybe, make this clear in its reference documentation. * "boost/fixed_string/config.hpp": - At the top of this file we have `#define BOOST_FIXED_STRING_USE_BOOST`, which therefore makes all following conditional definitions always use Boost equivalents of standard library types internally. Is it really desired to have it hard-coded here? Shouldn't the user decide if s/he wants to use Boost compatibility types instead of the ones coming from the standard library? * Filenames - I do not really like, that all files have the same name "fixed_string.hpp". There is the main one in "boost/fixed_string", another one in "boost/fixed_string/detail" and a third one in "boost/fixed_string/impl". I would prefer these files having some (at least slightly) different names. * "CMakeLists.txt": - This CMakeLists.txt file is written in Traditional CMake (old style CMake) although requiring CMake 3.5.1 which knows how to handle Modern CMake. You should consider using Modern CMake instead. - You should leave `CMAKE_CXX_FLAGS` untouched. It is for the user of the library, not for the developer! - Similar, set requirements for a specific minimum required C++ version using the `CXX_STANDARD` property instead of hard-coding it into `CMAKE_CXX_FLAGS`. - You should probably replace usage of `include_directories` with `target_include_directories` on the specific targets. - Similar for `add_definitions` and `link_directories`. - Using `file(GLOB...)` for globbing sources is dangerous and CMake might not always realize that some sources have changed. (see note at: https://cmake.org/cmake/help/latest/command/file.html#glob) - In general, I am not sure if that CMakeLists.txt file should have been part of the review, but I recommend to provide a useful and more modern one if this is going to become a part of Boost, too. Best regards, Deniz

6 10

Suggested policy for dropping C++03 support in Boost libraries
by Peter Dimov 26 Nov '19

26 Nov '19

We need a policy on phasing out C++03 support in Boost. C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times. Library authors and maintainers need to have an approved mechanism for dropping C++03 support in their libraries. The suggested way forward is to allow library authors to declare C++03 support deprecated via a notice in the documentation and a message issued at compile time, then be allowed to drop C++03 support no earlier than three Boost releases later. For instance, a library may declare C++03 support deprecated in Boost 1.73, and drop it no earlier than in Boost 1.76. More at https://pdimov.github.io/articles/phasing_out_cxx03.html.

12 21

Beginner's guide
by Siddhartha Sen 26 Nov '19

26 Nov '19

Could anyone help me get started? This is my first time contributing to open source. I am proficient with C++11 and C++14(Not so much with 17 though). Also, I am not sure whether this is useful or not but I have a very keen interest in algorithms and problem solving techniques in general. Any help would be appreciated.

3 2

Re: [boost] [Boost-users] Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 25 Nov '19

25 Nov '19

Thanks for your valuable feedback. I added initial versions of tutorial and user-guide to README. It's not ideal yet but it's a start. * https://github.com/boost-experimental/ut#tutorial * https://github.com/boost-experimental/ut#user-guide I also updated benchmarks with Boost.Test-1.71.0 (static library). I didn't add Boost.LightweightTest though as it's just assertions (no tests/suites/etc...) so it makes it difficult to compare due to missing features. * https://github.com/boost-experimental/ut#benchmarks I hope that helps a bit. Thanks again, Kris On Fri, Nov 22, 2019 at 1:17 AM Richard Hodges via Boost-users < boost-users(a)lists.boost.org> wrote: > It looks very interesting. The idea of not using macros is very appealing > to me. > > From looking at the examples, I get the feeling of "I could probably use > this". > > However, as the other commenters have mentioned, without a tutorial and > full reference it's difficult to judge whether it's ready for use in > production. > > Are there plans to develop this? > > > > > On Thu, 21 Nov 2019 at 16:24, Krzysztof Jusiak via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> Hi, >> >> I was wondering whether there is any interest in exploring a C++20 single >> header/single module, macro-free Unit Testing Framework with no >> dependencies? >> >> Github: https://github.com/boost-experimental/ut >> >> Additional links: >> - Try it online: https://godbolt.org/z/uVDxkW >> - Benchmarks: https://github.com/boost-experimental/ut#benchmarks >> - How it works?: https://github.com/boost-experimental/ut#how-it-works >> >> Thanks, Kris >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> https://lists.boost.org/mailman/listinfo.cgi/boost-users >> > > > -- > Richard Hodges > hodges.r(a)gmail.com > office: +442032898513 > home: +376841522 > mobile: +376380212 > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 2

[review] [STLInterfaces] STLInterfaces review starts December 10
by Barrett Adair 23 Nov '19

23 Nov '19

The Boost formal review of Zach Laine's STLInterfaces library will take place December 10 - 19, 2019. Please consider participating in this review. The success of Boost depends on our robust library review process. STLInterfaces is a C++14 library targeting ISO standardization. The following templates are provided, all C++20-friendly: 1. iterator_interface - a modern version of the iterator_facade and iterator_adaptor parts of Boost.Iterator 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature 3. container_interface - a tool to eliminate boilerplate when writing new containers. Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett Adair

1 0

icl
by Andreas Fislage 22 Nov '19

22 Nov '19

Hello all, I am new here... I recently used icl and ran into a rather surprising behavior: Assertion failed: (numeric_minimum<domain_type, domain_compare, is_numeric<domain_type>::value> ::is_less_than_or(upper(object), is_right_closed(object.bounds())) ), file ...\boost\icl\concept\interval.hpp, line 438 This is the code to produce the problem: #include <boost/icl/discrete_interval.hpp> int main() { boost::icl::discrete_interval<size_t> x{0, 0}; boost::icl::discrete_interval<size_t> y{0, 1}; boost::icl::contains(x, y); } Note that the assertion fails only with size_t not with int. What could be reason for this?

1 0

Boost serialization (bug?) issue with MSVC, with vector<shared_ptr> in several libraries
by Nicolas Guillot 22 Nov '19

22 Nov '19

We use boost serialization in ours projects, both on linux (gcc) and Windows. We encounter a problem only on Windows (for "every" versions of Windows (7 and 10) and of MSVC: Visual 2010 and 2015, ie. MSVC++ 10.0 _MSC_VER == 1600 or MSVC++ 14.0 _MSC_VER == 1900). *Here is the problem summarized*, but I need to give more details after: When I serialize a class - which have base class - and have 2 vector of shared_ptr of ClassB, with the same contents, and B inherits from the same base class the serialization works, but the deserialization doesn't ("input stream error"). The following image is here : https://i.stack.imgur.com/osoiF.png (if it's not displayed) [image: enter image description here] <https://i.stack.imgur.com/osoiF.png> Yes, it's very strange: - if I remove the base class, it works. - if I inline the serialization code (empty function) of the base class, it works. - if the 2 vectors don't have the same content, it works !! - if I register the ClassBase in the serialize method of ClassTest, it works. I.e.: // in ClassTest:template <class Archive>void serialize(Archive & ar, const unsigned int version) { ar.template register_type<ClassBase>(); ...} *Some details* *When it works* on linux, and when it works on Windows with ClassBase type registration in the archive, we have the same xml output. It's worth noting that: - boost_serialization is version 17 on Windows and 9 on linux (I didn't tried to update boost on linux yet). - On BaseClass xml tag, the tracking_level="1", so we have object_id. *And when it doesn't work* (once again: the serialization of ClassTest is OK, but cannot deserialized "input stream error"): - The main difference is in the serialization of ClassTest: the ClassBase part has no tracking_level. - However it's not the only cause, because if the vectors are differents (same 2 first items, and a third item in one vector), tracking_level of ClassBase in ClassTest part is "0". Last thing, if it can give you some clues: while we debugged our application, we noticed that the deserialization framework tries to deserialize a class into another. It makes me think the serialization framework is confused about the classe types identifications. Could it be a matter of dll linking? Of global static shared storage ? I've posted a visual studio solution here <https://1drv.ms/u/s!Aoy4ax0S3ZS5gkxv1UIvRUd32oVO?e=ACVi4c>. Thanks a lot for your help. And if any clarification is needed, I'm available of course !

2 3

[xpressive] Accept one line pull that's been outstanding for a couple years?
by Brian Kuhl 21 Nov '19

21 Nov '19

Hi Boost, We've been running nightly regression on this for years now at Wind River over a couple Boost releases. Any reason it can't be merged? https://github.com/boostorg/xpressive/pull/5 Thanks Brian

1 0

Re: [boost] Jason is getting MARRIED!
by julien.blanc＠tgcm.eu 21 Nov '19

21 Nov '19

"Vinnie Falco" vinnie.falco(a)gmail.com – 21 novembre 2019 15:29 > Yep, the bench program and input files are here: thanks. I'll try to compile it for raspberry pi and report the results here. > > A 200MB file would be a good start to see how the library deals with large files. > > I don't have a 200MB JSON file, and I have doubts that it would > provide much more information than what we have already. I'd also > prefer not to put a 200MB file into the repository. The goal of this > library is to be in the same ballpark as rapidjson, it doesn't try to > be the top performer (in fact, rapidjson achieves its performance by > making usability tradeoffs which are unsuited for vocabulary types). > > However if someone wants to run the bench program on a 200MB file or > any other custom inputs and report the results, that would be great! Just made the test, and the validator performs well (memory consumption is about the size of the file, which i is expected since the whole file is read in memory), while the printer memory usage was huge (i had to stop it, but it was at that time already eating more than 1Gbyte memory, which is not expected). Regards, Julien

2 1

istream_iterator_limited
by Frederick Gotham 21 Nov '19

21 Nov '19

[MODERATOR: I tried to post this a week ago, but for some reason the word SPAM was prefixed to the subject line and so it didn't show up on the GMane server. I don't think many people actually saw it.] - - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 1

[release] Boost 1.72.0 Beta 1
by Michael Caisse 21 Nov '19

21 Nov '19

Boost release 1.72.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1/source/> The SHA256 checksums are as follows: 5a6b5cbd27b8ca0c7741b715e022a3bf05aecbb1e73dc72dd82eef9622374bd5 boost_1_72_0_b1.7z 6c85a7aed198757f5e4be66a971ae90a25c4ce32703fecfb5bb19019bd80947c boost_1_72_0_b1.tar.bz2 be4a3fdaa84d5a8b25863651043308e02645f3fbf772b7623ee6462fb1dbad09 boost_1_72_0_b1.tar.gz 95181a5f3de0078b8fc031f63a4dc8be4d70b7d3d5cde3b266d2cd98bd4b61b0 boost_1_72_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_72_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[release] Boost 1.72.0 Beta 1 Release Candidate 2
by Marshall Clow 21 Nov '19

21 Nov '19

Boost release 1.72.0 beta 1 rc2 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1.rc2/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: 5a6b5cbd27b8ca0c7741b715e022a3bf05aecbb1e73dc72dd82eef9622374bd5 ./boost_1_72_0_b1_rc2.7z 6c85a7aed198757f5e4be66a971ae90a25c4ce32703fecfb5bb19019bd80947c ./boost_1_72_0_b1_rc2.tar.bz2 be4a3fdaa84d5a8b25863651043308e02645f3fbf772b7623ee6462fb1dbad09 ./boost_1_72_0_b1_rc2.tar.gz 95181a5f3de0078b8fc031f63a4dc8be4d70b7d3d5cde3b266d2cd98bd4b61b0 ./boost_1_72_0_b1_rc2.zip Changes since RC1: * Fix Boost.IOStreams to allow compilation on Mac OS w/LZMA support. Please download the beta release candidate, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 2

[release] Boost 1.72.0 Beta 1 Release Candidate 1
by Michael Caisse 18 Nov '19

18 Nov '19

Boost release 1.72.0 beta 1 rc1 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1.rc1/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: 3dd80fc3979c312bf892398c35778d821f6744a7fbf76c8248c85b4f3702e4d4 boost_1_72_0_b1_rc1.7z 676e476a2a1246c7c5e8f40230fa70469f29dfe8aaa5bce0a85f94692e605c68 boost_1_72_0_b1_rc1.tar.bz2 e62e5fdffe0772309c77fc9463a95350ebcabb2ce03f2c6ee177123016756044 boost_1_72_0_b1_rc1.tar.gz e3199f3f5046541570fffacd804d736e1999cfac05df6cc054ec97c8098d000d boost_1_72_0_b1_rc1.zip Please download the beta release candidate, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8

回复：Re: [release] Boost 1.72.0 Beta 1 Release Candidate 1
by ckgppl_yan＠sina.cn 18 Nov '19

18 Nov '19

I can compile this release in my macOS catalina, 10.15.1. I don't have lama installed in my OS, so I didn't have the issue below.only some warnings out. Thanks Liang----- 原始邮件 ----- 发件人：Marshall Clow via Boost <boost(a)lists.boost.org> 收件人：turkanis(a)coderage.com, Michael Caisse <mcaisse-lists(a)ciere.com> 抄送人：Marshall Clow <mclow.lists(a)gmail.com>, "boost(a)lists.boost.org List" <boost(a)lists.boost.org> 主题：Re: [boost] [release] Boost 1.72.0 Beta 1 Release Candidate 1 日期：2019年11月19日 04点38分 This appears to be https://github.com/boostorg/iostreams/issues/102, and https://github.com/boostorg/iostreams/pull/103 is a suggested fix. -- Marshall On Mon, Nov 18, 2019 at 11:56 AM Marshall Clow <mclow.lists(a)gmail.com> wrote: > On my Mac, I the version of LZMA that I have installed (via homebrew) does > not have the multi-tasking calls (_lzma_cputhreads and > _lzma_stream_encoder_mt). > It identifies itself: > > $ cat junk.cpp > #include <iostream> > #include "lzma.h" > > int main() { > std::cout << LZMA_VERSION << std::endl; > } > > $ clang++ junk.cpp && ./a.out > 50020042 > $ > > Changing libs/iostreams/src/lzma.cpp thus solves enables things to build: > > #ifndef BOOST_IOSTREAMS_LZMA_NO_MULTITHREADED > - #if LZMA_VERSION < 50020002 > + #if LZMA_VERSION <= 50020042 > #define BOOST_IOSTREAMS_LZMA_NO_MULTITHREADED > #endif > #endif > > -- Marshall > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Required C++ version in meta/libraries.json
by Mateusz Loskot 18 Nov '19

18 Nov '19

Hi, How can I specify required version of the standard in the library meta info? Where is documentation of libraries.json schema? I've learned that "std":"C++17", for example, in Boost.Any states which standard adopted the library. That is not what I'm after. -- Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting)

1 1

Jason is getting MARRIED!
by Vinnie Falco 18 Nov '19

18 Nov '19

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? Thanks!

3 4

pulling the plug on Boost Library Incubator
by Robert Ramey 17 Nov '19

17 Nov '19

I've been maintaining the Boost Library Incubator (www.blincubator.com) for some years now. Maintaining is sort of mis-nomer since it not required any change for years now. I never, ever touch it. I was painful to get to that point though. My motivation is the continuing evolution of github which I believe has come to embody almost of the goals I've had for the inclubator. I would like a couple of tweaks to git hub - or maybe just some changes in our usage of it. For example I'd like to see us proliferate the tags #Boost and #ProposedForBoost to help us search stuff but basically I believe that it has made boost library incubator obsolete. So I'm inclined to terminate it when the domain comes up for renewal the next time. Currently it has about 200 page views / day. I don't really know how much of that a bots/rss feeds and the like. I do you a service which detects and filters out almost all the obvious bogus hits, but still one never knows. BTW - the tipping point for me is the addition of "sponsership" to github. This looks to be the realization of an idea which I've promoted for many years in one for or another. I would like to successful open source project developers and maintainers get rewarded financially rewarded for their efforts and I see that git hub promoters seem to share this view - and they're in a position to move it toward reality. When I can't sleep at night, I imagine that microsoft looked at the incubator and copied features from it into the git hub. Feels like I'm dreaming so I don't feel like I'm awake anymore. Robert Ramey

1 0

Re: [boost] Jason is getting MARRIED!
by Peter Dimov 17 Nov '19

17 Nov '19

> or even `{ "size": 3, "data": [ 1, 2 ] }`. Er, "size": 2 obviously. :-)

1 0

Fwd: Markdown to Quickbook
by Mateusz Loskot 15 Nov '19

15 Nov '19

As boost-docs may not be as popular among subscribers as the development list, I'm bumping my chances for solution... ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 11 Nov 2019 at 21:25 Subject: Markdown to Quickbook To: <boost-docs(a)lists.boost.org> Hi, Is there an established known method for converting a Markdown document to Quickbook dokument? Best regards, Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting) -- Mateusz Loskot, http://mateusz.loskot.net

3 3

Removing old branches
by Edward Diener 15 Nov '19

15 Nov '19

I received an issue about Boost PP having lots of old branches which the issuer would like removed. I notice most other Boost libraries also have lots of old branches. Is there any policy about removing these old branches from a Boost library repository ? Many of these old branches are svn-branches, but most of them do not have any value any more and, of course, do not affect the current 'develop' or 'master' branch.

5 7

[preprocessor] Testing C++ standard macro examples
by Edward Diener 14 Nov '19

14 Nov '19

I have added to the 'develop' branch of Boost PP an 'explicit' test with the alias of 'test_iso' in the 'test' subdirectory. This test, depending on the compiler toolset and C++ standard setting used, will test a compiler's ability to expand correctly the macros listed in a C++ standard document's "Macro Replacement" section for C++ standards 2003, 2001, 2014, 2017, and 2020 ( N4835 ). The test uses the __cplusplus setting and the Boost PP BOOST_PP_VARIADICS setting to determine which C++ standard's set of macros to test. This is because the __cplusplus setting alone is misleading for a number of compilers, most notably vc++ and compilers who mimic vc++, who do not set the correct __cplusplus setting for the C++ standard level being used. There are really only three sets of macros from the C++ standard documents which can potentially be tested, despite five different standards being considered. This is because the set of macros to be tested for C++11, C++14, and C++17 are exactly the same. Some compilers do allow C++20 support but do not implement the full __VA_OPT__ support yet, so these compilers will fail the C++20 macro tests with compiler errors. Among these are gcc and vc++, who both document that they do not yet support the stringizing operator with the __VA_OPT__ parameter. Clang also supports C++20 and will run the test and succeed in that mode. You can of course test any compiler at any C++ level and view the results. These tests, unlike Boost PP, do not have any workarounds for any compilers. So the tests form a really good basis for reporting macro expansion preprocessor bugs to various compiler implementations. In the 'test' subdirectory of Boost PP you should be able to run: b2 toolset=atoolset cxxstd=astandard( optional ) test_iso to get the results for any compiler. Any failed results will show the test output, where the original expression, the expanded expression, and for individual failed tests the expected expanded expression will be shown. The actual macros being used are in the appropriate C++ Standard documents or can be seen in the test program which is called cpp_standard.cpp in the same 'test' subdirectory. After the upcoming release I will push this to the 'master' branch. Please note that the test is an 'explicit' test so it is not normally run when you just run the tests for Boost PP.

1 0

fixed_string: Request for review
by Krystian Stasiowski 13 Nov '19

13 Nov '19

Hi all, My name Is Krystian Stasiowski. I'm currently attending college as a Computer Science major, am active on the C++ Language Slack, and starting to contribute to ISO C++. Vinnie offered for me to take the lead on submitting Boost.FixedString for a formal review, so here I am! Applicable links: Github: https://github.com/18 Repo: https://github.com/18/fixed_string Docs: https://18.github.io/doc/fixed_string

2 1

Late fix for Boost PP
by Edward Diener 12 Nov '19

12 Nov '19

I had added support in the Boost PP library in C20 mode ( __cplusplus > 201703L ) for the __VA_OPT__ construct and enhanced an internal function used fairly extensively in the library to use this functionality in c20 mode when __VA_OPT__ was supported. I had tested this against the compilers which I knew could operate in c20 mode, gcc and clang, and all was well. I just discovered that the vc++ compiler can also work in c20 mode in Boost PP as defined above if you pass the '/std:c++latest' and the '/Zc:__cplusplus' command line switches and that vc++, in its usual non-standard way, blows up badly when doing so using the preprocessor library because it can not handle the rather simple code that checks for __VA_OPT__ support in c20 mode. I have a simple fix for this which is to turn off the __VA_OPT__ support and __VA_OPT__ support checking in c20 mode specifically for vc++ and removes which I have pushed to 'develop'. Can I push this fix to the 'master' branch now ? The fix needs to get in the coming release or else vc++ programmers specifying both the '/std:c++latest' and the '/Zc:__cplusplus' command line switched will not be able to use Boost PP and the many libraries which use Boost PP in the upcoming release. I apologize for the seeming aggressiveness of this change, which incorporated the c20 __VA_OPT__ support internally in some much-used Boost PP functionality when c20 mode is being used, but I did not anticipate that it would blow up on me, although maybe I should have. I can also remove that internal dependency with a very simple one-line change. I realize that Boost PP stability has to be maintained, even in c20 mode for the few compilers which support that mode and apologize again that I have endangered it there.

1 1

Re: [boost] [Boost][Proposal] library for enhanced switch syntax.
by рустам абдумаликов 12 Nov '19

12 Nov '19

Phil Endecott wrote: > Specifically thinking about strings, there are numerous ways > that it could be done. Starting with > (1): the obvious sequence of if-else-if: > ... > (2): binary search using nested switches: > ... > (3) character-by-character comparison using nested switches: > ... > (4) converting to a 64-bit integer, for strings of up to 8 characters: > ... Firstly my implementation was never particularly about string in "switch" it is just one of the applications. Secondly, example 3-4 assume additional implementation( can take quite a time to do it right ), it isn't like you have it out of the box, this is exactly what my statement was about( example 1-2 don't count, they are non-scalable ). Lets rather consider something that is more complex: -- Example_1 "Parse file by extension": switch( hash_it( get_file_extention( file_name ) ) ) { case "cpp"HASH: case "cc"HASH: case "c++"HASH: case "cxx"HASH: case "C"HASH: { ... } break; case "hpp"HASH: case "hh"HASH: case "h++"HASH: case "hxx"HASH: case "H"HASH: { ... } break; } // OR // I think this way it is much readable eswitch( get_file_extention( file_name ) ) >> case_( any_from( "cpp", "cc", "c++", "cxx", "C" ) ) >> [&]{...} >> case_( any_from( "h", "hpp", "hh", "h++", "hxx", "H" ) ) >> [&]{...}; // OR // even this could be possible( but not yet implemented ) eswitch( get_file_extention( file_name ) ) >> case_( "cpp", "cc", "c++", "cxx", "C" ) >> [&]{...} >> case_( "h", "hpp", "hh", "h++", "hxx", "H" ) >> [&]{...}; -- Example_2 "Parse HTTP header with Regex": // O_o too much boilerplate if( std::regex_match( line, "^.+ 200 .+$"_r ) ){...} else if( std::regex_match( line, "^.+ 404 .+$"_r ) ){...} else if( std::regex_match( line, "^.+: .+$"_r ) ){...} else { terminate(); } // OR // I think this way your intention is clearer eswitch( line ) >> case_( "^.+ 200 .+$"_r ) >> []{...} // match for "HTTP/1.1 200 OK" case_( "^.+ 404 .+$"_r ) >> []{...} // match for "HTTP/1.1 404 Not Found" case_( "^.+: .+$"_r ) >> [&]{...} >> // match for "key: value" default_ >> []{ terminate(); }; -- Example_2 "match in range of values": // Error prone approach if( value >= 1 && value <= 10 ){ Print("Value in a range[1,10]"); } if( value >= 11 && value <= 20 ){ Print("Value in a range[11,20]"); } else { Print('?'); }; /// OR eswitch( value ) >> case_( _1.in( 1, 10 ) ) >> []{ Print("Value in a range[1,10]"); } >> case_( _1.in( 11, 20 ) ) >> []{ Print("Value in a range[11,20]"); } >> default_ >> []{ Print('?'); }; // _1 it is lazy index mapping for the params in eswitch I my opinion "eswitch" looks more readable, more intuitive, less error prone and furthermore it is extensible. P.S. Here https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… I had described why I think it is important( just in case you've missed it ).

3 4

[release] 1.72.0 closed for Beta
by Michael Caisse 11 Nov '19

11 Nov '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_72_1.q…> Thanks, -- The Boost Release Team

4 4

[Boost][Proposal] library for enhanced switch syntax. Request for Comments
by рустам абдумаликов 11 Nov '19

11 Nov '19

Hi All, I wrote a library *eswitch* which provides enhanced functionality for* C++ switch*. Please take a look and leave your comments. *=====================* *Motivation:* *=====================* To overcome "*native switch*" limitations: - one parameter per "*native switch*" - the parameter restricted to only *integral *types( int, char, enum ... ). "*eswitch*" supports any number of parameters and almost without restriction on their *type*, as long as the *type *is comparable( i.e. has* operator==* ). *=====================Why it is important?=====================* Here is the most viewed questions on the *stackoverflow*: FEATURE VIEWS Multiple conditions in switch case <https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement> 850k Switch for string <https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-…> 693k Case match in range <https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu…> 133k Over a million views indicate how many people out there are disappointed with limited functionality of "*native switch*". Building parallels with such operators as "*if*"/"*while*"... it is expected by default that "*native switch*" should have the same possibilities: - be able to work with *non-integral* types as well - be able to compose complex conditions like we do in other operators " *if*"/"*while*"... Unfortunately it is not the case up till now. There was a proposal in 2013 *Relax switch statement <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html>*, and committee agreed about importance of this topic. There also was *StringSwitch <http://llvm.org/doxygen/classllvm_1_1StringSwitch.html>* implementation by *LLVM *and *Case ranges <https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html>* non-standard extension which is supported by *gcc*, *intel C/C++* and *clang*. Nevertheless, we still don't have common and universal solution. People want to overcome current "*native switch*" limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed *eswitch <https://github.com/rabdumalikov/eswitch_v4>* functionality part of the *Boost-Library *will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. *=====================repository:=====================* https://github.com/rabdumalikov/eswitch_v4 *=====================References:=====================/// "switch for non-integral" on stackoverflow* 1. https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-… 2. https://stackoverflow.com/questions/16388510/evaluate-a-string-with-a-switc… 3. https://stackoverflow.com/questions/5452188/switch-case-statement-in-c-with… 4. https://stackoverflow.com/questions/19273092/character-in-switch-statement-c 5. https://stackoverflow.com/questions/4165131/c-c-switch-for-non-integers 6. https://stackoverflow.com/questions/27536575/switch-case-on-char */// "Multiple conditions" on stackoverflow* 7. https://stackoverflow.com/questions/8644096/multiple-conditions-in-switch-c… 8. https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement */// "Ranges in case" on stackoverflow* 9. https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu… */// "Case ranges" - non-standard extension* 10. https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html */// LLVM "StringSwitch"* 11. http://llvm.org/doxygen/classllvm_1_1StringSwitch.html */// "Relax switch statement" proposal* 12. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html */// "N3627 Relaxed switch statement" c++ committee status* 13. https://cplusplus.github.io/EWG/ewg-active.html *Best Regards.*

7 7

[Boost][Proposal] library for enhanced switch syntax. Request for Comments #2
by рустам абдумаликов 09 Nov '19

09 Nov '19

Hi All, First attempt kind of failed due to alignment:( So this is another one) So I wrote a library eswitch which provides enhanced functionality for C++ switch. Please take a look and leave your comments. Motivation: To overcome native switch limitations: 1) one parameter per switch 2) the parameter restricted to only integral types( int, char, enum ... ) Whereas "eswitch" supports any number of parameters and almost without restriction on their type, as long as the type is comparable( i.e. has operator== ). Why it is important? Because people want to overcome current switch limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed eswitch functionality part of the Boost-Library will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. Full proposal here: https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… Repository: https://github.com/rabdumalikov/eswitch_v4 Best Regards Rustam Abdumalikov

2 1

Re: [boost] fixed_string: Request for review
by Ggh 09 Nov '19

09 Nov '19

First: 1)wonderful documentation! 2) A few ideas => 2.1)find_count_of =>find number of occurences of 'argument' 2.2)get_sequence_of =>return sequence of 'begin'=>'end' 2.3)set_sequence_of => set sequence of 'begin'=>'end' with 'arg' 2.4)set_slice_of => ~= 2.3) 2.5)get_slice_of => ~= 2.2) 6)char_traits<T> here but =>> also for any type/class? Quoting Krystian Stasiowski via Boost <boost(a)lists.boost.org>: Good work! Please regard this as constructive critism, Ty G > Hi a > ,y > My name Is Krystian Stasiowski. I'm currently attending college as a > Computer Science major, am active on the C++ Language Slack, and starting > to contribute to ISO C++. Vinnie offered for me to take the lead on > submitting Boost.FixedString for a formal review, so here I am! > > Applicable links: > Github: https://github.com/18 > Repo: https://github.com/18/fixed_string > Docs: https://18.github.io/doc/fixed_string > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Tell me, and I forget. Ask me, and I discover...

1 0

[container] static_string ?
by Vinnie Falco 09 Nov '19

09 Nov '19

Beast has static_string which someone has asked to be move, is there any interest in moving this to Boost.Container? See: <https://github.com/boostorg/beast/issues/1691> <https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552…> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

19 50

[Metrics] - library idea reviews
by cpijcke.wall＠laposte.net 08 Nov '19

08 Nov '19

Hi, Two years ago, I have created a library who handle metrics type (distance, speed, flow rate, ...). I have simply applied the principle of chrono library (std:: one from clang in my case) and have applied it to other types. I have decided some weeks ago to make it public on github. This project also manage inter-type conversion(speed to distance, or volume to flow rate for example). Before going much further in this project, I would like to get your though about it. Maybe some of you already have had a similar idea, maybe even in a more advanced state, or with another principle of conversion between types? Here is the project link: https://github.com/xtofpic/metrics if you are interested. In this case, don't blame me for the state of the code actually, I know it still need a huge works to do on testing and code reducing by better c++ templates. But if you can just let me know what you think of the idea? And if there is an opportunity to eventually integrate this project into boost afterwards? Best regards, Christophe Pijcke.

2 2

How to make boost write_xml not escape angle brackets?
by Ananya Maiti 07 Nov '19

07 Nov '19

Hi all, I am trying to write some data in a xml file using boost write_xml() function. My data has some angle brackets in it e.g. <![CDATA[name]]> . But when I use boost::property_tree::write_xml() to write the data node to xml file it escapes the angle brackets to < and > tags. I even tried using unicode \x3C , \x3E but still it escapes them. Is there any way to tell boost to not escape the characters in a non html safe way ? Regards, Ananyo Maiti

1 0

[1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests
by John Maddock 07 Nov '19

07 Nov '19

This change: https://github.com/boostorg/test/commit/1c4533f7654d4c049cc6a34a43a5c10cde5… To Boost test (which I'm sure has been long signaled, I just wasn't aware of it), breaks one Math lib test (develop and master), and quite a number of Fibre tests (also develop and master), the Math failure should be fixed in develop (https://github.com/boostorg/math/commit/1d04bf714e809d386088ce135e3f9ea04ca…) and will get merged to master once CI is green. Not sure if anything is in the works for Fiber. Just a wee heads-up. Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 8

Best Boost to use for boost::python with Python 3.7/3.8?
by Kacvinsky, Tom 06 Nov '19

06 Nov '19

Subject is the question. Any recommendations? Looking at the boost documentation for boost::python, it doesn't look like the copyright has changed since 2015, but compiling boost 1.6.9.0, for instance, points out there have been code changes.

1 0

[Test] log_level (was RE: [1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests)
by Peter Bartlett 05 Nov '19

05 Nov '19

>I think it is very counter-intuitive that messages only emerge to the normal output if there is an error or --log_level="message" > >And that > > #define BOOST_TEST_LOG_LEVEL "message" > >does not appear to have the same effect as --log_level="message" > >which is also surprising, and in my book a buglet? > >I suggest that this behaviour should be changed so that BOOST_TEST_MESSAGE >*always* produces output. > >BOOST_AUTO_TEST_CASE(test_message) >{ > BOOST_TEST_MESSAGE("\nTest BOOST_TEST_MESSAGE.\n"); } // BOOST_AUTO_TEST_CASE(test_message) > >Otherwise I am sure I will not be the only person confused. > >At the very least the documentation should highlight that ones expectation may not match what actually happens. Hi, I think it would be a bad idea to change the default value of --log_level (in your suggestion, from "error" to "message"). The default has been "error" for a long time (I don't like to count how long, because it makes me feel old!). And I'm sure that a lot of parsing tools have been built around the world assuming Boost.Test output is of a certain form. I know I've had to 'teach' various CI systems Boost.Test-speak over the years. > #define BOOST_TEST_LOG_LEVEL "message" BOOST_TEST_LOG_LEVEL is supported as an environment variable, not as a macro. Supporting it as a macro would be a bad idea for similar reasons as above - the layout and volume of the output should be for the *user* to control not the author of the tests, or otherwise the user can't rely on what the test output is going to look like from one library to the next. If you, personally, always want the log_level to be 'message', then you should set the environment variable BOOST_TEST_LOG_LEVEL permanently on your system. Hope that helps, Pete

1 0

[histogram] [1.72] merge usability patch?
by Hans Dembinski 05 Nov '19

05 Nov '19

Dear release managers, I have a patch in my develop branch for Boost.Histogram which would like to merge to the master for the 1.72 release. https://github.com/boostorg/histogram/commit/d658aff0b09f73d4f0d3b729b13518… It is a rather intrusive patch, hence my question whether I am allowed to merge this. There is no change to the public interface. The patch provides nice compile-time error messages when users make mistakes in using the histogram instead of spilling out internals details as it does now, that's why I think it would be good to have this already in the upcoming release instead of the next after. The patch passes all the tests in the CI (and new tests developed for this feature). Line coverage remains at 100 % for Boost.Histogram, therefore I am confident that applying the patch is safe. Best regards, Hans

1 0

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 02 Nov '19

02 Nov '19

On Fri, Nov 1, 2019 at 3:41 PM Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > This email appears to only be addressed to me and not the list, is > that intentional? > I typed this on my phone so maybe things didn't work exactly as I intended. > It was not intentional. > On Fri, 1 Nov 2019 at 16:09, Zach Laine <whatwasthataddress(a)gmail.com> > wrote: > > > Right. Unicode encodes all natural languages that anyone has taken the > time to put into Unicode. I stand by the implication that natural > languages are crazy. > > Natural languages -- and their transliteration to bytes -- are > arbitrary conventions yes, but they're sufficiently consistent to be > used by millions of people in their personal and professional life > everyday. > There are rules, and however alien they might look to someone who only > needs the fairly straightforward ASCII system, they are not crazy, and > have their own reasons. > > > > So then maybe don't use those parts? They're independent; you don't > have to use them to use the Unicode algorithms. > > Separation of concerns, they do appear coupled in the documentation. > That could just be due to the way the documentation is written. > Could be ... could you point to something in the docs that left you with that impression? I explicitly divided up the documentation along the lines of the separation of concerns found in the code -- the string layer, the Unicode layer, and the text layer. I also tried to be explicit that the first is without dependencies, the second does not depend on the first or the third, and that the third depends on the second. > > Clearly you are more capable than I am. It took me a lot longer to do > than 2 months. Why did you never submit this for a Boost review? You were > thinking about it, ~10 years ago, but you never did.... > > The use case for Unicode is quite niche, and I wasn't particularly > interested in working in that niche further. > Any serious natural language processing engine would probably bypass > Unicode and come up with its own heuristics to parse text, and > applications like GUI toolkits or text editors are specialized enough > that they'd probably never use a library which wasn't specifically > designed for their use case in mind. > That leaves everyday programming, which very rarely needs to do > anything with text beyond treating it as a byte stream, and I believe > wanting to impose the heavyweight Unicode machinery systematically > everywhere is a mistake. > > Anyway, I was just mentioning this because there is prior work > (Boost.Unicode) that you apparently never looked at. > Of course being developed for only a short period of time it doesn't > have the same level of polish as your library. > Ok. FWIW, I did know about your library -- I was there for the BoostCon presentation -- and I was looking forward to using it. Ten years later, I did not look at it again, simply because it had been ten years. > >> and that the database itself is not even accessible, > > > > > > That's also intentional. Another goal of the library is to make Unicode > as simple as possible for naive users who just want to do the basics. If I > find requests for any new feature that has a compelling use case, I'll add > that. > > Being able to replace things like std::isalpha etc. is pretty basic I'd > say. > Having an API that tells you a number of properties about a code point > is one of the most useful parts of Unicode. > I agree I the abstract, but I think that there is a real problem that the properties for a given code point are not necessarily consistent across the various Unicode algorithms. For example, there are multiple notions of "number" that are treated differently in the bidirectional algorithm. Moreover, I don't know of a great use case for a boost::text::is_alpha(). Specifically, it seams that if you are looking for alphabetical characters, you are usually doing something like word-breaking, for which there is already an algorithm, doing a regex match, for which is_alpha() is insufficient, etc. I'm open to hearing about such use cases, of course. > > I don't consider 1.5MB for a database containing all human languages in > widespread use on computers to be a ridiculous size, but YMMV. > > I suppose that's reasonable. > I think the Boost.Unicode one was only 500k but that's an old Unicode > version, and I'm not sure it ever had full collation support. > > > > >> > >> It also doesn't provide the ability to do fast substring search, which > >> you'd typically do by searching for a substring at the character > >> encoding level and then eliminating matches that do not fall on a > >> satisfying boundary, instead suggesting to do the search at the > >> grapheme level which is much slower, and the facility to test for > >> boundary isn't provided anyway. > > > > > > I honestly don't know what you mean here. > > I'm not sure how to clarify this better, but I'll try. > > To search for the utf-8 substring "foo" in the utf-8 string "I really > like foo dogs", there is no need to iterate the string per code point > or per grapheme as you do in your examples. You can just perform the > search at the code unit level, then check that the position before and > after the match does not lie inside a grapheme cluster, i.e. they are > on a valid boundary. > What you need to be able to do that is a function that tells you > whether an arbitrary position in your sequence of utf-8 code units > lies at a grapheme cluster boundary or not (which would probably be a > composition of two separate functions, one that test whether the code > unit is on a code point boundary, and one that tests whether the code > point is on a grapheme cluster boundary). This functionality is not > provided. > > This sort of thing is briefly touched upon in Unicode TR#29 6.4. > I see. This seems like it might be really useful to add. I'll open a ticket for it on Github. Zach

1 1

Interest in a Unicode library for Boost?
by Zach Laine 02 Nov '19

02 Nov '19

About 14 months ago I posted the same thing. There was significant work that needed to be done to Boost.Text (the proposed library), and I was a bit burned out. Now I've managed to make the necessary changes, and I feel the library is ready for review, if there is interest. This library, in part, is something I want to standardize. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" will almost certainly never happen now, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. Github: https://github.com/tzlaine/text Online docs: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May 2018, and now it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 10

[filesystem] Management of junction on Windows is broken
by Vincent R. 02 Nov '19

02 Nov '19

Hello, I am bit disappointed to see that symlink and junctions are still not really properly handled on Windows with boost (and even with standard MS libs but that's another story.) First my environment: Windows 10, VS2019 16.3.7, boost 1.71 (static, x64). I would like to write a small c++ utility that does not use os dependent code to handle files so filesystem seems a good candidate. Here is what I am doing on Windows: cd "C:\Users\Vincent\AppData\Roaming\Apple Computer\MobileSync" mklink /j Backup E:\Backup So basically I am creating inside C:\..\MobileSync a junction folder that points to my second harddisk E:\Backup Then I am checking that Windows recognize it by entering dir command: 01/11/2019 23:48 <DIR> . 01/11/2019 23:48 <DIR> .. 01/11/2019 23:29 <JUNCTION> Backup [E:\Backup] 0 fichier(s) 0 octets 3 Rép(s) 59 393 630 208 octets libres As you can see I have a junction targeting E:\Backup, so now let's see what happens with boost: fs::path p(_T("C:\\Users\\Vincent\\AppData\\Roaming\\Apple Computer\\MobileSync\\Backup")); sys::error_code ec; if (fs::is_symlink(p)) { fs::path pathTarget = fs::read_symlink(p, ec); } When I display the content of pathTarget I have: L"\\Backup" ie Backup if I decode it into human string I might not understand anything about junction but is it not supposed to return E:\Backup ?? When I look at source code I can see the following lines: /********************** boost_1_71_0\libs\filesystem\src\operations.cpp **************************************/ symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); This is wrong since we need to distinguish between a symlink and a junction folder so here is my contribution : --- a/src/operations.cpp +++ b/src/operations.cpp @@ -201,6 +201,12 @@ typedef struct _REPARSE_DATA_BUFFER { # ifndef IO_REPARSE_TAG_SYMLINK # define IO_REPARSE_TAG_SYMLINK (0xA000000CL) # endif +# ifndef IO_REPARSE_TAG_MOUNT_POINT +# define IO_REPARSE_TAG_MOUNT_POINT (0xA0000003L) +# endif +# ifndef IO_REPARSE_TAG_DEDUP +# define IO_REPARSE_TAG_DEDUP (0x80000013L) +# endif inline std::wstring wgetenv(const wchar_t* name) { @@ -1661,12 +1667,24 @@ namespace detail if (!error(::DeviceIoControl(h.handle, FSCTL_GET_REPARSE_POINT, 0, 0, info.buf, sizeof(info), &sz, 0) == 0 ? BOOST_ERRNO : 0, p, ec, "boost::filesystem::read_symlink" )) + if (info.rdb.ReparseTag == IO_REPARSE_TAG_SYMLINK) + { symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); + } + else if (info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT) + { + symlink_path.assign( + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t), + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t) + + info.rdb.MountPointReparseBuffer.PrintNameLength / sizeof(wchar_t)); + } # endif return symlink_path; } I will add more suggestions in a next message because there is no consistency between boost and MSVC approach. I don't know the last c++ specifications but it shouldn't be difficult to have a simple approach;

1 0

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 01 Nov '19

01 Nov '19

Mathias pointed out that I sent this just to him. So I'm replying again to get this onto the list. Sorry for the noise. On Fri, Nov 1, 2019 at 11:09 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > On Fri, Nov 1, 2019 at 6:35 AM Mathias Gaunard < > mathias.gaunard(a)ens-lyon.org> wrote: > >> On Sat, 26 Oct 2019 at 02:11, Zach Laine via Boost-users >> <boost-users(a)lists.boost.org> wrote: >> > >> > About 14 months ago I posted the same thing. There was significant >> work that needed to be done to Boost.Text (the proposed library), and I was >> a bit burned out. >> > >> > Now I've managed to make the necessary changes, and I feel the library >> is ready for review, if there is interest. >> > >> > This library, in part, is something I want to standardize. >> > >> > It started as a better string library for namespace "std2", with >> minimal Unicode support. Though "std2" will almost certainly never happen >> now, those string types are still in there, and the library has grown to >> also include all the Unicode features most users will ever need. >> > >> > Github: https://github.com/tzlaine/text >> > Online docs: https://tzlaine.github.io/text >> >> I would start by removing the superlative statements about Unicode >> being "hard" or "crazy". >> It's not that complicated compared to the actual hard problems that >> software engineers solve everyday. The only thing is that people >> misunderstand what the scope of Unicode is, it's not just an encoding, >> it's a a database and a set of algorithms (relying on said database) >> to facilitate natural text processing of arbitrary scripts, and does >> compromises to integrate with existing industry practices prior to all >> those scripts being brought together under the same umbrella. >> > > Right. Unicode encodes all natural languages that anyone has taken the > time to put into Unicode. I stand by the implication that natural > languages are crazy. > > >> Now the string/container/memory management, this is quite irrelevant. >> That sort of stuff has nothing to do with Unicode and I certainly do >> not want some Unicode library to mess with the way I am organizing how >> my data is stored in memory. >> Your rope etc. containers belong in a completely independent library. >> > > So then maybe don't use those parts? They're independent; you don't have > to use them to use the Unicode algorithms. > > >> What's important is providing an efficient Unicode character database, >> and implementing the algorithms in a way that is generic, working for >> arbitrary ranges and being able to be lazily evaluated (i.e. range >> adaptors). >> I already did all that work more than 10 years ago as a two-month GSoC >> project, though there are some limitations since at that time ranges >> and ranges adaptors were still fairly new ideas for C++. It does >> however provide a generic framework to define arbitrary algorithms >> that can be evaluated either lazily or eagerly. >> > > Clearly you are more capable than I am. It took me a lot longer to do > than 2 months. Why did you never submit this for a Boost review? You were > thinking about it, ~10 years ago, but you never did.... > > >> To be honest I can't say I find your library to be much of an >> improvement, at least in terms of usability, since the programming >> interface seems more constrained (why don't things work with arbitrary >> ranges rather than this "text" containers) > > > They do, of course. I'm not sure why it is you think otherwise. > > >> and verbose (just look at >> the code to do transcoding with iterators), > > > Are you referring to the verbosity of: > > char const * some_utf8 = /* ... */ ; > out = std::ranges::copy(boost::text::as_utf32(some_utf8), out); > > , or: > > out = boost::text::transcode_utf_8_to_32(utf8_first, utf8_last, out); > > , or something else? > > >> the set of features is >> quite small, > > > That is quite intentional. I want to standardize *basic* Unicode > support. I feel that what I have in Boost.Text is the basic set that users > will need, just to support languages or formatting conventions that are not > common in their favorite environment. For instance, today there is no > standard way of taking UTF-8 and turning it into UTF-16, or vice versa; > this library is intended to work at that level. That is, it is intended to > fill in needless gaps in Unicode support that exist in C++ -- gaps that no > other major language besides C has. It is specifically not intended to > replace all ICU functionality. Do you have specific things in mind that > you think ~90% of Unicode-aware C++ users will need? Note that I did not > say 100%. > > >> and that the database itself is not even accessible, > > > That's also intentional. Another goal of the library is to make Unicode > as simple as possible for naive users who just want to do the basics. If I > find requests for any new feature that has a compelling use case, I'll add > that. > > >> and >> last I remember your implementation was ridiculously bloated in size. >> > > I don't consider 1.5MB for a database containing all human languages in > widespread use on computers to be a ridiculous size, but YMMV. > > >> It also doesn't provide the ability to do fast substring search, which >> you'd typically do by searching for a substring at the character >> encoding level and then eliminating matches that do not fall on a >> satisfying boundary, instead suggesting to do the search at the >> grapheme level which is much slower, and the facility to test for >> boundary isn't provided anyway. >> > > I honestly don't know what you mean here. If you use the text::text or > text::string types, those are just contiguous sequences of bits, like a > std::vector or std::string. text::text exposes iterators to those bits > which can be used to get grapheme, code point, and/or UTF-8 byte views of > the underlying data. If you are using something else besides text::text or > text::string two types, you presumably have access to your own bits in your > own representation. What prevents you from doing whatever substring search > you like, via std::search(), std::ranges::includes(), or something else? > Boost.Text is not intended as a string algorithms library. > > I'm pretty sure I made similar comments in the past, but I don't feel >> like any of them has been addressed. >> > > I think you're referring to this email you sent in the Boost.Text > interest thread from 14 months ago: > > """ > The Unicode library I did as a SoC project in 2009 was significantly > smaller than that and if I recall correctly it has more data than the one > in your library. > Clearly some work can be done here to better optimize the database size. > """ > > I did make it a bit smaller. The other comments are new. > > Zach > >

1 0

Change TCP_USER_TIMEOUT
by JH 01 Nov '19

01 Nov '19

Hi, I am using boost asio TCP socket in my device application for network connection in Linux platform. I am troubled currently by long TCP tmeout issues in a device to switch application between WiFi and 4G LTE. If my application TCP was connected via 4G LTE initially, when WiFi is available, the network is switched to WiFi, but the application TCP connection would have 30 minutes timeout before it terminated the 4G LTE and reconnects to WiFi. That 30 minutes is too long. I checked TCP document for TCP_USER_TIMEOUT: TCP_USER_TIMEOUT Decreasing user timeouts allows applications to "fail fast", if so desired. Otherwise, failure may take up to 20 minutes with the current system defaults in a normal WAN environment. My question is, in boost asio socket, is there an API to change TCP_USER_TIMEOUT? Appreciate if showing an example or point me to a document how to do it. Thank you. Kind regards, - jh

2 3

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 30 Oct '19

30 Oct '19

On Wed, Oct 30, 2019 at 4:51 AM Leon Mlakar <leon(a)digiverse.si> wrote: > On 29.10.2019 17:11, Zach Laine wrote: > > > > >> - for the sake of completeness the normalization type used at the text >> level ought to be a policy parameter; although I do understand your >> arguments against it I think it should be there even at the cost of >> different text types being inoperable without conversions >> > > I disagree. Policy parameters are bad for reasoning. If I see a > text::text, as things currently stand, I know that it is stored as a > contiguous array of UTF-8, and that it is normalized FCC. If I add a > template parameter to control the normalization, I change the invariants of > the type. Types with different invariants should have different names. To > do otherwise is a violation of the single responsibility principle. > > Okay, the policy or not the policy was not my point ... it was to allow > for different underlying normalizations. Granted, it may only be important > to (a few) corner cases where input and/or output normalizations are given, > and your assessment that it may not be worth the effort is reasonable ... > unless you are aiming towards adding to the standard. Then the completeness > imho becomes more important. > > Frankly, I'm not proficient enough in the meta-programming to make a > strong case either for policy parameter or for explicit types/templates. I > just happen to prefer the policy based approach. > Understood. FWIW, the algorithms provided by Boost.Text make it possible to use any normalization representation, though at times conversions may be necessary. Some of those conversions are mandated by the Unicode standard itself -- you cannot feed NFC, NFKC, or NFKC to the collation algorithm, for instance (though implementations are possible for NFD and FCC). > > > - at the text level I'm not sure I'm willing to cope with different >> fundamental text types; I just want to use boost::text::text, pretty >> much the same as I use std::string as an alias to much more complex >> class template; heck, even at the string layer I'd probably prefer >> rope/contiguous concept to be a policy parameter to the same type >> template. >> > > That would be like adding a template parameter to std::vector that makes > it act like a std::deque for certain values of that parameter. Changing > the space and time complexity of a type by changing a template parameter is > the wrong answer. > > No, that is not making the std::vector to act as std::deque - the text > would still remain the text and act as a text, with the same interface. > It's more like FIFO implementation using either std::vector or std::dequeu > for its store - since in both cases the FIFO has the same interface and > functionally behaves the same, I really don't want two distinct types. The > type template with the parameter that makes the choice between the > underlying storage seems much more natural to me. > You example highlights my point. For N inputs to your FIFO queue, a deque underlying implementation is worst-case O(N). A vector implementation is worst-case O(N*N). The invariants of the type matter, and they matter a lot. Saying a foo may be like a bar or like a baz only work when bar and baz are so similar that you cannot observe a difference in the behavior of foo. Zach

1 0

[SPAM] istream_iterator_limited
by Frederick Gotham 28 Oct '19

28 Oct '19

- - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 0

Re: [boost] disjoint_sets?
by Glen Fernandes 27 Oct '19

27 Oct '19

Peter wrote: > At some point we removed the disjoint_sets module from the develop branch, > but it's still on master. When are we going to remove it from master as > well? The relevant changes need to be merged from Graph develop to master, before we can retire the disjoint_sets repository entirely. John, any concerns about doing this now, before the 1.72 release progresses? Glen

1 0

disjoint_sets?
by Peter Dimov 25 Oct '19

25 Oct '19

At some point we removed the disjoint_sets module from the develop branch, but it's still on master. When are we going to remove it from master as well?

1 0

question re BOOST_NO_EXCEPTION
by Robert Ramey 25 Oct '19

25 Oct '19

I want to detect whether or not the -no_exception compile time flag has been used on gcc/clang. Will BOOST_NO_EXCEPTIONS do this? If not is there something I can use? Robert Ramey

5 10

Multi-Dimensional Dynamic Array Boost Library Proposal
by Richard Hogaboom 24 Oct '19

24 Oct '19

I've written a library at GitHub/rahogaboom/daa that does dynamic array allocation in ptr to ptr ... style that is very simple to use(only two routines), header file only, can allocate an unlimited number of dimensions with subscripts for each dimension starting at an arbitrary number e.g. 0, 1, -5 etc, can allocate anything you can take sizeof() and allocates all in one contiguous block(stack, heap) for easy freeing. I'm aware of the Boost.MultiArray library, however, I think daa has some advantages. Specifically, a. each dimension has it's own starting subscript b. it's relative simplicity(2 routines) c. it's longevity - 30 years and two articles d. also can be used in a C only environment. Following is the points noted in the GitHub README.md: |Library: daa.hpp Dynamic Array Allocator - C++ header file only library - ptr to ptr to ... style arbitrary N dimensional array allocator of anything you can take sizeof() - arbitrary starting subscript(0, 1, -10, ...) for each separate dimension - Note: for each array dimension the starting subscript and dimension size determine the valid subscripts for that dimension - any index outside that range is invalid and will give unpredictable results - allocates anything of any type(double, int, long, struct, ...) - one contiguous block allocation of memory for all ptr's and data(locality of reference and easy free()) - array or slices of array can be passed to subroutines to any depth, modified there, and be seen at all levels - simple library, two routines(das()(calculate space needed) and daa()(allocate ptr to ptr ... array)) - no library dependencies(except standard header files) - initialization pointer argument set to instance of initialized type or NULL for no initialization - implemented by a recursive routine(ptr_init()) which calls two other different recursive routines(off() and doff()) - see article in Embedded Systems Programming, Dec. 2000, "Flexible Dynamic Array Allocation"(included) - see article in The C Users Journal, Nov. 1990. "A Flexible Dynamic Array Allocator"(included) - 18 verification tests that show code usage examples, see daa_test.cpp - see cut/paste Examples section and API(das(), daa()) section below - a daa-compile.tar file is provided with a non-header compiled(clang, clang++, gcc, g++) version - for an excellent reference on this type of array(ptr to ptr to ...) access see Numerical Recipes in C, Press, Flannery, Teukolsky, and Vettering, Cambridge University Press, 1992, pg. 20-23. Ch. 1 Preliminaries -> 1.2 Some C Conventions for Scientific Computing -> Matrices and Two-Dimensional Arrays. From the above reference read: 'Here is our bottom line: We avoid the fixed-size two-dimensional arrays of C as being unsuitable data structures for representing matrices in scientific computing. We adopt instead the convention “pointer to array of pointers,” with the array elements pointing to the first element in the rows of each matrix.' - this file is the entire documentation needed to use the library - Author: Richard Hogaboom, richard.hogaboom(a)gmail.com| | Usage: - das() - find size necessary malloc()(or whatever memory allocation routine) - allocate memory daa() - populate allocated memory - allocate auto stack or static area storage e.g. unsigned char mem[SIZE] das() - determine if array will fit in mem[] daa() - populate allocated memory | |Example:| | int err_code = 0; int asize = 0; char *mem_ptr; unsigned int d[4] = {3, 5, 4, 2}; /* dimensions */ int st[4] = {-1, -5, 10, 0}; /* starting subscripts */ double ****array = NULL; /* array pointer */ asize = das(sizeof(double), 4, d, &err_code); mem_ptr = (char *)malloc(asize); array = (double ****) daa(sizeof(double), 4, d, st, &err_code, mem_ptr, NULL);| | double d = array[-1][-5][10][0];| -- Richard A Hogaboom 16 Alprilla Farm Road Hopkinton, MA 01748-1922 richard.hogaboom(a)gmail.com www.linkedin.com/in/richardhogaboom/ www.github.com/rahogaboom M508-330-3775

2 1

Boost logo font?
by Hans Dembinski 23 Oct '19

23 Oct '19

Dear all, does someone remember which font was used for the Boost logo on boost.org? Is it possible to get this font to make another logo? I want to make a logo for Boost.Histogram. Best regards, Hans

4 11

New JSON library from the maker of Beast!
by Vinnie Falco 23 Oct '19

23 Oct '19

I've been working on a massively-multiplayer online blackjack casino server, called Beast Lounge [1]. The server and client communicate using JSON-RPC over WebSocket. I have developed a brand-new JSON library for this project, in accordance with the following design goals: * Robust support for custom allocators throughout. * Array and object interfaces closely track their corresponding C++20 container equivalents. * Use `std::basic_string` for strings. * Minimize use of templates for reduced compilation times. * Parsers and serializers work incrementally (['online algorithms]). * Elements in objects may also be iterated in insertion order. You can see the JSON library in development here: https://github.com/vinniefalco/json Is there any interest in proposing this for Boost? I'm happy to hear feedback or answer questions about this library. Feel free to open an issue on the repository, or reply here. Thanks [1] <https://github.com/vinniefalco/BeastLounge>

21 68

[lockfree][Interprocess] - SPSC queue in shared memory cause SEG fault
by Saravanan A 23 Oct '19

23 Oct '19

Hi Team, We Currently trying to develop a prototype with boost libraries, where we are facing an issue in it with boost library. It would be great if someone help out here . we are having two process where one process create “*managed xsi shared memory”* and other get attached to it. Here we trying to have a spsc queue in a shared memory structure which will be accessed by both process . Where SPSC queue data is a user defined class object. when we have a integer in ” *Mydata”* (Class name) mentioned below and try to do a Push /pop operation in the spsc queue on respective process it was working fine without any issues. But the same framework when we have an array of greater size(more than 28 byte around. Example: a[7] ) .We are facing a crash in consumer side . (It seems spsc queue write somewhere in process heap memory after first pop leading to memory corrupt ) please let us know if there any open issue in this ? or if we have used boost library incorrectly ? Thanks for reading. I would be thankful for any information you may have to offer. *Backtrace:* /data/users/kapparao/example_boost/anony-SHM-managed> $./processB Consumer-TX - Read data from Q - [1,b] notify_one@93 - I am here! notify_one@159 - I am here! Segmentation fault (core dumped) /data/users/kapparao/example_boost/anony-SHM-managed> $gdb ./processB GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /data/users/kapparao/example_boost/anony-SHM-managed/processB...done. (gdb) r Starting program: /data/users/kapparao/example_boost/anony-SHM-managed/./processB [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Consumer-TX - Read data from Q - [1,b] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.0.1.el7.x86_64 libgcc-4.8.5-39.0.1.el7.x86_64 libstdc++-4.8.5-39.0.1.el7.x86_64 (gdb) bt #0 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004063de in boost::interprocess::ipcdetail::posix_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/posix/condition.hpp:160 #2 0x00000000004066e1 in boost::interprocess::interprocess_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/interprocess_condition.hpp:94 #3 0x0000000000402941 in main () at processB.cpp:42 Attached the complete code in tar for your reference. *Compilation and Execution* : *Process A : * Compilation syntax : c++ my_data.cc processA.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processA -std=c++11 Execution syntax : ./processA *Process B :* Compilation syntax : c++ my_data.cc processB.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processB -std=c++11 Execution syntax : ./processB *Thanks in advance !!!!!* Regards, saravanan =====================================================

2 1

Re: [boost] New JSON library from the maker of Beast!
by Daniel Frey 22 Oct '19

22 Oct '19

> On 23. Oct 2019, at 00:33, Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > > On Tue, Oct 22, 2019 at 3:13 PM Daniel Frey via Boost > <boost(a)lists.boost.org> wrote: >> That sounds like you should stop using the STL altogether. What if std::string is suddenly 2x slower? So... no, I don't buy that argument. >> >> I just switched our JSON library <https://github.com/taocpp/json> from >> our own classic enum+union implementation (back from the C++11 days) >> over to std::variant (as we are now C++17 anyways). > > Any idea why taocpp compiled with optimizations is 5 to 10 times > slower than the other libraries at parsing the same inputs? Yeah... I'd actually *try* to blame MSVC here :) We haven't benchmarked our libraries on Window as we are not Windows users ourselves. The numbers on Linux/MacOS should look different. Have you tested there as well? So Emil's argument has some truth to it, but still I'd rather like to see the STL to improve rather than rolling back. But I haven't even verified it, so take that with a grain of salt. > It seems like there's this thing called PEGTL which has some large > number of functions showing up as taking up time in the profile? What > is PEGTL? The PEGTL is the Parsing Expression Grammar Template Library <https://github.com/taocpp/PEGTL>, our general-purpose parser library. the JSON library actually started out as a benchmark for the PEGTL. Obviously, the parser spends most time in some methods from the PEGTL. And older version that are in the nativejson-benchmark were doing quite well for a general-purpose parser framework <https://github.com/miloyip/nativejson-benchmark#parsing-time>. Not as fast as RapidJSON, but that also largely depends on the design choices for the value type to hold the result.

2 1

Re: [boost] New JSON library from the maker of Beast!
by Vinnie Falco 22 Oct '19

22 Oct '19

On Tue, Sep 24, 2019 at 7:32 AM Dominique Devienne <ddevienne(a)gmail.com> wrote: > ...why conflate the array and object APIs in the value > type, rather than just having as_object() and > as_array() as you already? I agree, and these additional APIs have been pruned. I have also pruned other unnecessary APIs (thanks to advice from Peter Dimov) such as the local iterator and bucket interfaces in `json::object` (which needlessly constrain the implementation). > So I'm curious why it should be different here. Does the doc goes into that already? `json::value` is not `variant<...>` for the same reason that `string_view` is not `std::pair<char const*, std::size_t>`. > On the "compact" side, how compact is your json::value? > What are the different sizeof on 32 and 64-bit arch? I've done some work on this. I gave up on using std::string to represent strings for a few reasons related to performance and API. I have reimplemented string to have a small buffer optimization and to work natively with the `json::storage_ptr` type which gives some space efficiencies (and eliminates some unnecessary atomic operations caused by std::string's Allocator interface). The new sizes look like this: 32-bit sizeof(value) == 40 sizeof(object) == 8 sizeof(array) == 8 sizeof(string) == 32 sizeof(number) == 24 64-bit sizeof(value) == 48 sizeof(object) == 16 sizeof(array) == 16 sizeof(string) == 40 sizeof(number) == 24 The string type has a 20-byte small buffer which is pretty generous Thanks

4 5

[release] Is everyone ready for the 1.72.0 release (cycle)?
by Marshall Clow 21 Oct '19

21 Oct '19

We're getting ready to start the release cycle. People should be familiar with the milestones. They're on the calendar at https://www.boost.org/development/ The first two milestones are: 23-Oct: Boost 1.72.0 closed for new libraries and breaking changes 30-Oct: Boost 1.72.0 closed for major changes -- Marshall

1 0

[Exception] PR #24 passes CI tests
by dariomt＠gmail.com 21 Oct '19

21 Oct '19

Hi, PR #24 [1] at last passes all CI tests. It should solve Issue #10 [2]. I'd like to ask for it to be reviewed and merged. I'm hopeful we can get it into the 1.72 release. Regards, Dario PS: thanks to pdimov for suggesting how to fix the Travis configuration [1] https://github.com/boostorg/exception/pull/24 [2] https://github.com/boostorg/exception/issues/10

1 0

Re: [boost] Adding my sorting algorithm, ska_sort to boost
by Malte Skarupke 20 Oct '19

20 Oct '19

Thanks for the replies. I finished a first pass of the documentation, tests, and other work of including my algorithm in boost and uploaded it here: https://github.com/skarupke/sort/tree/master I also re-ran all the single threaded benchmarks and updated the documentation. For the big O complexity: I am actually still not quite sure what it is. I used similar notation to what spreadsort uses. I think O(n*key_length) is correct for the worst case, but for long keys (like when sorting long strings) the algorithm may fall back to comparison based sorting, so I used the same thing as spreadsort: min(O(n log n), O(n key_length)). For speed: ska_sort should be the fastest sorting algorithm even for small numbers of items. I included three graphs of benchmarks, for sorting ints, floats and strings: https://github.com/skarupke/sort/blob/master/doc/images/sorting_ints.png https://github.com/skarupke/sort/blob/master/doc/images/sorting_strings.png https://github.com/skarupke/sort/blob/master/doc/images/sorting_floats.png For ints and strings ska_sort is always fastest, for floats pdqsort is briefly faster, but starting at N >= 128 ska_sort is faster. Part of the work of this new version of ska_sort was to make radix sort really fast even for small N. Before I would use std::sort for any small array of less than 128 items. Now that cutoff is at 32 items, so I skip straight to insertion sort and never do std::sort. The biggest effect of this change is that it removes the "waves" from the benchmark graph, like we still see for spreadsort in the above picture. I used to also have those when I gave a talk about this algorithm. Now the graph is much more smooth. (this also confuses my answer to the question "what is the big O complexity of this algorithm?" Because the O(n*b) answer that I gave in my talk was justified by the presence of the waves) The biggest questions I have at this point are around the interface. I reworked that completely so that even relatively advanced use cases are now pretty straightforward. I don't think that anyone else will ever need to use those advanced features, so I kept the documentation of them small, choosing instead to focus on the common use cases. And I made sure to give lots of examples of converting existing comparison-based sorting examples to my interface. Oh and for the big point of a parallel version of this algorithm: At this point I have no idea how to do that. I haven't even begun to look into parallel algorithms. The current version was a lot of work already. I think that'll have to be a project for another time. (it's definitely appealing though since currently the sorted algorithms are only 2.4 times as fast as ska_sort on a machine with 8 cores/16 hyper threads in benchmark_numbers.cpp, so even a little bit of parallelism would beat the existing algorithms...) Francisco, since you'll be busy in the near term it sounds like I can't expect too much response for another month, but I would really appreciate it if you could look at it a little just to see if anything obvious stands out to you that I can work on while I wait. (otherwise no biggie, I understand how hard it can be to find time for maintaining projects, since that is exactly one of the reasons why I want to get this into boost...) Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm > Date: Sun, 20 Oct 2019 13:24:06 +0200 > From: Francisco Jos? Tapia <fjtapia(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Adding my sorting algorithm, ska_sort to boost > Message-ID: > <CADBNGqQJpHux3AdRJON-nh76BaouRn1FRO4_LrMR76TywmCH+g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Malte, > I am Francisco Tapia, one of the co-authors of the Sort library. > We will examine your algorithm. But we must examine the internal parts of > the algorithm, and evaluate the correctness of the algorithm, how is > implemented the worst case and a couple of details. After, we check the > speed with the benchmarks used in the library, with several sets of data. > Since the near sorted to the fully unsorted, and from the single numbers to > structs with heavy comparison functions. > > Now, I am overburdened by work, and I can't revise until December. But we > will do and provide to you a reasoned response, and according to it, decide > the inclusion or not in the library. > As commented by Phil Endecott, the most interesting now is the parallel > algorithms. Today, we don't have any parallel algorithm based on radix sort > or any other hybrid algorithm. > Because with small sets of data the differences are insignificant. But when > you have big sets of data, use parallel algorithms, and then, the new > single thread algorithms are in the middle, in the no man's land. > > If you have any doubt or question, contact me, and I will try to answer you. > > El mar., 15 oct. 2019 a las 23:06, Kostas Savvidis via Boost (< > boost(a)lists.boost.org>) escribi?: > > > > > > On Oct 13, 2019, at 03:06, Malte Skarupke via Boost < > > boost(a)lists.boost.org> wrote: > > > > > > Hi, > > > a couple of years ago I wrote a generalized version of radix sort, > > called ska_sort. I gave a talk about it at CppNow, available here: > > > https://www.youtube.com/watch?v=zqs87a_7zxw > > > > > > I have a new version of that algorithm that is both faster and more > > general. I can now sort almost anything. For example when I gave the talk I > > couldn't sort a std::vector<std::list<int>> because std::list doesn't have > > a random access interface, but now that works. (and it's faster than > > sorting the same thing with std::sort) > > > > > > > This seems like a product of a large investment of effort. > > The big advantage over any previously available radix_sort > > is the ability to sort almost any datatype if a key maps to an integer > > somehow. > > Plus, an advantage in measured practical speed, and apparently no claims > > about Big O improvement. > > > > The average performance is O(n*b) where b is unknown and/or dependent on n > > ? > > > > Is the theoretical worst-case O(n^2) ? Why? Is it because of working > > in-place? > > (yes, I understand you fall back to std::sort if you hit this case) > > > > Is this software/algorithm fully documented? - I mean by another way than > > reading the source code. > > > > Maybe too many questions at once, but it was not clear after watching your > > talk at cppcon and the blog posts. > > > > Cheers, > > Kostas > > > > <https://www.youtube.com/watch?v=Nz1KZXbghj8> > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > ------------------------------ > > Subject: Digest Footer >

1 0

constexpr for boost::endian
by Gero Peterhoff 20 Oct '19

20 Oct '19

Hello developer, can you implement constexpr support for boost::endian? And i'm missing support for (compiler-dependent) int128 (boost::u/int128_type). thx Gero

2 2

Adding my sorting algorithm, ska_sort to boost
by Malte Skarupke 20 Oct '19

20 Oct '19

Hi, a couple of years ago I wrote a generalized version of radix sort, called ska_sort. I gave a talk about it at CppNow, available here: https://www.youtube.com/watch?v=zqs87a_7zxw I have a new version of that algorithm that is both faster and more general. I can now sort almost anything. For example when I gave the talk I couldn't sort a std::vector<std::list<int>> because std::list doesn't have a random access interface, but now that works. (and it's faster than sorting the same thing with std::sort) I've also made it much easier to extend the algorithm with your own types. It was always easy if your type isn't too complicated, but now even weird types like std::variant are pretty easy to add. In my old version I had to go deep into the guts to add support for std::variant, now it's easy enough to do that that I'll add it to the documentation. I'm thinking of releasing the new version in boost, mainly so that it will be used more widely and so that it can be kept working in the long term. Since this is a long weekend in the US, I will try to as much of the work as possible this weekend. I'm currently trying to figure out how the boost documentation works (I saw that there are quickbook files in Boost.Sort, but how do I run the build for it?) and I've already made good progress on cleaning up my code and making it use the boost::sort namespace. Before I go any further I wanted to ask though: Does boost want my sorting algorithm? This would essentially deprecate spreadsort since this one is faster and more general and easier to use. To convince you that this is worth adding, I ran the benchmark that is included in the Boost.Sort source code. On random numbers here is how long all the algorithms took: std::sort: 9.04 pdqsort: 4.65 std::stable_sort: 11.57 spinsort: 5.42 flat_stable_sort: 7.26 spreadsort: 4.41 ska_sort: 2.00 There are a lot more bencmarks in the Boost.Sort code, and in general the results are this: If the data is already sorted or mostly sorted, other algorithms are faster, but if there are no easy patterns, ska_sort is always fastest. (I was going to include the entire table in this email, but the formatting breaks. I can attach all the results separately if anyone is interested) The Boost.Sort code also has benchmarks for sorting "objects" and "strings" and the results are similar there: On random data ska_sort is always fastest. I think this new version would be great in boost. It's not every day that a new sorting algorithm comes along that's literally twice as fast as what we had before. If we want this in boost, what would the next steps be? From the "submission process" document it sounds like there will be several stages of "Refinement" for the code. (or should this go through the Boost Library Incubator?) After I figure out how the documentation works I can upload a first version of this to github. (I want to get the documentation working so that we can talk about the interface) Let me know what you think, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

5 4

[SPAM] [preprocessor][vmd] Updates to the preprocessor and vmd libraries
by Edward Diener 19 Oct '19

19 Oct '19

The C++20 preprocessor construct __VA_OPT__ has the additional affect of providing the ability to write a general purpose macro for testing emptiness, ie. no preprocessor tokens, in C++ macro programming that is 100% reliable for any preprocessor data passed to it. Previously such a macro testing for emptiness always had some corner cases where the test might fail with a preprocessor error, but in C++20 mode at least the test can now be completely reliable in all cases. So I have added two macros along with documentation, as well as a topic discussing emptiness, to the Boost PP library. The first macro is called BOOST_PP_VARIADIC_OPT, invoked with no parameters as BOOST_PP_VARIADIC_OPT(), which expands to 1 if the compiler is in C++20 mode, supports variadic macros, and supports the C++ 20 __VA_OPT__ construct, and otherwise expands to 0. The second macro, which only exists if BOOST_PP_VARIADIC_OPT() expands to 1, is called BOOST_PP_CHECK_EMPTY. This second macro is a variadic macro which takes a single parameter of variadic data, and expands to 1 if the data is empty or expands to being empty, while otherwise expanding to 0 if the data is not empty. Furthermore in the Boost VMD library I have updated the BOOST_VMD_IS_EMPTY macro to essentially invoke the BOOST_PP_CHECK_EMPTY macro when BOOST_PP_VARIADIC_OPT() expands to 1, while retaining the current processing when that is not the case. As well I have updated the VMD discussion of emptiness in the documentation of Boost VMD to include information about the ability to provide a 100% reliable test for emptiness in C++20. Neither change in Boost PP or Boost VMD should affect any end-user or Boost library in any way. There are tests for all these changes and all tests have passed. I will update the release notes for Boost PP and Boost VMD for the next release of Boost with this information. As always any comments, questions, or criticism of these changes are always welcome.

1 1

Warning from Boost.Exception
by pbristow＠hetp.u-net.com 17 Oct '19

17 Oct '19

Using Clang 9 on Windows b2 toolset-clang-linux cxxstd=2a . I am seeing lots of these warnings In file included from ..\..\..\boost/test/included/unit_test.hpp:23: In file included from ..\..\..\boost/test/impl/execution_monitor.ipp:37: In file included from ..\..\..\boost/exception/diagnostic_information.hpp:11: ..\..\..\boost/exception/info.hpp:134:21: warning: delete called on non-final 'boost::exception_detail::error_info_container_impl' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] delete this; ^ It seems that trying to supress is ineffective with -Wno-delete-non-abstract-non-virtual-dtor Perhaps by design? https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html#… te-non-abstract-non-virtual-dtor -Wdelete-non-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> Diagnostic text: warning: delete destructor called on non-final B that has virtual functions but non-virtual destructor -Wdelete-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> Some of the diagnostics controlled by this flag are enabled by default. Controls -Wdelete-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> , -Wdelete-non-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> . Should I be concerned about this? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

4 13

[Math] float16 on ARM
by Phil Endecott 16 Oct '19

16 Oct '19

Hi, There seems to be support for 16-bit floats on iOS, when using Apple's XCode clang. This seems to be a storage-only format with the only instruction set support being conversions to and from 32- and 64-bit floats. Quick test: #if __ARM_FP & 2 #warning "Have 16-bit FP" #endif void test() { __fp16 a = 1.234; static_assert(sizeof(a)==2); __fp16 b = 2.345; auto sum = a+b; static_assert(sizeof(sum)==4); } There doesn't seem to be a std::numeric_limits specialisation. I suspect that other platforms have something similar. It would be good to have a boost::float16_t typedef and a portable feature-test macro (and maybe a software fallback). As far as I can see, boost/math/cstdfloat/cstdfloat_types.hpp checks the sizes of float, double and long double, and checks for 128-bit floats provided by the compiler. Can this be extended to check for __fp16 ? (P.S. it seems that gcc also has support, see https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html ) Cheers, Phil.

5 10

Does boost asio ssl support sslv3?
by JH 15 Oct '19

15 Oct '19

Hi, I've been running boost asio socket and sslv2 for many months, it works very well: server.cpp ontext_(boost::asio::ssl::context::sslv23) context_.set_options(boost::asio::ssl::context::default_workarounds | boost::asio::ssl::context::no_sslv2 | boost::asio::ssl::context::single_dh_use); context_.set_password_callback(boost::bind(&Server::get_password, this)); context_.use_certificate_chain_file("ssl/server.pem"); context_.use_private_key_file("ssl/server.pem", boost::asio::ssl::context::pem); context_.use_tmp_dh_file("ssl/dh2048.pem"); on client.cpp boost::asio::ssl::context context(boost::asio::ssl::context::sslv23); Recently we changed a nodejs server nodejs which using sslv3, the client failed to connect to server sslv3: Failed handshake: sslv3 alert handshake failure Any tips how to fix sslv3 handshake failure? Thank you. Kind regards, - jh

4 6

Cryptic Boost.Build error (help required!)
by John Maddock 14 Oct '19

14 Oct '19

Can anyone see what's wrong here: https://github.com/boostorg/regex/issues/89 ? The reduced test case is: |./b2 -sICU_PATH="/opt/some/path" -sICU_LINK="-L/opt/some/path/lib/x86_64-linux-gnu -licuuc -licudata -licui18n" toolset=gcc-8 -n --with-filesystem --with-log Many thanks, John. | -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[gil][docs] Image Processing docs structure based on "Principles of Digital Image Processing" book
by Mateusz Loskot 13 Oct '19

13 Oct '19

Hi, (Copying to boost and boost-users lists) If you are passionate about C++ and image processing and interested in writing documentation about it, here is a good first issue for you if you'd like to start contributing to Boost.GIL. During the course of GSoC 2019 we have received first batch of IP features, there is not great deal of content yet, so shouldn't be overwhelming to get started. It's rather a clean slate under your control. Don't be shy! :-) Regards, Mateusz Loskot ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Sun, 13 Oct 2019 at 20:08 Subject: [GH #396] Image Processing docs structure based on "Principles of Digital Image Processing" book To: <boost-gil(a)lists.boost.org> Hi, Following our successful GSoC 2019, I have started discussion on proposal of improved and future-proof structure of the "Image Processing" chapters of GIL documentation. Here are details: https://github.com/boostorg/gil/issues/396 Please, have a look and share your feedback. If there is anyone experienced in writing docs, a technical write, who is looking for ways to contribute to Boost and Boost.GIL, this is a very good first issue to pick :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[outcome] Major changes for Boost 1.72 release
by Niall Douglas 11 Oct '19

11 Oct '19

Just as a heads up to those who care, and any pretesting of these changes in advance of the Boost release is welcome. There are two breaking changes: 1. The git submodule mechanism used by standalone Outcome of specifying dependent libraries has been replaced with a cmake superbuild of dependencies mechanism instead. Upon cmake configure, an internal copy of quickcpplib will be git cloned, built and installed into the build directory from where an internal `find_package()` uses it. This breaks the use of the unconfigured Outcome repo as an implementation of Outcome, one must now do one of: 1. Add Outcome as subdirectory to cmake build 2. Use cmake superbuild (i.e. `ExternalProject_Add()`) to build and install Outcome into a local installation. 3. Use one of the single header editions. 2. For standalone Outcome, the current compiler is now checked for whether it will compile code containing C++ Concepts, and if it does, all cmake consumers of Outcome will enable C++ Concepts. Set the cmake variable `CXX_CONCEPTS_FLAGS` to an empty string to prevent auto detection and enabling of C++ Concepts support occurring. There are two new features: - Standalone outcome is now `make install`-able, and cmake `find_package()` can find it. Note that you must separately install and `find_package()` Outcome's dependency, quickcpplib, else `find_package()` of Outcome will fail. - Support for C++ Coroutines has been added. This comes in two parts, firstly there is now an `OUTCOME_CO_TRY()` operation suitable for performing the `TRY` operation from within a C++ Coroutine. Secondly, in the header `outcome/coroutine_support.hpp` there are implementations of `eager<OutcomeType>` and `lazy<OutcomeType>` which let you more naturally and efficiently use `basic_result` or `basic_outcome` from within C++ Coroutines -- specifically, if the result or outcome will construct from an exception pointer, exceptions thrown in the coroutine return an errored or excepted result with the thrown exception instead of throwing the exception through the coroutine machinery (which in current compilers, has a high likelihood of blowing up the program). Both `eager<T>` and `lazy<T>` can accept any `T` as well. Both have been tested and found working on VS2019 and clang 9. More detail can be found at: https://boostorg.github.io/outcome/changelog.html Niall

3 4

Seeing spam designation in message title
by Edward Diener 10 Oct '19

10 Oct '19

The previous message I sent to this mailing list shows the word [SPAM] in the title to the message. Does anybody know why this happened ? I am obviously not a spammer being the author of two libraries and maintainer of another.

3 3

Regression tests on 'develop'
by Edward Diener 10 Oct '19

10 Oct '19

It looks like on the 'develop' side most regression tests are either not being run very often or there is some problem in the posting of the latest results. I suspect the former but I thought it should at least be brought up. On the 'master' side many more recent recent regression tests are showing.

1 0

A solution to return dynamic strings without heap allocation. Any interest?
by Roberto Hinz 09 Oct '19

09 Oct '19

Hi all, I haven't been succesful at attracting interest in a formatting library [1] I've been working lately. But recently I realized that part of it could be isolated as a small standalone library that could solve an old common troublesome situation in C++: Suppose you need to create a function that returns/provides a string whose content and size is unknown at compilation time. The first approach is to make it return a `std::string`. But if it need to be usable in environments like bare-metal real-time system, then one usually makes it take a raw string as an output argument, more or less like this: struct result{ char* it; bool truncated; }; result get_message(char* dest, std::size_t dest_len); But this is clearly not a perfect solution since there's nothing really effective the caller can do when get_mesage fails because of the destination string being is too small. So I present the `outbut` abstract class. It somehow resembles `std::streambuf`, but with a simpler and lower level design, which is the result of many attempts looking for the best performance [2] and usability in my formatting library. Afaics, it does not require a hosted C++ implementation, though I would like someone else to confirm that. Now the caller of `get_message` has to choose or create a suitable class type deriving from outbuf, that dictates where the message is written to. For example, if the user wants to get a `std::string`, then `string_maker` will do the job: #include <boost/outbuf/string.hpp> // ... boost::outbuf::string_maker<false> msg; get_message(msg) std::string str = msg.finish(); Or, if one wants it to write into a raw string, then use `cstr_writer` char buff[buff_size]; boost::outbuf::cstr_writer csw(buff, buff_size); get_message(csw); auto result = csw.finish(); if (result.truncated) { // ... Those `finish` functions above do not belong to `outbuf`. They are defined in the concrete derived types only. It's solely by convention that they share the same name. Yes, using `string_maker` still leads to heap allocation and `cstr_writer` to string truncation. The problem isn't solved by these. However, a string object is never the final destination. So the user could rather use another class that writes the message directly into the final destination ( output console, a log file, an LCD display or whatever ). It is not difficult to implement concrete subtypes of `outbuf`. `outbuf` is actually a type alias: template <bool NoExcept, typename CharT> class basic_outbuf; using outbuf = basic_outbuf<false, char>; using outbuf_noexcept = basic_outbuf<true, char>; That `NoExcept` template parameter is perhaps the controversial part. It is not present originally in my formatting library. Besides the destructor, `basic_outbuf` has only one virtual function: `recycle()`, and it is declared as `noexcept(NoExcept)`. This is the only effect the `NoExcept` template parameter has. All other functions are guaranteed not to throw. Hence, by taking a `outbuf_noexcept&` parameter, a function states that the destination must not throw. That might be particularly good if such object comes from another module and we must avoid exceptions crossing modules boundaries. On the other hand, if a function takes an `outbuf&`, then it also accepts `outbuf_noexcept&`, because `basic_outbuf<true, CharT>&` derives from `basic_outbuf<false, CharT>`. When using `string_maker` you can choose between the two kinds. `string_maker<true>` derives from `basic_outbuf<true, char>&`. So if any exception raises from its internal `std::string`, then it is caught by a try/catch(...) block, stored as an `exception_ptr` and rethrown by `finish()`. This has the undesirable effect of delaying its proper handling ( after all, we rather stop what's being doing as soon as possible when an error appears ). So I think the recommendation would be to use `string_maker<false>&` if possible, and `string_maker<true>&` only if necessary. The reason why I think it's controversial is that it makes `recycle()` violates the Lakos Rule. And although the Lakos Rule is not a requirement in boost (afaik), I was wondering whether this library could interest LEWG in future as well. Anyway, this whole noexcept idea is not a central part of this library and can it be removed. Now, the other topic is how to implement that `get_message` function, i.e., how to write into an `outbuf` object. One can use `puts` and `putc` functions to insert string and chars. One can also use `fmtlib` through an output iterator adapter. Or one can write directly in the buffer. But I will ask you to read the doc [3] for that. It's a quick read, quicker than this email. The repository is: https://github.com/robhz786/outbuf I would prefer it to be part of Boost.Core instead of being a standalone library, and also to remove the `outbuf` namespace. But that is up to you. Best regards, Roberto [1] The Stringify library: https://github.com/robhz786/stringify [2] The great performance of Stringify is mainly thanks to the design of outbuf ( named there as `output_buffer` ): https://robhz786.github.io/stringify/doc/html/benchmarks/benchmarks.html#be… [3] "Writing into and outbuf object" https://robhz786.github.io/outbuf/doc/html/index.html#boost_outbuf.overview…

5 13

[Boost.MSM] Please, update master with changes from develop
by Deniz Bahadir 08 Oct '19

08 Oct '19

Hello world, I just stumbled across a compilation-error with the latest Boost release (1.71) of Boost.MSM for which I already provided a merge-request [1] a year ago, and which was merged to "develop" branch at that time, too. Still, the "master" branch lags this merge-request (and a lot more [2] from former years which are in "develop") but has some other unrelated merge-requests [3] merged in which are not in "develop". I would love seeing "develop" being merged into "master" (and maybe vise-versa) so that bugs for which fixes already exist will no longer be present in the next Boost release. Thanks for taking care of. Deniz [1] https://github.com/boostorg/msm/pull/15 [2] https://github.com/boostorg/msm/compare/master...develop [3] https://github.com/boostorg/msm/compare/develop...master

3 2

[contract] new maintenance release for Boost 1.72
by Lorenzo Caminiti 07 Oct '19

07 Oct '19

Hello Release Managers & all, I made a maintenance release of Boost.Contract. All tests pass, docs are updated, etc. The code is up-to-date in boost/contract/master. Can you please pull changes from boost/contract/master into the upcoming Boost 1.72 release? These are the changes: * Using std::uncaught_exceptions on C++17 compilers onward (instead of the now obsolete std::uncaught_exception). * Fixed a few warnings. * Removed linking to Boost.System (Boost.System is now a header-only library). * Added this library to Boost's Continuous Integration (CI). * Fixed documentation typos. Thank you in advance. --Lorenzo

2 2

git pull on Boost 'develop' branch problem
by Edward Diener 03 Oct '19

03 Oct '19

When I do a 'git pull' on Boost checked out to 'develop' it ends with: error: Server does not allow request for unadvertised object 3eb4826d1d2a3e46207a7e4a0467d9bab96d37f5 Anybody know why this is happening with the latest Boost in the 'develop' branch and if I need to do something to correct this ? It does not seem to b3e affecting anything, and it appears the 'git pull' is successful at the top level in pulling the latest 'develop' changes.

4 3

Re: [boost] New JSON library from the maker of Beast!
by Bjorn Reese 30 Sep '19

30 Sep '19

On 9/30/19 12:14 PM, julien.blanc(a)tgcm.eu wrote: > Do you have an example of an efficient implementation of a pull parser on top of async io ? I find push parsers really more straightforward in that case. Vinicius has an HTTP pull parser here: https://github.com/BoostGSoC14/boost.http > Pull parsers can also be built on top of push parsers, although it is less easy. Indeed, that is how we implemented XmlTextReader in libxml2, and it was a rather painful experience. Coroutines can help, as Phil pointed out, but pull parser are also a natural fit for parser combinators (e.g. HTTP contains a partial URL syntax, so it could be created combining HTTP and URL pull parsers.) I am not sure how well coroutines would handle this case.

1 0

Who is maintaining Boost.Random?
by Christoph Conrads 29 Sep '19

29 Sep '19

Last Tuesday I submitted a feature request for Boost.Random and received absolutely no feedback which seems to be unusual judging by last week's discussions (e.g. secure-by-default networking with Boost.Asio). Is anybody maintaining Boost.Random currently and if not, how can I proceed with my feature request? Christoph Conrads

2 3

How to handle contributions from anonymous?
by Hans Dembinski 27 Sep '19

27 Sep '19

Hi all, I got a PR from a contributor who prefers to remain anonymous. The person created new files and instead of putting a real name, the person added just initials. I am talking to the person to see whether they can be convinced to give a real name. Any advice on how to handle this? My feeling is that a copyright notice without a real name is illegal. I could publish the code in my name, but then a documented transfer of copyright from the contributor to me is missing, which then puts me in a vulnerable position. Any thoughts? Best regards, Hans

5 6

MS STL now open source (and using Boost)
by John Maddock 26 Sep '19

26 Sep '19

Microsoft's standard library is now in the process of going open source (the code is there, but not the tests yet), see : https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-stl/ Interestingly they're using the Math library's special functions en-mass for enhanced <cmath> support, and a quick grep of the code turns up other references to Boost, though I haven't identified the libraries they've borrowed from yet. Hopefully this means that in the long turn we'll see patches and enhancements flowing in both directions for the benefit of all. John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

11 14

more (hyper)complex types
by Gero Peterhoff 26 Sep '19

26 Sep '19

Hallo Developers, Hello John, I'm missing the (hyper)complex types in boost::math: - dual, i²=0 https://en.wikipedia.org/wiki/Dual_number - acomplex (anormal complex), i²=1 https://en.wikipedia.org/wiki/Split-complex_number - sedenion, https://en.wikipedia.org/wiki/Sedenion and the arithmetic functions for this types. Can you provide it? That would be great! thx Gero

3 2

Memory leak in add_options
by Vinitha Anish(UST,IN) 24 Sep '19

24 Sep '19

Hi , Our static analyzer report an memory leak with add_options . We use namespace po = boost::program_options; po::options_description desc("Options"); desc.add_options() ("name", po::value<std::string>(), ...) // add option ; The issue reported in boost library file value_semantic.hpp:199 template<class T> typed_value<T>* value(T* v) { typed_value<T>* r = new typed_value<T>(v); return r; } memory is dynamically allocated here and return at line 201. Can anyone suggest how do we handle this memory leak.

1 0

How to bind boost::asio::ip::tcp::socket to a local endpoint with a sperific local IP address?
by JH 24 Sep '19

24 Sep '19

Hi, I have searched the documents, but still could not clarify how to bind the socket to a local IP address, which API could I add my local IP address to it? socket.bind(boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), 12345)); ....... boost::asio::ip::tcp::resolver::query query(remoteServerIPAddress, portNumber); Thank you. Kind regards, - jh

3 3

Source code of boost-commitbot git user
by LE GARREC Vincent 24 Sep '19

24 Sep '19

Hi, I work on a company where the architecture of the software is closed to boost : one super project and lots of submodules. We are spending lots of time with the superproject by doing "fetch/merge/checkout" every time because someone else updated a submodule just 15 minutes ago. In boost, it looks like the superproject is updated by Travis (or maybe a git post hook ?). Does this script is available somewhere? It will really help us and improved your time. I took a look but I didn't find anywhere the source code. Thanks for your help, Best regard, Vincent

1 0

clang-9 on travis?
by John Maddock 23 Sep '19

23 Sep '19

Has anyone figured out how to install clang-9 on travis? I'm seeing: Adding APT Sources Disallowing sources: llvm-toolchain-xenial-9 See https://travis-ci.org/boostorg/multiprecision/jobs/588146074 With .travis.yml containing: - os: linux env: TOOLSET=clang COMPILER=clang++-9 CXXSTD=c++17 TEST_SUITE=misc addons: apt: packages: - clang-9 - libgmp-dev - libmpfr-dev - libmpc-dev - libmpfi-dev sources: - ubuntu-toolchain-r-test - llvm-toolchain-xenial-9 Which works fine for clang-8. Any ideas anyone? Thanks! John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

Call for Papers - ICITST-2019 - London, UK
by Galina Akmayeva, ICITST 20 Sep '19

20 Sep '19

CALL FOR PAPERS! ************************************************************ The 14th International Conference for Internet Technology and Secured Transactions (ICITST-2019) Venue: CCT Venues-Docklands London, UK December 9-11, 2019 www.icitst.org ************************************************************ The ICITST is an international refereed conference dedicated to the advancement of the theory and practical implementation of secured Internet transactions and to fostering discussions on information technology evolution. The ICITST aims to provide a highly professional and comparative academic research forum that promotes collaborative excellence between academia and industry. The ICITST-2019 invites research papers that encompass conceptual analysis, design implementation and performance evaluation. The topics in ICITST-2019 include but are not confined to the following areas: Internet Applications and Technology: * Internet Architecture * Internet of things * Broadband Access Technologies * Application Agents * Boundary Issues of Internet Security * Database Management * Data Models for Production Systems and Services * Artificial Intelligence and Expert Systems * IPSec Quality of Service * Knowledge Management * Embedded Systems * Defence Systems Ubi/Cloud Computing: * Authentication and Access Control for Data Protection in Ubi/Cloud Computing * Context-Awareness and its Data Mining for UbiCom * Data Grids * Distributed Information Systems * Human-Computer Interface and Interaction for UbiCom * Ubiquitous Systems * USN/RFID Service * Smart Homes and its Business Model for UbiCom Service * Security and its Data Management for UbiCom * Peer to Peer Data Management * New Novel Mechanism and Application for Ubi/Cloud Computing Information Security: * Trust, Privacy and Data Security * Network Security Issues and Protocols * Security Challenges and Content Authoring * Cryptography * Secure Communications * Authentication Techniques * Chaos-based Data Security * MANET Security * Wireless Sensor Network Security * Organization Considerations in Security Policy Formulation and Implementations * Digital Forensics and Crimes * Biometrics * Cyber Security Multimedia and Web Services: * Intelligent Multimedia and its Data Management * Multimedia Information Systems * Multimedia Security * Web Databases * Web Metrics and its Applications * Web Mining including Web Intelligence and Web 3.0. * Web Services * XML and other extensible languages * Semantic Web and Ontology Bitcoin *Challenges and its Roadmap *Crypto-Assets *Current State of Privacy in Bitcoin *Decentralised Technology *Data Licensing *Digital Currencies *Fintechs *Future Payment Implications *Standardisation-Related Issues *Technical, Business and Regulatory Aspects *Technology-based Risks Infonomics and e-Technology: * Infonomics * Information Visualization * Information Management * Information Quality * Technology-Enabled Information * e-Learning * e-Commerce * e-Business * e-Government * e-Society * System Design and Security for e-Services * Synchronizing e-Security Submissions: *You can submit your abstract via email at abstract(a)icitst.org *You can submit your extended abstract or paper online at http://icitst.org/paper-submission/ or email it to extendedabstract(a)icitst.org or papers(a)icitst.org *You can submit your poster via email at posters(a)icitst.org *You can submit your workshop or tutorial proposal via email at workshop-tutorial(a)icitst.org *You can submit your speaker's proposal online at https://icitst.org/call-for-speakers/ or via email at speakers(a)icitst.org Submission Dates: *Abstract and Extended Abstract Submission Date: September 20, 2019 *Notification of Abstract and Extended Abstract Acceptance/Rejection: September 25, 2019 *Proposal for Industrial Presentation: September 20, 2019 *Notification of Industrial Presentation Acceptance: September 25, 2019 *Full Paper Submission Date: September 27, 2019 *Notification of Paper Acceptance/Rejection: October 10, 2019 *Workshops and Tutorials Submission Date: September 20, 2019 *Notification of Workshop and Tutorial Acceptance: September 25, 2019 *Special Track Submission Date: September 20, 2019 *Notification of Special Track Acceptance: September 25, 2019 *Poster/Demo Submission Date: September 20, 2019 *Notification of Poster/Demo Acceptance: September 25, 2019 *Camera Ready Paper Due: November 15, 2019 *Early Registration Deadline: October 25, 2019 *Late Registration Deadline: November 25, 2019 *Conference Dates: December 9-11, 2019 For more details, please contact [1]info(a)icitst.org References 1. mailto:info@icitst.org

1 0

[multiprecision] how to catch both underflow and overflow
by blacksmith＠peerfreedom.org 20 Sep '19

20 Sep '19

Hello, when using boost multiprecision [1] to execute even simple math operations like addition x = x+1 or x-1 it seems on mathematical error it might throw either std::range_error or std::overflow_error or std::underflow_error . Sadly it seems that it's not the case that overflow and underflow are child classes of range_error. So, in more complex math expression to detect any math error you must write catch(....) for all 3 of them (because just catching common std::runtime_error would be too broad and might hide some unrelated error). Is there some better way for this? Perhaps boost should introduce a common type for math error and throw own under/over/range errors that inherit from std's one (for compatibility) and also inherit from boost::math_range_error to allow catch (boost::math_range_error) // either over/under flow or other math [1] for example using type like: boost::multiprecision::number< boost::multiprecision::cpp_int_backend< 64-1, 64-1, boost::multiprecision::signed_magnitude, boost::multiprecision::checked, void> > -- GPG: 31A8 55AA 07BE 5145 65EB 2292 65A6 1F7A 9781 DF89

3 2