- Boost-users - lists.boost.org

Re: [Boost-users] Cannot open boost lib file when building CLI dll
by Michael Pogue 28 Oct '22

28 Oct '22

> > I am trying to build a CLR dll file in VS22 and dotnet 6.0 that references >> boost. When I build, I get the following error. >> LNK1104 cannot open file 'libboost_program_options-vc142-mt-x64-1_76.lib' >> >> - This file does exist. >> - I have restarted to make sure the file isn't locked. >> - I have tried building as 32 and 64 bit. >> - I have tried 3 different versions of boost >> >> The problem is reproduced by this project: >> https://github.com/MajorMajor0/boostRepro. >> Any help would be much appreciated. >> >

1 0

Norms methods
by General Magic - Teodora Bogdan 26 Oct '22

26 Oct '22

Hello, I was using the Boost library and I wanted to call the l2_norm() method from "boost/math/tools/norms.hpp", but is says that the namespace boost::math::tools doesn't contain l2_norm() method. When I looked into it, I saw that the namespaces at the beginning of the file were written"boost::math::tools" instead of "namespace boost { namespace math { namespace tools {...". Can this be fixed? Have a nice day, Teodora Bogdan CONFIDENTIALITY NOTICE: This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. DISCLAIMER: General Magic accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing and duly signed on behalf of General Magic by an authorized officer. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of General Magic. No employee or agent is authorized to conclude any binding agreement on behalf of General Magic with another party by email without express written confirmation which is duly signed on behalf of General Magic by an authorized officer. Thank you.

3 3

Boost::serialization detection of Cxx Standard
by Georg Gast 14 Oct '22

14 Oct '22

Hi, I developed a patch and a test to serialize std::pmr::(w)strings in all 3 archive types. The test I set the requirement to <cxxstd>17. It works so far but when I compile the library for using it in my application the "hidden" functions behind "BOOST_NO_CXX17_MEMORY_RESOURCE" are not found by the linker as the define is set when the library is compiled. How to work around this? Bye Georg

2 2

Is there any official documentation on shutdown procedure for ASIO SSL socket?
by Ivan Matek 11 Oct '22

11 Oct '22

There is this SO answer https://stackoverflow.com/a/25703699/ with Vinnie comment from 8y ago that it should be added to documentation. :) I can not find anything in the documentation so I presume the documentation/example does not exist, but I decided to double check. regards, Ivan

3 2

Very slow destructors of binary_oarchive and filtering_streambuf
by boost.5nyej＠simplelogin.com 03 Oct '22

03 Oct '22

Hello, I just posted a question on StackOverflow, but I realised that this mailing list might be a better place. The link to the question is: https://stackoverflow.com/questions/73938656/very-slow-destructors-of-binar… Tl;dr; I have a code that serializes a big object by using binary_oarchive and filtering_bufstream. The writing on its own takes around 28 minutes, but the deconstructors of the mentioned classes take 37 and 36 minutes, respectively. It is very strange to me that they would take so much time to run, as the first deconstructor adds only 2KiB of data, and the second deconstructor doesn't change anything. Could you help me find the root cause of those execution times?

1 0

[serialisation] Strange "direct access" warning on OSX for basic_text_oprimitive
by Marco Craveiro 29 Sep '22

29 Sep '22

Hi Boost Users, First, a great thanks to the authors of the boost serialisation library, which I have used successfully across projects and has proven invaluable. Now to my problem. I have been investigating for a little while a strange warning I get when linking on OSX; the results of my investigation can be found here [1]. The TL; DR of it is as follows: my OSX debug build has a warning (indented for ease of reading): ld: warning: direct access in function 'boost::archive::basic_text_oprimitive< std::__1::basic_ostream<char, std::__1::char_traits<char> > >::~basic_text_oprimitive()' from file 'vcpkg_installed/x64-osx/debug/lib/libboost_serialization.a(basic_text_oprimitive.o)' to global weak symbol 'std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::endl<char, std::__1::char_traits<char> > (std::__1::basic_ostream<char, std::__1::char_traits<char> >&)' This warning is caused by a mismatch in visibility settings between my project and vcpkg's build of boost. However, as far as I can see, both projects are using "-fvisibility=default", meaning there should be no mismatch. Also, no other warnings show up but if I change the project settings I then get hundreds of warnings (again, for details see ticket). What I find even more puzzling is that I am using all three types of archives (Text, XML and Binary). Of these three, only Text produces this warning. As the problem is with the destructors, I did a quick inventory of the destructors to see how they differ: basic_xml_oarchive.hpp: [2] BOOST_ARCHIVE_OR_WARCHIVE_DECL ~basic_xml_oarchive() BOOST_OVERRIDE; basic_text_oarchive.hpp: [3] ~basic_text_oarchive() BOOST_OVERRIDE {} basic_binary_oarchive.hpp: [4] no destructor. So my question is, should text archive also have a BOOST_ARCHIVE_OR_WARCHIVE_DECL macro, and would that fix my warning? If so I can submit a PR. Many thanks for your time. Marco [1] https://github.com/Microsoft/vcpkg/issues/4497 [2] https://github.com/boostorg/serialization/blob/develop/include/boost/archiv… [3] https://github.com/boostorg/serialization/blob/develop/include/boost/archiv… [4] https://github.com/boostorg/serialization/blob/develop/include/boost/archiv… -- Marco Craveiro MD, Domain Driven Consulting blog: https://mcraveiro.github.io/index.html twitter: https://twitter.com/MarcoCraveiro That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea—which is a-kind-of itself, so that the system is completely self-describing— would have been appreciated by Plato as an extremely practical joke [Plato]. -- Alan Key

