- Boost-users - lists.boost.org

Free threaded python support with PEP 779
by george.sykes＠connectorsubsea.com 09 Jul '25

09 Jul '25

Hi, With Python 3.14 introducing free threaded python I was wondering if anyone's had a chance to try this out with Boost Python? Seems like it should be able to help us increase performance on certain types of tasks but not sure if Boost Python supports using the functionality. If not, i'll go give it a crack and see what it's like. Best wishes George

1 0

Issue with Python 3.12 and Concurrent Threads
by jholbrook＠kinetic-vision.com 19 Jun '25

19 Jun '25

Hi, I have a Windows application that has been using Boost Python for many years now, and we are looking to upgrade from Python 3.7 to Python 3.12. This is a C++ application written in Qt5 that uses Boost Python to interface with Python scripts that do some scientific calculations, and the results are displayed in the C++ application. As such, these calculations are by and large done on a concurrent thread so as not to block the UI; however, some quick python functions are run from the main thread. The problem is that *something* changed in the Python 3.12 upgrade, and I'm not sure what -- but now it crashes when I run Python code from a different thread from the one I called Py_Initialize() on. I've tested up to Python 3.11, and I can Py_Initialize() on the main thread and call Python code from any thread and everything works. But starting in Python 3.12, that's no longer the case. If I initialize Python on the UI thread, I can only run it from that thread. If I initialize it on a concurrent thread, I can only run it on a concurrent thread. Since I am using Python, Qt5, and Boost Python, I am not 100% sure where the fault lies, but I am posting this here in case anyone has run into this issue. I haven't found any other references to it online. I can post a minimal example project if that would be helpful for debugging. Essentially, this is the meat of my code: //Initialization Function: Py_Initialize(); //Boost Python Code: boost::python::object main = boost::python::import("__main__"); boost::python::object name_space(main.attr("__dict__")); boost::python::exec_file("testPython.py", name_space, name_space); double testNumber = boost::python::extract<double>(name_space["testNumber"]); qDebug() << testNumber; //print(testNumber) #testPython.py: import random testNumber = random.random() Thanks for any help you can provide.

1 1

Issue with Python 3.12 and Concurrent Threads
by jholbrook＠kinetic-vision.com 18 Jun '25

18 Jun '25

Hi, I have a Windows application that has been using Boost Python for many years now, and we are looking to upgrade from Python 3.7 to Python 3.12. This is a C++ application written in Qt5 that uses Boost Python to interface with Python scripts that do some scientific calculations, and the results are displayed in the C++ application. As such, these calculations are by and large done on a concurrent thread so as not to block the UI; however, some quick python functions are run from the main thread. The problem is that *something* changed in the Python 3.12 upgrade, and I'm not sure what -- but now it crashes when I run Python code from a different thread from the one I called Py_Initialize() on. I've tested up to Python 3.11, and I can Py_Initialize() on the main thread and call Python code from any thread and everything works. But starting in Python 3.12, that's no longer the case. If I initialize Python on the UI thread, I can only run it from that thread. If I initialize it on a concurrent thread, I can only run it on a concurrent thread. Since I am using Python, Qt5, and Boost Python, I am not 100% sure where the fault lies, but I am posting this here in case anyone has run into this issue. I haven't found any other references to it online. I can post a minimal example project if that would be helpful for debugging. Essentially, this is the meat of my code: //Initialization Function: Py_Initialize(); //Boost Python Code: boost::python::object main = boost::python::import("__main__"); boost::python::object name_space(main.attr("__dict__")); boost::python::exec_file("testPython.py", name_space, name_space); double testNumber = boost::python::extract<double>(name_space["testNumber"]); qDebug() << testNumber; //print(testNumber) #testPython.py: import random testNumber = random.random() Thanks for any help you can provide.

1 0

Assignment of boost::dll::import_symbol to boost::shared_ptr fails to compile
by Yuri 14 Jun '25

14 Jun '25

