- Boost-users - lists.boost.org

Embedded install paths in CMake files for Boost 1.79
by Alex 05 Jul '22

05 Jul '22

Apologies if this is the wrong list. I tried boost-build but I'm not sure if my message was verified (I don't see it in the archive). I'm trying to make a build of Boost that includes the generated CMake files. For my case, I need to install the files to a staging area before packaging them up for installation in the target environment. I've tried "b2 --stagedir <dir> stage" but the generated CMake files still include the stagedir path in them, instead of the install prefix specified during bootstrap, which triggers errors in the packaging system I need to use. I'm also not sure if it's then possible to just install the headers to the same staging location. Is there a way to install to a staging location while the CMake files have the paths to the final install location? CMake uses CMAKE_STAGING_PREFIX for this but I can't find an equivalent for b2. I guess it must be required for cross-compiling though, if you want to support CMake on the target? Regards, Alex

1 0

Excessive dynamic allocation when using boost::split(..., boost::is_any_of(", "))?
by Dominique Pellé 05 Jul '22

05 Jul '22

Hi This following program shows many allocations coming from boost::split(..., boost::is_any_of(",")): ``` $ cat split.cpp #include <string> #include <cstdio> #include <boost/algorithm/string.hpp> #include <boost/container/small_vector.hpp> int main() { std::string str = "foo,bar,foobar,quux"; std::size_t s = 0; for (int i = 0; i < 100; ++i) { boost::container::small_vector<std::string, 4> v; #ifdef USE_IS_ANY_OF boost::split(v, str, boost::is_any_of(",")); #else boost::split(v, str, [](const char c) { return c == ',';}); #endif s += v.size(); } fprintf(stderr, "%zu\n", s); } ``` When using boost::is_any_of(","), there are 7 dynamic allocations per loop iteration whereas when using the lambda predicate, there are 0 dynamic allocation per loop as shown below: ``` $ clang++ -std=c++14 -DUSE_IS_ANY_OF split.cpp $ heaptrack ./a.out ... allocations: 702 $ clang++ -std=c++14 split.cpp $ heaptrack ./a.out ... allocations: 2 ``` I suspect that there are potential optimizations in Boost here to avoid so many allocations when boost::is_any_of(",") is used. Regards Dominique

3 2

Boost.URL review planned for 13-22 August 2022
by Mateusz Loskot 29 Jun '22

29 Jun '22

Folks, Klemens Morgenstern kindly volunteered [1] as the Review Manager (thanks Klemens!) for the Boost.URL [2], so we have planned the review shortly after the upcoming release of the Boost 1.80. Check the Review Schedule [3] for details! [1] https://lists.boost.org/Archives/boost/2022/06/253225.php [2] https://lists.boost.org/Archives/boost/2022/04/252814.php [3] https://www.boost.org/community/review_schedule.html Best regards, -- The Boost Review Wizards Mateusz Loskot

2 2

Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

Greetings fellow users, library authors, maintainers, review wizards, release wizards, and Boost Foundation Board members! As part of our ongoing effort to continue the revitalization of Boost, a handful of us have taken the reins to post about Boost on social media. We have postings on Reddit and Hacker news, blog posts about the new efforts in Boost.Unordered, and new tweets. However, we could use your help! Right now the Boost Twitter account has a measly 957 followers. It would be great to increase our reach, so I'm asking everyone if they could be so kind as to Follow the official Boost Twitter account here: <https://twitter.com/Boost_Libraries> and then amplify our messages by Liking and Retweeting. Starting with this pinned tweet, which everyone will see when they visit the Boost Libraries Twittter profile page: <https://twitter.com/Boost_Libraries/status/1539003321939202048> Following the Boost Twitter account will give you up-to-date information about what is going on with Boost, including articles and mentions on other social media sites. Here is what we have so far: <https://www.reddit.com/r/cpp/comments/vfdcrz/advancing_the_state_of_the_art…> <https://www.reddit.com/r/cpp/comments/vbdr3z/new_boostunordered_containers_…> <https://twitter.com/hackernewstop10/status/1538622706035343364> <https://news.ycombinator.com/item?id=31801814> To summarize, engaging with Boost related content on social media will enhance our profile - any help is appreciated! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 9

[JSON] Vote for Boost.JSON in this poll!
by Vinnie Falco 21 Jun '22

21 Jun '22

There's an online poll asking about which JSON library you use. If you use Boost.JSON consider voting for it: <https://meetingcpp.com/mcpp/survey/?q=2> Also, consider voting for it if you _don't_ use Boost.JSON, but you want to. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

[Locale] IBM437 encoding not supported in wconv
by Arnold, Stefan 14 Jun '22

14 Jun '22

Why is the IBM437 encoding not supported in boost::locale with the Win32 API ("wconv") backend? The following call will fail with a boost::locale::conv::invalid_charset_error when using the Win32 API backend: boost::locale::conv::to_utf<char>("abc", "IBM437") This is because "ibm437" is not contained in the all_windows_encodings variable in wconv_codepage.ipp (nor is "cp437" or another alias). As per Win32 API documentation (https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringap…, https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers) this encoding is supported in Win32 API. Furthermore, IBM437 is the legacy encoding of filenames in ZIP files, so it should be quite common.

1 1

Any objections to making C++14 the current baseline for Boost support and testing?
by John Maddock 10 Jun '22

10 Jun '22

Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.

8 11

[thread] attribute constructor failing to compile
by Jeanette C. 07 Jun '22

07 Jun '22

