- Boost-users - lists.boost.org

[Boost.Asio] Segmentation fault when ::getaddrinfo() returns EAI_SYSTEM without system error code set (errno = 0) - is this a bug?
by Nils Frielinghaus 04 Oct '21

04 Oct '21

Hello Boost users, I experienced a segmentation fault inside Boost in the following scenario: o There was an illegal DNS entry o When resolving that illegal DNS entry on a Yocto-based embedded Linux distribution, ::getaddrinfo() returned with the error code EAI_SYSTEM but errno was set to 0 o The function translate_addrinfo_error(int) in boost/asio/detail/impl/socket_ops.ipp translates this into boost::system::error_code(0, boost::asio::error::get_system_category()) o This is then interpreted as a success by the calling function and the other output parameters of ::getaddrinfo() are accessed which resulted in the segmentation fault My question would be whether this should be considered a bug in the Boost ASIO library? One could argue that the system should not return EAI_SYSTEM with errno not being set properly. But one could also argue that returning EAI_SYSTEM indicates that something went wrong and that the output parameters are not to be accessed. Nils ------ Nils Frielinghaus

4 11

Problem understanding 'boost::intrusive::list_member_hook<>'
by John Emmas 14 Sep '21

14 Sep '21

I'm in the early stages of trying to understand boost::intrusive::list' so forgive me if I'm just doing something stupid!! Using VS2019 I wrote a small demo app which uses 'boost::intrusive::list_base_hook<>':- #include <boost/intrusive/list.hpp> #include <string> #include <iostream> using namespace std; class animal : public boost::intrusive::list_base_hook<> { public: animal (string n, int l) : name{move(n)}, legs{l} {} string name; int legs; }; using animal_list = boost::intrusive::list<animal>; template<typename T> void print_list (const boost::intrusive::list<T>& elem) { for (const T& a : elem) cout << "A " << a.name << " has " << a.legs << " legs" << '\n'; } int main() { animal a1{"dog", 4}; animal a2{"spider", 6}; animal a3{"budgie", 2}; animal_list animals; animals.push_back(a1); animals.push_back(a2); animals.push_back(a3); print_list (animals); return 0; } Everything runs fine and I see the expected output but I've noticed that some other developers use something called a 'list_member_hook' rather than my 'list_base_hook' - so class animal would look like this:- class animal { public: animal (string n, int l) : name{move(n)}, legs{l} {} string name; int legs; boost::intrusive::list_member_hook<> _animal_hook; }; and then later on in the program there'd be a couple of lines looking something like this:- typedef boost::intrusive::member_hook<animal, boost::intrusive::list_member_hook<>, &animal::_animal_hook> AnimalHookOption; typedef boost::intrusive::list<animal, AnimalHookOption> Animals; But when I try that here, VS2019 throws up this compiler error:- error C2039: 'default_list_hook': is not a member of 'animal' Can anyone explain what I'm doing wrong?? John

4 18

Support end date of boost version ,1.76.0
by rajesh daggumati 08 Sep '21

08 Sep '21

Hi Team, When is supporting end date for boost 1.76.0. Please let me know asap. Regards, Rajesh D

2 1

Linking Problem
by Stephen P. Molnar 04 Sep '21

04 Sep '21