I've encountered the compilation error with this program with boost-libs-1.88.0: #include <boost/dll/import.hpp> #include <boost/shared_ptr.hpp> class API { public: API() { } }; void x() { boost::shared_ptr<API> pluginInterface; pluginInterface = boost::dll::import_symbol<API>("path", "name"); } The error: $ c++ -std=c++20 -c s.cpp -I /usr/local/include/ s.cpp:13:21: error: no viable overloaded '=' 13 | pluginInterface = boost::dll::import_symbol<API>("path", "name"); | ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/include/boost/smart_ptr/shared_ptr.hpp:407:18: note: candidate function not viable: no known conversion from 'boost::dll::detail::import_type<API>' (aka 'st d::shared_ptr<API>') to 'const shared_ptr<API>' for 1st argument 407 | shared_ptr & operator=( shared_ptr const & r ) noexcept | ^ ~~~~~~~~~~~~~~~~~~~~ Compiler: clang-19, but gcc-12 fails in a similar way. It seems that such assignment should work. This error was originally found in the Dakota project (https://github.com/snl-dakota/dakota) This error prevents the Dakota project from compiling. Thanks, Yuri

2 1

mailman upgrade
by Sam Darwin 04 Jun '25

04 Jun '25

Hi, As discussed earlier on the developer list, mailman2 is end-of-life and no longer supported. We are planning to upgrade the mailing lists from mailman2 to mailman3. This will be done in-place, importing the previous archives and user list into a mm3 instance hosted at the same URL lists.boost.org. An example staging instance can be viewed at https://lists.preview.boost.org Mailman3 is more complex than Mailman2 with multiple components including "web" and "core". After the upgrade your account should still exist in the core backend, which means you will continue to receive messages and be able to send emails. However, to interact with the web frontend (optional) you must register an account using the same email address at https://lists.boost.org. Registering in the web portal will require setting up a new password, and confirming the email address. Be sure to use your existing email from before. Any previous passwords will not be valid. If you don't create an account in the web UI, your email subscriptions to the lists continue. But you can't yet log in to configure the account. No action is needed right now. Wait until after the upgrade. All previous messages will be imported to the new system. Additionally, the earlier archives in the form of static plain html pages will be available at https://listarchives.boost.org/ The imported lists are Boost, Boost Announce, and Boost Users. Activity on any other lists is remarkably low such as 1-2 emails per year. Please migrate other discussions to Github Issues, Slack, or one of the main mailing lists. Let us know any concerns. Report issues in the github repository cppalliance/boost-mailman. The tentative schedule is Tuesday June 17. Plan on not using the list for one day, or perhaps a few days. Roll back to mailman2 if something unusual is discovered soon after going live. Chat out-of-band in cpplang slack boost channel.

1 0

boost::process v1 broken in 1_88_0
by Sebastian Koerner 02 Jun '25

02 Jun '25

Hi Boost-Users, I understand that boost process has v2 and v1 is deprecated, but I thought v1 will at least work on for existing stuff. Between 1_87 and 1_88 process v1 stopped working with v1 code. Something changed v1-incompatible with the includes, like: boost::process::child is unknown. error: ‘child’ is not a member of ‘boost::process’ 73 | std::vector<boost::process::child> m_processes; Is this known or easy-to fix?

2 2

[boost] [openmethod] Peer review conclusion
by Дмитрий Архипов 28 May '25

28 May '25