1 0

Re: [Boost-users] [boost] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 22 Sep '22

22 Sep '22

On Thu, Sep 22, 2022 at 8:57 AM Peter Dimov <pdimov(a)gmail.com> wrote: > > That's complete nonsense. First, Microsoft invented __forceinline, so > making BOOST_FORCEINLINE be a no-op on the very compiler for which > the feature has been added would be ridiculous. Second, it does force > inlining, that's why it's called __forceinline. The whole point of the warning > is to warn about the rare cases where the compiler does not honor the > command; it exists because people want to know whether their "force > inline" orders are ignored. But no boost user wants to be warned about some internal implementation detail of a boost library. So every boost usage of BOOST_FORCEINLINE needs to add a #pragma warning(disable: 4714), awesome! Who is the maintainer of variant anyways? -- Frank

1 0

TSan error with boost::interprocess::message_queue on macOS ARM
by vl01＠jens-carl.de 22 Sep '22

22 Sep '22

Hello List, I'm using the boost::interprocess::message_queue in a project and to verify everything is working I created a test case. In that test case I'm sending and receiving data via threads. The test passes on Linux, Windows with no sanitizer and also with AddressSanitizer and ThreadSanitizer. I recently added Apple Silicon (M1) to the test matrix and now the test run with ThreadSanitizer enabled fails. Is boost::interprocess::message_queue thread-safe? Can the reported TSan error be an false-positive? If it that case, what test can I run to verify that? I looked at code of atomic_cas32() and it uses the legacy built-in __sync_val_compare_and_swap(). Can it be that that built-in isn't supported on ARM? Is there a newer built-in which should be used? The reported TSan error: -- snip ================== WARNING: ThreadSanitizer: data race (pid=4146) Atomic write of size 4 at 0x000104af4028 by thread T2: #0 __tsan_atomic32_compare_exchange_val <null>:81245684 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x57854) #1 boost::interprocess::ipcdetail::atomic_cas32(unsigned int volatile*, unsigned int, unsigned int) atomic.hpp:581 (tsan_boost:arm64+0x100005b30) Previous read of size 4 at 0x000104af4028 by thread T1: #0 boost::interprocess::ipcdetail::spin_mutex::try_lock() mutex.hpp:100 (tsan_boost:arm64+0x100006eb0) #1 void boost::interprocess::ipcdetail::try_based_lock<boost::interprocess::ipcdetail::spin_mutex>(boost::interprocess::ipcdetail::spin_mutex&) common_algorithms.hpp:62 (tsan_boost:arm64+0x100006e28) SUMMARY: ThreadSanitizer: data race atomic.hpp:581 in boost::interprocess::ipcdetail::atomic_cas32(unsigned int volatile*, unsigned int, unsigned int) -- snap Here is a code example which demonstrates the test case -- snip #include <boost/interprocess/ipc/message_queue.hpp> #include <iostream> #include <vector> #include <thread> #include <memory> struct MessageQueueImpl { MessageQueueImpl() { boost::interprocess::permissions file_permissions; file_permissions.set_permissions(0660); queue = std::make_unique<boost::interprocess::message_queue>(boost::interprocess::create_only, "tsanqueue", 10, 15, file_permissions); } std::unique_ptr<boost::interprocess::message_queue> queue; }; class MessageQueue { public: MessageQueue() : m_impl(std::make_unique<MessageQueueImpl>()) {} void send(const std::vector<uint8_t>& buffer) { m_impl->queue->send(buffer.data(), buffer.size(), 0); } void receive(std::vector<uint8_t>& buffer) { boost::interprocess::message_queue::size_type received_size = 0; buffer.resize(m_impl->queue->get_max_msg_size()); uint32_t prio; m_impl->queue->receive(buffer.data(), buffer.size(), received_size, prio); buffer.resize(received_size); } private: std::unique_ptr<MessageQueueImpl> m_impl; }; int main() { auto uut = std::make_unique<MessageQueue>(); std::thread sender([&uut]{ for(uint8_t i = 0; i < 3; ++i) { const std::vector<uint8_t> send_buffer = {i}; uut->send(send_buffer); } }); std::thread receiver([&uut]{ for(uint8_t i = 0; i < 3; ++i) { std::vector<uint8_t> receive_buffer; uint32_t prio; uut->receive(receive_buffer); std::cout << "buffer received:\n"; for (const auto i : receive_buffer) { std::cout << i << '\n'; } } }); if(sender.joinable()) { sender.join(); } if(receiver.joinable()) { receiver.join(); } return 0; } -- snap Cheers, Jens