I have successful compiled an application on my Debian-10 platform using boost-1-67. It is an essential part of my computations chemistry pipe line. Now Debian 11 has been released. I have installed it in a VM in order to make sure that the app is compilable in Debian 11 with boost-1-74 (the Debian12 version of boost), before upgrading my Linux platform. I installed boost in /user/ilocal. The makefile is: BASE=/usr/local BOOST_VERSION=1_74_0 BOOST_INCLUDE = $(BASE)/include C_PLATFORM= -pthread GPP=g++ C_OPTIONS= -O3 -DNDEBUG BOOST_LIB_VERSION= include ../../makefile_common The test compile went well until the link stage. The process stopped with: g++ -pthread -ansi -Wno-long-long -O3 -DNDEBUG -I /usr/local/include -L/usr/local/lib -L. -o gwovina main.o cache.o coords.o current_weights.o everything.o grid.o szv_grid.o manifold.o model.o gwo.o gwo_mutate.o my_pid.o naive_non_cache.o non_cache.o parallel_gwo.o parse_pdbqt.o pdb.o quasi_newton.o quaternion.o random.o ssd.o terms.o weighted_terms.o rotamer.o -l boost_system -l boost_thread -l boost_program_options /usr/bin/ld: cannot find -lboost_system /usr/bin/ld: cannot find -lboost_thread /usr/bin/ld: cannot find -lboost_program_options collect2: error: ld returned 1 exit status make: *** [../../makefile_common:34: gwovina] Error 1 Even my limited knowledge (my original programming experience was with FORTRAN II in the early 1960's), I can see the the problem. Unfortunately, I don't know the solution. Assistance will be greatly appreciated. Thanks om advance. -- Stephen P. Molnar, Ph.D. www.molecular-modeling.net 614.312.7528 (c) Skype: smolnar1

2 1

Comment on divide_unsigned_helper
by Neill Clift 03 Sep '21

03 Sep '21

Hi, I was trying to understand the algorithm inside the main divide routine. I struggled with this bit of code: if ((prem[r_order] <= py[y_order]) && (r_order > 0)) { double_limb_type a = (static_cast<double_limb_type>(prem[r_order]) << CppInt1::limb_bits) | prem[r_order - 1]; double_limb_type b = py[y_order]; double_limb_type v = a / b; if (v <= CppInt1::max_limb_value) { guess = static_cast<limb_type>(v); --r_order; } } I was trying to understand why we essential set guess to 1 in the case that the division is too big. I finally realized that the only way we can have v > CppInt1::max_limb_value is if we have prem[r_order] == py[y_order]. Some simple inequalities with floor can convince you of this. So in the case of equality we do an expensive divide and test when we could move the test outside like this: limb_type guess = 1; if (r_order == 0) { <-------- do this first to simplify guess = prem[0] / py[y_order]; } else if (prem[r_order] == py[y_order]) { <----------- handle it here to avoid the divide guess = 1; ... This leads to another question. Why is this line: guess = prem[0] / py[y_order]; not this line: guess = prem[0] / py[0]; Logically for division it must be the second line. In fact this loop has the invariant that r_order >= y_order. That makes sense for division. So the divisor must be py[0]. That suggests a divisor with one element and we handle that case via a special divide. So that code is not needed I believe. We end up with this: BOOST_ASSERT(r_order >= y_order && y_order >= 1); if (prem[r_order] == py[y_order]) { guess = 1; } else if (prem[r_order] < py[y_order]) { double_limb_type a = (static_cast<double_limb_type>(prem[r_order]) << CppInt1::limb_bits) | prem[r_order - 1]; double_limb_type b = py[y_order]; double_limb_type v = a / b; BOOST_ASSERT(v <= CppInt1::max_limb_value); guess = static_cast<limb_type>(v); --r_order; } else { double_limb_type a = (static_cast<double_limb_type>(prem[r_order]) << CppInt1::limb_bits) | prem[r_order - 1]; double_limb_type b = (y_order > 0) ? (static_cast<double_limb_type>(py[y_order]) << CppInt1::limb_bits) | py[y_order - 1] : (static_cast<double_limb_type>(py[y_order]) << CppInt1::limb_bits); BOOST_ASSERT(b); double_limb_type v = a / b; guess = static_cast<limb_type>(v); } BOOST_ASSERT(guess); // If the guess ever gets to zero we go on forever.... Some simple random divide tests seem to show a little over 2% improvement from doing this. Of course this could just be code layout changes. Just thinking that the 64 bit values are random would make me think this case is rare but I guess we subtract out multiples of the divisor and cause this to happen more for reasons that are hard to understand (for me anyway). I see the path hit a lot. Neill.

1 0

Jamshell query
by Mohammed Zahid 03 Sep '21

03 Sep '21

Hi, I am trying to run boost build in distributed environment by setting JAMSHELL I tried setting as environment variable and passing as command line variable -sJAMSHELL= Both didn't work https://github.com/bfgroup/b2/discussions/78 Need you guidence on how to do it. Thanks, Mohammed zahid

1 0

3D Tree Queries
by Glenn, Rachel M 02 Sep '21

02 Sep '21

I have a question about 3D RTree spatial queries, like a cube, sphere, or something. Are there any examples of how that can be done? I know how to do it for 2D RTree. Do you recommend the regular RTREE or a is there another one to use, like an rstar, that would be better? Thanks, Rachel

3 2

[Compute] automatically determine work group size
by Stephan Menzel 30 Aug '21

30 Aug '21

Hello everyone, I have recently made the switched an existing OpenCL application to boost compute. For reasons mostly. Now the transition went well for the most part but I struggle with one feature that appears to be missing. The determination of the local work group size. Originally the code was using clEnqueueNDRangeKernel() which has an option for the local work group size called local_work_size. When left empty, the system will determine that value itself at a small cost. Boost compute doesn't seem to have that. When I process an image for example: command_queue.enqueue_nd_range_kernel(kernel, bc::extents<2>{ 0, current_line }, bc::extents<2>{ width, height }, bc::extents<2>{ 128, 1 }); The last parameter is very hard for me to understand. I know roughly what it is and I understand it has to be dividable by 64, the total size (width * height) however has to be a multiple of it too, so there's a bunch of rules that apply and I would much rather leave that auto-determined as it was before. Leaving it bc::extents<2>{ 0, 0 } throws an assertion. So, essentially: Is there a way to leave it empty to be auto-defined? Cheers, Stephan

1 0

boost/rational.hpp and VS2019
by John Emmas 24 Aug '21

24 Aug '21

I'm guessing this might be solvable by updating to a newer version of boost (currently I'm running ver 1.71.0) but before updating, I wondered if there might be something obvious that 'm missing.... I'm building with Visual Studio 2019 and I get a whole bunch of errors simply by adding this line to an empty source file:- #include "boost/rational.hpp" It seems to be the same 6 errors but at various different lines - i.e. these errors, over & over again:- Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(146,19): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(146,8): error C2146: syntax error: missing ';' before identifier '_mm_macc_ps' Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(147,20): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(147,9): error C2146: syntax error: missing ';' before identifier '_mm_macc_pd' Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(148,19): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(148,1): error C2086: 'int __m128': redefinition I just wondered if this might ring a bell with someone? e.g. might there be some preprocesser #define that I should've defined? (or a #define that I shouldn't be defining...) Thanks for any suggestions, John

3 18

Boost's Stage\Lib *.a Files
by Alexander Tanseco 23 Aug '21

23 Aug '21

I am running a tutorial program and I found out that in the program's build options under Linker settings/Link Libraries I can put both or either of the ff and the program compiles & runs without errors. What is the difference between the two? libboost_filesystem-mgw8-mt-d-x64-1_77.dll.a OR libboost_filesystem-mgw8-mt-x64-1_77.dll.a

2 1