Dear Boost community, the formal review of candidate Boost.OpenMethod has taken place between 28th of April and May 7th. I have received 6 reviews in total. Four of the reviews recommended unconditional, and 1 conditional acceptance. One reviewer recommended to reject the library. The reviews came from: - Joaquin M López Muñoz, - Christian Mazakas, - Ruben Perez, - Yannick Le Goc, - Klemens Morgenstern, - Andrzej Krzemienski. Also, several people have given insightful comments but did not provide a review. I would like to thank all of the people who took their time to write reviews or participate in the discussions. Your effort was very important and valuable. The outcome of the review is that Boost.OpenMethod is ACCEPTED with some CONDITIONS. 1. The convenience header <boost/openmethod.hpp> should be changed to not introduce identifiers to the global namespace. Reviewers suggested several alternatives to that: either moving those global entities into an alternative header, or put them into a dedicated namespace which users could use via using namespace. 2. The library should not choose an arbitrary ambiguous overrider. Virtually all reviewers have expressed strong dislike for this behaviour. The default should be an error. More lax overrider selection may be provided as an option. 3. The library's documentation should be improved in several areas: * The concepts used by the documentation should be explained early on and more thoroughly. * The library should not claim to implement N2216, as it diverges from it significantly. Instead it may remark on being inspired by it. * Better explain potential platform-specific limitations of certain use cases (runtime loading of shared libraries) and error conditions. In addition, I want to discuss several criticisms that have been expressed during the review. One is that essentially the library doesn't solve a problem that is worth solving. That is, you never need an open set of types combined with an open set of operations. I believe that 10 years of library's use should mostly dispel such concerns. I personally have also encountered such a situation in my practice. The second criticism is that the flexibility of the library comes with higher chance of programmer error, as some usual safe guards go out the window. I can attest that in "many types, many operations" situations alternative approaches are comparably error-prone. It seems to me that this is largely inherent to the complexity of the problem. My advice to the author is to highlight dangerous situations, so that potential users can better evaluate if the added flexibility is worth it. Thanks to Jean-Louis Leroy for submitting this library to Boost. And thanks again to the reviewers and everyone who provided feedback, who ultimately made this review possible.

1 0

How to replace get_io_service()/get_io_context()-calls
by Klebsch, Mario 21 May '25

21 May '25

Hello, I have been using boost::asio for about a decade. I was using boost-1_63. I use get_io_service() (e.g. on a socket) to get a reference to the io_context, e.g. to post(…) on that io_context. I have read, that get_io_service() got deprecated and was removed. I now am facing, the challenge to find a replacement for get_io_service(). I found https://stackoverflow.com/a/39447000/6832488 suggesting to use get_executor().context() as a replacement for get_io_service(). And although the reference returned from get_executor().context() points to the same address as my io_context, it does have the wrong type. I cannot do socket.get_executor().context().post(…). I also found https://stackoverflow.com/a/67773642/6832488, suggesting to (C-Style)cast s to (boost::asio::io_context&). > #define GET_IO_SERVICE(s) ((boost::asio::io_context&)(s).get_executor().context()) But trying C++ (more or less) type safe to static_cast< boost::asio::io_context&>(s) fails to compile. I found that I misinterpreted > ((boost::asio::io_context&)(s).get_executor().context()) to cast (s) to ((boost::asio::io_context&). When I use > static_cast<boost::asio::io_service&>(s.get_executor().context()) My code finally compiles. I must admit, that I find the documentation of get_executor() quiet useless. Btw, Boost.org seems to be useless, too. When I try to read https://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/reference.html, I get > Error 503 first byte timeout. ☹ The documentation of basic_socket::get_io_service() in version 1_40_0 lists its signature as: > boost::asio::io_service & get_io_service(); That is useful, I can go to the documentation of boost::asio::io_service and find the methods usable on the io_service like post(). But for the current boost version 1_88_0, the signature of basic_stream_socket::get_executor() is documented as: > const executor_type & get_executor(); Ok, executor_type is documented as of basic_stream_socket::executor_type > typedef Executor executor_type; Executor is a template parameter. But when I look at ip::tcp::socket, I find: > typedef basic_stream_socket< tcp > socket; But basic_stream_socket is documented as > template< > typename Protocol, > typename Executor> > class basic_stream_socket : > public basic_socket< Protocol, Executor > Where the hell is the 2nd template parameter for basic_stream_socket? There is no default value of Executor, so how does the template instantiation of basic_stream_socket<tcp> compile? How am I supposed to find out, that I can invoke context() on the return value of get_executor()? I am totally screwed up with the documentation of current boost::asio. ☹ I hope, anybody on this mailing list can enlighten me. Many thanks in advance, Mario Klebsch Mario Funktion | R&D Tel: +49 (0) 531 38 701 718 Raum: Braunschweig, E20 Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke. This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.