Hey hey, using boost 1.78 from the Archlinux repository, using the thread constructor with boost::thread::attributes as first argument fails to compile. The relevant code from the small test program is this: void work(bool& done) // simple main function for the thread int main() { bool done = false; boost::thread::attributes attr; // all changes commented out in the program boost::thread th1(attr, work, std::ref(done)); // some code, sleep and set done to true th1.join(); return 0; } g++ 11.2.0 reports the following error: In file included from /usr/include/boost/thread/detail/thread.hpp:33, from /usr/include/boost/thread/thread_only.hpp:22, from /usr/include/boost/thread/thread.hpp:12, from thread_prio.cpp:1: /usr/include/boost/bind/bind.hpp: In instantiation of 'void boost::_bi::list2<A1, A2>::operator()(boost::_bi::type<void>, F&, A&, int) [with F = boost::thread_attributes; A = boost::_bi::list0; A1 = boost::_bi::value<int (*)(bool&)>; A2 = boost::_bi::value<std::reference_wrapper<bool> >]': /usr/include/boost/bind/bind.hpp:1273:18: required from 'boost::_bi::bind_t<R, F, L>::result_type boost::_bi::bind_t<R, F, L>::operator()() [with R = void; F = boost::thread_attributes; L = boost::_bi::list2<boost::_bi::value<int (*)(bool&)>, boost::_bi::value<std::reference_wrapper<bool> > >; boost::_bi::bind_t<R, F, L>::result_type = void]' /usr/include/boost/thread/detail/thread.hpp:120:18: required from 'void boost::detail::thread_data<F>::run() [with F = boost::_bi::bind_t<void, boost::thread_attributes, boost::_bi::list2<boost::_bi::value<int (*)(bool&)>, boost::_bi::value<std::reference_wrapper<bool> > > >]' /usr/include/boost/thread/detail/thread.hpp:118:18: required from here /usr/include/boost/bind/bind.hpp:298:35: error: no match for call to '(boost::thread_attributes) (int (*&)(bool&), std::reference_wrapper<bool>&)' 298 | unwrapper<F>::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_]); | ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The syntax is based on this part of the manual: https://www.boost.org/doc/libs/1_79_0/doc/html/thread/thread_management.htm… Is that perhaps a feature only introduced in version 1.79 of the Boost libraries? Best wishes and thanks for any pointers, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c Don't care about money It doesn't give me half the thrill <3 (Britney Spears)

3 3

[Compute] Auto-determine work group size
by Stephan Menzel 12 May '22

12 May '22

Hi everyone, perhaps someone can answer a question about Boost.Compute. I have recently switched to it from using native OpenCL. Most of the things work fine except for one quirk: OpenCL allows for auto-determining the work group size when using enqueue_kernel(). As the correct work group size is still a mystery to me after using OpenCl for almost a year now I normally left this parameter to 0 to let OpenCL figure it out. With Boost.Compute and the equivalent function enqueue_nd_range_kernel() this doesn't seem to be possible. I have to use a parameter like boost::compute::extents<2>{ 8, 2 } as local_work_size. Leaving it 0 or using extents<2>{ 0, 0 } doesn't do the trick and I'm getting "Invalid work group size". This forces me to guess values until one works, which is extremely error prone and breaks all the time with images of different resolutions. Does anyone know how I can use OpenCL's auto-work-group-size feature in Boost.Compute? Cheers, Stephan

1 0

Iterating over each point within a geometry::box
by Keith Bennett 11 May '22

11 May '22

I want to iterate over every point within a geometry::model::box<point>. I want to be able to do that with iterators so that I can also use all (or most of) the standard algorithms like for_each or all_of or etc. Initially my code used several loops, one for each axis, like so for a 2d point: for (int x = box.min_corner().template get<0>(); x <= box.max_corner().template get<0>(); ++x) { for (int y = box.min_corner().template get<1>(); y <= box.max_corner().template get<1>(); ++y) { callback(point(x,y)) } } There are several places where this occurs. Some loops have the x axis first, others the y axis first -- and this has performance issues when translating the point to a container. Some loops were erroneously considering right-open intervals with less-than instead of less-than-or-equal-to comparisons. So I've had to fix bounding bugs and performance issues in multiple places that are caused by these manual loops. I've gone and unified a lot of that to use templated functions that basically duplicate some of the functionality in the standard. But that's not tractable and still doesn't use iterators so most of <algorithm> is still off-limits: namespace mynamespace { template <class box, enable_if vomit, blah blah> void for_each(const box& b, const std::function<void(const typename box::point_type&)> callback) { // the manual loops here, not repeated for brevity } } Then I've replaced most of those manual loops with calls to: mynamespace::for_each(box, [](const point& p){ // do some work here }); So I want to instead do: for (const auto& point : box) { callback(point); } Satisfying that would make a lot of places simpler and easier to read. I think it should also help to enable use of a lot of the stuff in the standard <algorithm> I understand that it might be difficult for, eg, a box containing a point with floating point types. But that's fine ... I'm only looping over integral points anyway. I'd also prefer to have the ability to control the axis order ... eg do I want x or y on the inner/outer loop? Do I want to only iterate over the y axis? I'm using C++14 and boost 1.70 at the moment. There's some friction against upgrading. But if this problem is solved in a future version -- like with C++20 ranges -- then that would be a strong point for me to convince my team to upgrade. I could go and write up some iterators myself of course. But before I do that I wondered if someone else has already solved this problem and I just haven't found the solution. Thoughts? -- Keith Bennett

1 0