3 3

Re: [Boost-users] [boost] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 22 Sep '22

22 Sep '22

On Wed, Sep 21, 2022 at 12:32 PM Peter Dimov <pdimov(a)gmail.com> wrote: > > That's not very user friendly; maybe the user _wants_ the warning in his code, > and the above would disable it even if no Boost header that uses > BOOST_FORCEINLINE (and generates a warning) has been included. > Okay, then maybe BOOST_FORCEINLINE shouldn't be defined as __force_inline on compilers where it doesn't actually force inlining. If the compiler is just going to treat it as a suggestion, I don't see the point of boost headers using it and then suppressing the warning. -- Frank

1 0

[signals2][variant] inline warning with MSVC 2022
by Gavin Lambert 21 Sep '22

21 Sep '22

This may not be a new issue, as I'm trying to update a project from Boost 1.68 to 1.80 (big jump!), but in trying to compile I'm being hit with this lengthy warning (and this particular project is building with warnings as errors, so this is problematic): warning C4714: function 'class boost::variant<class boost::shared_ptr<void>,class boost::signals2::detail::foreign_void_shared_ptr> __cdecl boost::detail::variant::visitation_impl<struct boost::mpl::int_<0>,struct boost::detail::variant::visitation_impl_step<struct boost::mpl::l_iter<struct boost::mpl::l_item<struct boost::mpl::long_<3>,class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,struct boost::mpl::l_item<struct boost::mpl::long_<2>,class boost::weak_ptr<void>,struct boost::mpl::l_item<struct boost::mpl::long_<1>,class boost::signals2::detail::foreign_void_weak_ptr,struct boost::mpl::l_end> > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> >,class boost::detail::variant::invoke_visitor<class boost::signals2::detail::lock_weak_ptr_visitor const ,0>,void const *,struct boost::variant<class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,class boost::weak_ptr<void>,class boost::signals2::detail::foreign_void_weak_ptr>::has_fallback_type_>(int,int,class boost::detail::variant::invoke_visitor<class boost::signals2::detail::lock_weak_ptr_visitor const ,0> &,void const *,struct boost::mpl::bool_<0>,struct boost::variant<class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,class boost::weak_ptr<void>,class boost::signals2::detail::foreign_void_weak_ptr>::has_fallback_type_,struct boost::mpl::int_<0> *,struct boost::detail::variant::visitation_impl_step<struct boost::mpl::l_iter<struct boost::mpl::l_item<struct boost::mpl::long_<3>,class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,struct boost::mpl::l_item<struct boost::mpl::long_<2>,class boost::weak_ptr<void>,struct boost::mpl::l_item<struct boost::mpl::long_<1>,class boost::signals2::detail::foreign_void_weak_ptr,struct boost::mpl::l_end> > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> > *)' marked as __forceinline not inlined I'm not sure whether the Real Bug™ is in signals2 or in variant, but I don't think it's in any of my code since it doesn't name any of my types above that I can see. I tried the big stick of setting all of Boost to "external" (and set the external warning level to 0), but sadly this did not suppress the warning. Wrapping it in a #pragma suppression does hide the warning, which makes me sufficiently happy. But perhaps someone might be interested to poke at it?

2 2