2 1

Boost:1.82.0 ASIO changed its behavior
by Nedelin Rusev 21 May '25

21 May '25

Hi, Recently I inherited an old project, which uses boost 1.65.0 and ASIO, for custom implementation of the SCTP protocol. Technically it adapts the existing ASIO TCP for SCTP. Another implementation uses this ASIO-SCTP to asynchronously send and receive data. My task was to make both implementations work with any boost version from 1.65.0 to 1.87.0. I did the necessary changes and the project now compiles and runs, but I face a test deviation with boost versions 1.82.0 and above. The test is more or less simple: - we have pre-generated data - we start a server, which only receives data and stores it in file per connected client - we start multiple clients, each running in its own thread. Each client sends its own data to the server at a random moment - finally we check if the server has received the same data as the clients have sent. With boost versions up to 1.81.0 the test passes OK. But with boost version 1.82.0 we observe wrong order of the data stored by the server. To illustrate it roughly: Client sends: 0,1,2 Server stores: 0,2,1 (0 is OK, Next we should have 1, but we get 2). Note: the real test data is hundreds of bytes long, not single digits. Note: the test seems to have issues, but on the particular machine, the behavior is consistent: test is OK with boost 1.81.0 and NOK with boost 1.82.0 I suspect the problem has something to do with the "on_immediate()" extension, introduced in boost 1.82.0. Somehow it speeds up the client threads execution and changes the order of the sent data. I failed to find any similar problems, reported in internet (git, boost forums, etc) I have enabled BOOST_ASIO_ENABLE_HANDLER_TRACKING and, if I get the log right, client threads are executed faster. I have attached the handler tracking logs for boost versions 1.81.0 and 1.82.0. My question is how to keep the old code behavior (pre 1.82.0) with later versions? Is there any way to disable the "on_immediate()" functionality? Are there any guidelines for using later versions of boost ASIO (1.82.0 and later)? Providing a simplified example test is hard, as the code-base is quite large. I will try to make something up, but this will take time. Thank you!

2 1

Issues with boost executor_work_guard
by João Fernando Silva 22 Apr '25

22 Apr '25

Hello all, We are facing some issues with boost::asio::executor_work_guard. We are spawning some threads which are bound to a boost::asio::io_context and proteced by a boost::asio::executor_work_guard so that they do not exit even if there is no work to be done. However, despite the work_guard still being valid, we see that the threads exit because boost::asio::detail::scheduler::outstanding_work reaches 0. All operations added to the queue are posted asynchronously. The boost version in use is 1.75 (also tested with 1.78 and the behaviour is the same). Could you help us on the following topics so that we can understand what the root cause may be? 1 - We created an implementation to track the number of elements on boost::asio::detail::op_queue, is this implementation valid? uint32_t size() { auto tmp_op = front_; uint32_t size{0}; while (tmp_op != 0) { ++size; tmp_op = op_queue_access::next(tmp_op); } return size; } 2 - Assuming the approach above is correct, we are trying to compare the values of outstanding_work with the returned value of op_queue.size(). However, these values do not seem to correlate, is this to be expected? 3 - Was this issue observed by someone else? If so what were the root causes? Thanks! Kind Regards, João Silva The information in this communication may contain confidential or legally privileged information. It is intended solely for the use of the individual or entity it addresses and others authorized to receive it. If you are not an intended recipient, you are hereby notified that any disclosure, copying, distribution or action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication by error, please notify us immediately by responding to this e-mail and then delete it from your system. Critical TechWorks is not liable for the proper and complete transmission of the information in this communication nor for any delay in its receipt This e-mail is environmentally friendly, just like Critical TechWorks, which lives in a paper-free atmosphere. Therefore, please consider the environment before printing it!

3 5