- Boost - lists.preview.boost.org

A question for folks here
by David Sankel 16 Jul '24

16 Jul '24

For those who got involved in Boost within the last couple years, how did you hear about boost? What attracted you to it? For those who have been around for a while, what keeps you here? Why do you stay engaged?

16 25

[unordered] New natvis visualizations + accompanying article
by Braden Ganetsky 16 Jul '24

16 Jul '24

Hi everyone, This is my first message on the ML. I've written visualizations in the Visual Studio Natvis framework for the Boost.Unordered containers and iterators. This will improve the user experience for anyone using Visual Studio. The visualizations mirror those of the STL unordered containers as closely as possible, except that end iterators display as "{ end iterator }" instead of the visualization just breaking. Here is the file: https://github.com/boostorg/unordered/blob/develop/extra/boost_unordered.na… I've written an accompanying article about the natvis implementation for the closed-addressing containers. I will be writing a second article about the implementation for the open-addressing containers. This first article contains some tips and tricks for using the natvis framework that I wish I knew before going into this, especially about using "<Intrinsic>" elements. Hopefully it can help someone else. Link to the article: https://blog.ganets.ky/NatvisForUnordered/ Custom gdb pretty-printers will be next up. Thank you to Joaquín for reviewing the code and the article. Thanks all, Braden Ganetsky

2 2

Re: [boost] Boost Digest, Vol 7279, Issue 2
by Stephen Greenfield 15 Jul '24

15 Jul '24

BUMP / RE-SENT -- I think I got lost in a flurry of responses to another subject: Richard – > This usually happens because you're compiling with one standard library > (e.g. libc++, the default on clang) while your boost libraries were > compiled with another (e.g. libstdc++, the default on gcc). That makes sense. Does my MacOS program need to be compiled for GCC (IE GNU C++17 / GNU C++20), and then linked with libstdc++ to be compatible with the default build of Boost, or the opposite: build Boost and link with libc++? I saw that there's a list of toolsets, but in the "getting started with unix variants", included with the 1_85_0 .zip package, there is no listing for toolset=clang or toolset=clang-darwin. Nor is there any mention of clang on: https://www.boost.org/doc/libs/1_85_0/more/getting_started/unix-variants.ht… Stephen

1 0

Re: [boost] Boost Digest, Vol 7279, Issue 2
by Stephen Greenfield 11 Jul '24

11 Jul '24

Richard – > This usually happens because you're compiling with one standard library > (e.g. libc++, the default on clang) while your boost libraries were > compiled with another (e.g. libstdc++, the default on gcc). That makes sense. Does my MacOS program need to be compiled for GCC (IE GNU C++17 / GNU C++20), and then linked with libstdc++ to be compatible with the default build of Boost, or the opposite: build Boost and link with libc++? I saw that there’s a list of toolsets, but in the “getting started with unix variants”, included with the 1_85_0 .zip package, there is no listing for toolset=clang or toolset=clang-darwin. Nor is there any mention of clang on: https://www.boost.org/doc/libs/1_85_0/more/getting_started/unix-variants.ht… Stephen -- ------------------------------ Message: 5 Date: Thu, 11 Jul 2024 09:43:01 +0200 From: Richard Hodges <hodges.r(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Updating from 1_71_0 to 1_85_0: "No member named 'memcpy' in namespace 'std::__1'" Message-ID: <CALvx3haD3uRR4sXjjDq5Hrw4XoTq11HMqQyq2D5taJQzH7ys7A(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" This usually happens because you're compiling with one standard library (e.g. libc++, the default on clang) while your boost libraries were compiled with another (e.g. libstdc++, the default on gcc). R On Thu, 11 Jul 2024 at 02:21, Stephen Greenfield via Boost < boost(a)lists.boost.org> wrote: > Dear Boost gurus, > > Building on MacOS 12.7.3, Xcode 13.4.1, C++ dialect = C++17. Deployment > target is 10.15. This particular project is x86_64 architecture. I?m only > linking libboost_filesystem.a and libboost_iostreams.a (I show my build > boost build steps at the end). > > When updating from Boost 1_71_0 to 1_85_0, I?m suddenly encountering these > kinds of errors: > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: > No member named 'memcpy' in namespace 'std::__1'; did you mean simply > 'memcpy'? > > > /Users/stephen/dev/Boost > Libraries/boost_1_85_0/boost/system/detail/append_int.hpp:23:5: No member > named 'snprintf' in namespace 'boost::system::detail'; did you mean simply > 'snprintf'? > > > > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.cp:22: > > In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.h:61: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:653: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/functional:500: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/function.h:20: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/shared_ptr.h:25: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/unique_ptr.h:15: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: > error: no member named 'memcpy' in namespace 'std::__1'; did you mean > simply 'memcpy'? > > _VSTD::memcpy(&__r, __p, sizeof(__r)); > > ^~~~~~~ > > In file included from <built-in>:1: > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Screenwriter_Prefix.pch:505: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/MacTypes.h:44: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/stdbool.h:22: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:858:15: > note: expanded from macro '_VSTD' > > #define _VSTD std::_LIBCPP_ABI_NAMESPACE > > ^ > > In file included from > /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.cp:22: > > In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter > Sources/Text Engine/CThingEdit.h:61: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:652: > > /Users/stephen/dev/Boost > Libraries/boost_1_85_0/boost/compatibility/cpp_c_headers/cstring:22:11: > note: 'memcpy' declared here > > using ::memcpy; > > ^ > ?this is for all sorts of symbols. ALSO: > > > > > Showing All Errors Only > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/filesystem:2635:5: > Use of undeclared identifier '_LIBCPP_UNREACHABLE' > > > When including: > > #include <fstream> > > > The libraries were build using: > > ./bootstrap.sh cxxflags="-arch x86_64 -arch arm64" cflags="-arch x86_64 > -arch arm64" linkflags="-arch x86_64 -arch arm64" > > ./b2 toolset=clang-darwin target-os=darwin architecture=arm abi=aapcs > cxxflags="-arch arm64" cflags="-arch arm64" linkflags="-arch arm64" -a > > mkdir -p arm64 && cp stage/lib/*.* arm64 > > ./b2 toolset=clang-darwin target-os=darwin architecture=x86 > cxxflags="-arch x86_64" cflags="-arch x86_64" linkflags="-arch x86_64" > abi=sysv binary-format=mach-o -a > > mkdir x86_64 && cp stage/lib/*.* x86_64 > > The intention was for me to eventually make UNIVERSAL dylibs using lipo ? > but for now, I just want to get my build back to functioning with Boost > 1_85_0. > > NOTE that I?m continuing to use Boost?s Filesystem ? even though I THINK > Xcode?s C++20 might now support std::filesystem. > > I?ve searched all over for the answer ? even consulted ChatGPT ? but > haven?t found a solution. But this seems like something bone-headed I?ve > missed. > > Stephen > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 7279, Issue 2 **************************************

1 0

Updating from 1_71_0 to 1_85_0: "No member named 'memcpy' in namespace 'std::__1'"
by Stephen Greenfield 11 Jul '24

11 Jul '24

Dear Boost gurus, Building on MacOS 12.7.3, Xcode 13.4.1, C++ dialect = C++17. Deployment target is 10.15. This particular project is x86_64 architecture. I’m only linking libboost_filesystem.a and libboost_iostreams.a (I show my build boost build steps at the end). When updating from Boost 1_71_0 to 1_85_0, I’m suddenly encountering these kinds of errors: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: No member named 'memcpy' in namespace 'std::__1'; did you mean simply 'memcpy'? /Users/stephen/dev/Boost Libraries/boost_1_85_0/boost/system/detail/append_int.hpp:23:5: No member named 'snprintf' in namespace 'boost::system::detail'; did you mean simply 'snprintf'? In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.cp:22: In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.h:61: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:653: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/functional:500: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/function.h:20: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/shared_ptr.h:25: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__memory/unique_ptr.h:15: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__functional/hash.h:40:5: error: no member named 'memcpy' in namespace 'std::__1'; did you mean simply 'memcpy'? _VSTD::memcpy(&__r, __p, sizeof(__r)); ^~~~~~~ In file included from <built-in>:1: In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Screenwriter_Prefix.pch:505: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/MacTypes.h:44: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/stdbool.h:22: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:858:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_ABI_NAMESPACE ^ In file included from /Users/stephen/dev/Screenwriter/ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.cp:22: In file included from ../ScreenWriterX/ScreenWriterX/Screenwriter Sources/Text Engine/CThingEdit.h:61: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/string:522: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/algorithm:652: /Users/stephen/dev/Boost Libraries/boost_1_85_0/boost/compatibility/cpp_c_headers/cstring:22:11: note: 'memcpy' declared here using ::memcpy; ^ …this is for all sorts of symbols. ALSO: Showing All Errors Only /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/filesystem:2635:5: Use of undeclared identifier '_LIBCPP_UNREACHABLE' When including: #include <fstream> The libraries were build using: ./bootstrap.sh cxxflags="-arch x86_64 -arch arm64" cflags="-arch x86_64 -arch arm64" linkflags="-arch x86_64 -arch arm64" ./b2 toolset=clang-darwin target-os=darwin architecture=arm abi=aapcs cxxflags="-arch arm64" cflags="-arch arm64" linkflags="-arch arm64" -a mkdir -p arm64 && cp stage/lib/*.* arm64 ./b2 toolset=clang-darwin target-os=darwin architecture=x86 cxxflags="-arch x86_64" cflags="-arch x86_64" linkflags="-arch x86_64" abi=sysv binary-format=mach-o -a mkdir x86_64 && cp stage/lib/*.* x86_64 The intention was for me to eventually make UNIVERSAL dylibs using lipo – but for now, I just want to get my build back to functioning with Boost 1_85_0. NOTE that I’m continuing to use Boost’s Filesystem – even though I THINK Xcode’s C++20 might now support std::filesystem. I’ve searched all over for the answer – even consulted ChatGPT – but haven’t found a solution. But this seems like something bone-headed I’ve missed. Stephen

4 3

Re: [boost] A question for folks here
by me＠kennethreitz.org 11 Jul '24

11 Jul '24

Hi all, My name is Kenneth Reitz, and I got involved with Boost when Vinnie Falco asked me to join the C++ Alliance to work on the new boost website. You might recognize my name from the Python community, where I’m known for making Requests, Pipenv, and other tools. It’s nice to meet everyone! — Kenneth Reitz > 1. A question for folks here (David Sankel) > 2. Re: A secure string library? (Andrey Semashev) > 3. Re: A secure string library? (Andrey Semashev) > 4. Re: A question for folks here (Richard Hodges) > 5. Re: A secure string library? (Daniela Engert) > 6. Re: A secure string library? (Andrey Semashev) > 7. Re: A secure string library? (Christian Mazakas) > 8. Re: A question for folks here (Matt Borland) > 9. Re: A question for folks here (Christopher Kormanyos) > 10. Re: A question for folks here (Louis Tatta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 10 Jul 2024 10:47:50 -0400 > From: David Sankel <camior(a)gmail.com> > To: Boost <boost(a)lists.boost.org> > Subject: [boost] A question for folks here > Message-ID: > <CAFYdOO+m95fKjxnKY3SY_eHC-X=PLs12BteaONG+QpS6fTCxcQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > For those who got involved in Boost within the last couple years, how did > you hear about boost? What attracted you to it? > > For those who have been around for a while, what keeps you here? Why do you > stay engaged? > > > ------------------------------ > > Message: 2 > Date: Wed, 10 Jul 2024 18:26:20 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <6265cabd-c0b9-405e-98f4-8a47683e5472(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 14:59, Peter Dimov via Boost wrote: >> Ruben Perez wrote: >>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>> simple - I wonder if this is just enough or there are any corner cases where this >>> doesn't work: >>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >> >> That's an interesting approach. I can't offhand think of a reason why it wouldn't >> work. > > The compiler might convert OPENSSL_cleanse to something like this: > > void OPENSSL_cleanse(void *ptr, size_t len) > { > memset_t func = memset_func; > if (func != memset) > func(ptr, 0, len); > else > memset(ptr, 0, len); > } > > The purpose here is that, if memset_func is actually memset most of the > time, it can further optimize the call to memset, including to > completely remove it, depending on the call context. The > (well-predictable) branch is typically cheaper than an indirect call. I > think I've seen compilers do something along those lines as a result of > call devirtualization, especially with IPO and LTCG. > > I'm not saying that's what actually happens in OpenSSL, just that > something like this is possible. I think, a dummy asm statement is more > reliable and more efficient. > > void secure_cleanse(void *ptr, size_t len) > { > memset(ptr, 0, len); // a normal memset, optimizations are welcome > __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); > } > > You can even make that function inline and it'll work, and in an optimal > way, too. > > > > ------------------------------ > > Message: 3 > Date: Wed, 10 Jul 2024 18:37:00 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <57326885-13ab-4a73-ac5a-5aa6357e799c(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 18:26, Andrey Semashev wrote: >> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>> Ruben Perez wrote: >>>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>>> simple - I wonder if this is just enough or there are any corner cases where this >>>> doesn't work: >>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>> >>> That's an interesting approach. I can't offhand think of a reason why it wouldn't >>> work. >> >> The compiler might convert OPENSSL_cleanse to something like this: >> >> void OPENSSL_cleanse(void *ptr, size_t len) >> { >> memset_t func = memset_func; >> if (func != memset) >> func(ptr, 0, len); >> else >> memset(ptr, 0, len); >> } >> >> The purpose here is that, if memset_func is actually memset most of the >> time, it can further optimize the call to memset, including to >> completely remove it, depending on the call context. The >> (well-predictable) branch is typically cheaper than an indirect call. I >> think I've seen compilers do something along those lines as a result of >> call devirtualization, especially with IPO and LTCG. >> >> I'm not saying that's what actually happens in OpenSSL, just that >> something like this is possible. I think, a dummy asm statement is more >> reliable and more efficient. >> >> void secure_cleanse(void *ptr, size_t len) >> { >> memset(ptr, 0, len); // a normal memset, optimizations are welcome >> __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >> } >> >> You can even make that function inline and it'll work, and in an optimal >> way, too. > > And for compilers that don't support __asm__, I think you could replace > it with: > > std::atomic_signal_fence(std::memory_order::acq_rel); > > > > ------------------------------ > > Message: 4 > Date: Wed, 10 Jul 2024 18:01:03 +0200 > From: Richard Hodges <hodges.r(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A question for folks here > Message-ID: > <CALvx3hYSO6svxz_aEw_LoaraweTguqW+jJScTyfymZAveOrXZg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 10 Jul 2024 at 16:48, David Sankel via Boost <boost(a)lists.boost.org> > wrote: > >> For those who got involved in Boost within the last couple years, how did >> you hear about boost? What attracted you to it? >> > > I've been using boost as an essential force multiplier of C++ since version > 1.35 when Asio appeared, courtesy of Chris Kohlhoff. > > More recently in 2017, I needed an asynchronous websocket library for C++ > and lo-and-behold, boost had one, courtesy of Vinnie Falco. > > >> >> For those who have been around for a while, what keeps you here? Why do you >> stay engaged? >> > > After finishing a contract in which I used Boost.Beast et.al. in production > code, I took up an offer by the C++ Alliance to become a maintainer of it. > A bit of a "Victor Kiam" moment, if you will. > > While working for the C++ Alliance I was also involved in the design and > first cut of Boost.Json and had some input into Boost.Url, another two very > keenly needed libraries sponsored by the C++ Alliance. > I am no longer working for the C++ Alliance, but maintain a warm > relationship with the organisation. > > I am currently using Boost.Cobalt in a financial trading software suite. > > I stay engaged because: > - I don't want to have to switch languages - C++ is perfectly fine for me. > - Boost polyfills all the essential functionality that the children running > WG21 continue to refuse to provide. > - It's convenient to have one library that provides (almost) every tool I > need. > > My very great thanks to the original authors and contributors, and more > recently to the C++ Alliance, which as far as I can see is the only major > sponsor of Boost. > Without this organisation's involvement, I believe the libraries would have > been allowed to fall into disrepair a long time ago. > > I don't think I have met more than one team in the financial industry which > uses C++ but which does not use Boost. > > On a separate note, I was deeply disappointed by your recent public > outbursts, David. > > Sincerely, > > Richard Hodges > A C++phile > ex maintainer of Boost.Beast > contributor to Boost.Json, Boost.Url > Advisor to Boost.MySQL, Boost.Cobalt > > >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > ------------------------------ > > Message: 5 > Date: Wed, 10 Jul 2024 18:13:41 +0200 > From: Daniela Engert <dani(a)ngrt.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <98140e71-ef1e-431a-a089-e24f56e390bd(a)ngrt.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 10.07.2024 um 17:37 schrieb Andrey Semashev via Boost: >> On 7/10/24 18:26, Andrey Semashev wrote: >>> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>>> Ruben Perez wrote: >>>>> There is OPENSSL_Cleanse, which does a similar job. I found it surprisingly >>>>> simple - I wonder if this is just enough or there are any corner cases where this >>>>> doesn't work: >>>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>>> That's an interesting approach. I can't offhand think of a reason why it wouldn't >>>> work. >>> The compiler might convert OPENSSL_cleanse to something like this: >>> >>> void OPENSSL_cleanse(void *ptr, size_t len) >>> { >>> memset_t func = memset_func; >>> if (func != memset) >>> func(ptr, 0, len); >>> else >>> memset(ptr, 0, len); >>> } >>> >>> The purpose here is that, if memset_func is actually memset most of the >>> time, it can further optimize the call to memset, including to >>> completely remove it, depending on the call context. The >>> (well-predictable) branch is typically cheaper than an indirect call. I >>> think I've seen compilers do something along those lines as a result of >>> call devirtualization, especially with IPO and LTCG. >>> >>> I'm not saying that's what actually happens in OpenSSL, just that >>> something like this is possible. I think, a dummy asm statement is more >>> reliable and more efficient. >>> >>> void secure_cleanse(void *ptr, size_t len) >>> { >>> memset(ptr, 0, len); // a normal memset, optimizations are welcome >>> __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >>> } >>> >>> You can even make that function inline and it'll work, and in an optimal >>> way, too. >> And for compilers that don't support __asm__, I think you could replace >> it with: >> >> std::atomic_signal_fence(std::memory_order::acq_rel); >> > I think Peter is actually right in his assessment: > > While 'memset_func' is TU-local, it is also 'volatile'. This implies > every look at it might reveal a different content. Therefore the > necessity for non-constness and dynamic initialization. We humans see > that the variable can't change its value other than in the > initialization. The compiler can't reason that because said properties > are the only ones known during the compilation of 'OPENSSL_cleanse()'. > It can't perform unbounded look-ahead until the end of the TU like we do. > > Dani > > -- > PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5 > > ------------------------------ > > Message: 6 > Date: Wed, 10 Jul 2024 19:24:48 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: <905dd5f7-5d29-48ab-87aa-6aa0a23e60c6(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 7/10/24 19:13, Daniela Engert via Boost wrote: >> Am 10.07.2024 um 17:37 schrieb Andrey Semashev via Boost: >>> On 7/10/24 18:26, Andrey Semashev wrote: >>>> On 7/10/24 14:59, Peter Dimov via Boost wrote: >>>>> Ruben Perez wrote: >>>>>> There is OPENSSL_Cleanse, which does a similar job. I found it >>>>>> surprisingly >>>>>> simple - I wonder if this is just enough or there are any corner >>>>>> cases where this >>>>>> doesn't work: >>>>>> https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f8… >>>>> That's an interesting approach. I can't offhand think of a reason >>>>> why it wouldn't >>>>> work. >>>> The compiler might convert OPENSSL_cleanse to something like this: >>>> >>>> ?? void OPENSSL_cleanse(void *ptr, size_t len) >>>> ?? { >>>> ???? memset_t func = memset_func; >>>> ???? if (func != memset) >>>> ?????? func(ptr, 0, len); >>>> ???? else >>>> ?????? memset(ptr, 0, len); >>>> ?? } >>>> >>>> The purpose here is that, if memset_func is actually memset most of the >>>> time, it can further optimize the call to memset, including to >>>> completely remove it, depending on the call context. The >>>> (well-predictable) branch is typically cheaper than an indirect call. I >>>> think I've seen compilers do something along those lines as a result of >>>> call devirtualization, especially with IPO and LTCG. >>>> >>>> I'm not saying that's what actually happens in OpenSSL, just that >>>> something like this is possible. I think, a dummy asm statement is more >>>> reliable and more efficient. >>>> >>>> ?? void secure_cleanse(void *ptr, size_t len) >>>> ?? { >>>> ???? memset(ptr, 0, len); // a normal memset, optimizations are welcome >>>> ???? __asm__ __volatile__ ("" : : "r" (ptr), "r" (len) : "memory"); >>>> ?? } >>>> >>>> You can even make that function inline and it'll work, and in an optimal >>>> way, too. >>> And for compilers that don't support __asm__, I think you could replace >>> it with: >>> >>> ?? std::atomic_signal_fence(std::memory_order::acq_rel); >>> >> I think Peter is actually right in his assessment: >> >> While 'memset_func' is TU-local, it is also 'volatile'. This implies >> every look at it might reveal a different content. Therefore the >> necessity for non-constness and dynamic initialization. We humans see >> that the variable can't change its value other than in the >> initialization. The compiler can't reason that because said properties >> are the only ones known during the compilation of 'OPENSSL_cleanse()'. >> It can't perform unbounded look-ahead until the end of the TU like we do. > > With volatile, the compiler is not allowed to optimize away or reorder > loads and stores of the variable. There's no restriction on what the > compiler is allowed to do with the loaded value. > > > > ------------------------------ > > Message: 7 > Date: Wed, 10 Jul 2024 10:10:43 -0700 > From: Christian Mazakas <christian.mazakas(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A secure string library? > Message-ID: > <CAHf7xWueD5=ekMC178pikzH2iuhAtyzC6v5UgPBSoj0NMy3y9Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > >> Andrey Semashev via Boost: >> With volatile, the compiler is not allowed to optimize away or reorder >> loads and stores of the variable. There's no restriction on what the >> compiler is allowed to do with the loaded value. > > It could insert a branch against `memset` but that seems really only like a > theoretical > optimization. > > This is an example where the volatile preserves the secure_erase() call: > https://godbolt.org/z/854jfarb9 > > Kind of neat trying to get the compiler to elide this stuff. You were > right, Andrey, you really need > LTO and LTCG and the like to get this kind of behavior. Super neat stuff. > > Idk, seems like whatever OpenSSL is doing is Sound Enough in practice. > > I'd be curious to know if it's actually sound for a compiler to make that > kind of optimization or at least > what are the limits on how far a compiler can actually go to ensure > soundness. If you know those limits, > you can probably make this pattern work reliably. > > - Christian > > > ------------------------------ > > Message: 8 > Date: Wed, 10 Jul 2024 17:57:57 +0000 > From: Matt Borland <matt(a)mattborland.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] A question for folks here > Message-ID: > <LQ-gmVceAUPyCRzsmP5gN1Z4NJiwrRtJ-yJY5Q6Ne-3SnJ_omC84hltKP9AbS3x-TVlz35Amln3jW0CBdG0nnzAioM53fxXobq0GO3zYb2E=(a)mattborland.com> > > Content-Type: text/plain; charset="utf-8" > > >> For those who got involved in Boost within the last couple years, how did >> you hear about boost? > > I heard about it from a university professor as a freshman undergraduate student in 2011. Since C++11 was just coming about, and the speed of updating toolchains in academia is slow so we were stuck in the C++03 days on old RHEL systems. > >> What attracted you to it? > > I was studying aeronautical engineering so having pre-made libraries like Boost.Math, Boost.Multiprecision, and ODEint were useful to me. I could focus on the problem at hand rather than having to roll my own special functions, solvers, big numbers, constants, etc. > >> For those who have been around for a while, what keeps you here? Why do you stay engaged? > > I started to get involved with development during the COVID lockdowns because like many people I found myself with quite a bit of extra free time. What hooked me was learning from and working with extremely competent programmers and mathematicians like John Maddock, Chris Kormanyos, and Nick Thompson. I was hired by the C++ Alliance at the beginning of 2023 and they have sponsored my development since. This allows me to work on new (https://github.com/cppalliance/decimal) and existing libraries (charconv, math, multiprecision, random, etc) in a way that I was never able to on a volunteer basis with a full time job. The community is large, knowledgeable, and helpful so I continue to enjoy working on Boost. > > > I think it would be beneficial to the developer community for the Boost Foundation board members to also answer these questions. Frankly some even require introductions with their answers. There are members of the board like Peter, Glen, and Zach that are Titans of Boost, and those like Kristen who I had not heard of until her post about wanting to cut ties with the C++ Alliance. Having unknown members of the Boost Foundation runs counter to their mission statement whereby the board intends to achieve its mission by "fostering community engagement, [and] nurturing leaders..."[1]. > > Matt > > [1] https://sites.google.com/boost.org/boost-foundation/home >

2 1

A secure string library?
by Ruben Perez 10 Jul '24

10 Jul '24

Hi all, Boost.MySQL and Boost.Redis need to hold sensitive information, like passwords, to work. Using std::string may be sufficient for many use cases, but it's not the best security practice. std::string doesn't wipe its memory on cleanup, resulting in the password remaining in memory for an indeterminate amount of time. Other languages like C# implement a SecureString class that wipes memory on destruction. Crypto++ implements a similar concept, but it's a big dependency I'm not willing to take. I'd like to know whether everyone else's opinion on this: * Have you faced this issue before? * Do you think this is something we (as Boost authors) should care about, or am I thinking too much? * Do you think a library implementing secure string/array/buffer classes would be a valuable addition to Boost? Thanks, Ruben.

11 22

[boost 1.85.0 MSVC142-64 ]type_name.hpp(354,2): error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined
by Bhuyan, Jyotideep 10 Jul '24

10 Jul '24

Hello, I am updating my code from boost version 1.78 to boost 1.85. and facing build issues "error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined" Below is the error that I am facing that needs your help. I could not find any code or direct header file inclusion in my code related to the below error. C:\<my boost>\boost_1_85\boost\boost\core\type_name.hpp(354,2): error C2766: explicit specialization; 'boost::core::detail::tn_holder<unsigned short>' has already been defined. C:\<my boost>\boost_1_85\boost\boost\core\type_name.hpp(273): message : see previous definition of 'tn_holder<unsigned short> Please note that after upgrading to boost 1.85, the compiler was not able to find "#include <boost/function/detail/prologue.hpp>", I checked this file is not present in the new version. Hence, I have commented header file inclusion in my code. I am building the code for MSVC142 (C++14) for 64-bit Windows 10 architecture. Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

3 2

failure to produce PDF documentation
by Robert Ramey 10 Jul '24

10 Jul '24

For many years, I've been using the xslt based system for converting boostbook xml into html an pdf files. Once I got it set up, I've never had a problem. But now, it is failing with some error messages provoked by the contents of some xml files which are part of boost book. A casual review of the correspondng github repository shows the that the some of these files have been "maintained" recently ... some as recently as 3 days ago. Could someone (probably the maintainer) look into this. I noticed that when I try to appy this to the safe numerics library. The following should reproduce the problem: cd /Users/robertramey/WorkingProjects/modular-boost/libs/safe_numerics/doc/boostbook $ls *.sh makeepub.sh makehtml.sh makepdf.sh makeproposal.sh $echo $PATH /Volumes/public/fop-2.1:.:/Volumes/public/menu_bash:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin $./makepdf.sh [Fatal Error] docbook.xsl:6:3: The element type "hr" must be terminated by the matching end-tag "</hr>". http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; Line #6; Column #3; org.xml.sax.SAXParseException; systemId: http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>". Jul 09, 2024 2:58:38 PM org.apache.fop.cli.Main startFOP SEVERE: Exception ... Thanks to whoever looks into this. Robert Ramey

2 3

Boost 1.85, Windows, VS2022 17.10.3, build does not create any libs on building boost
by Dennis Luehring 09 Jul '24

09 Jul '24

my system Windows 10 x64, VS2022 10.7.3 Download: https://archives.boost.io/release/1.85.0/source/boost_1_85_0.7z unpack zip to boost_1_85_0 in console: cd boost_1_85_0 bootstrap.bat b2 -j%NUMBER_OF_PROCESSORS% toolset=msvc-14.3 address-model=64 --stagedir=.\lib64-msvc-14.3 --build-dir=.\__build --build-type=complete threading=multi architecture=x86 stage --with-date_time --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --with-serialization --with-locale --with-log result - lib64-msvc-14.3\lib\cmake gets created - but no libs that is my default build style up to 1.84 the output of bootstrap.bat https://pastebin.com/DQUVe3QR the output of b2 run https://pastebin.com/sJqGLDE7 it seems that all libs are ignored someway any idea?

2 2

[release] Master branch closes for the 1.86.0 beta release on WEDNESDAY
by Marshall Clow 08 Jul '24

08 Jul '24

Calendar is here: https://www.boost.org/development/ — The Release Managers

1 0

New Boost website ready for launch
by Joaquin M López Muñoz 06 Jul '24

06 Jul '24

Hi everyone, As most of you know, the new Boost website has been in the works for quite a long time: last week we've fixed the last showstopper issues and are now in a position to launch it publicly and announce to the wider community! See the launch-ready website at: https://boost.io The new website is ready to replace the current one at boost.org any time we want. The old site has served us well for 25 years, and it deserves to be given a retirement permit. OVERVIEW The new website is organized in five top-level sections: * News: an aggregator of internal announcements, blog articles, videos, etc. related to the Boost project. * Learn: comprehensive and completely rewritten tutorials and reference material for users, contributors and review participants. Check this out: there's a ton of new stuff here. * Community: links to the various discussion venues for Boost (mailing lists, Slack groups, X, etc.). * Libraries: revamped directory of Boost libraries, with integrated access to version-specific docs, repos, and more. * Releases: access to release notes, download binaries and source code for all Boost versions from 1.16.1 up to the current one. Users can navigate the website anonymously or log in to be able to contribute to the News section, receive notifications etc. The site uses responsive design to work on wide screens as well as your mobile device. Also, check the light and dark modes at the top-right corner :-) FEEDBACK AND FUTURE The evolution of the website does not stop here. We have quite a backlog of issues and new features registered at: https://github.com/boostorg/website-v2/issues https://github.com/boostorg/website-v2-docs/issues But we're also expecting your feedback! Please let us know what you think of the website and ways to improve it. I will personally make sure that all comments and suggestions are properly addressed. Ways to contribute: * Through the mailing list or the #boost-website group at cpplang.slack.com. * Filing issues directly at https://github.com/boostorg/website-v2 (website proper) and https://github.com/boostorg/website-v2 (learning material). * Learning material has an "Edit this page" link from where you can fork any documentation section and propose changes through a pull request. * Reach out to me anyway you'd like. ACKNOWLEDGEMENTS There are just too many individuals to list here who had contributed to the new website --my thanks to all of them. Let me mention some of the people I have worked with the most in the last two months, when I took over the PM role for this launch effort. * The people at REVSYS (Frank Wiles, Lacey Henschel) and Spencer Strickland built the Django-based backend and most of the frontend. Kenneth Reitz and Julio C. Estrada have been working tirelessly to close functionality gaps and fix remaining issues up to launch status. * Peter Turcan is the main author of the new learning material featured in the website. Again, check it out and help us spot glitches or propose new topics to work on. * Sam Darwin, who's already the Atlas upon whom the current Boost infrastructure rests, has double down on his responsibilites to set up and take care of this new backend. * René Rivera wrote many of the scripts that power the old website and has assisted us in the migration process with his expertise and unique insights into the particulars of Boost internal procedures. * Many people have filed issues during development, but the record holder is Andrey Semashev (39 tickets and counting). His suggestions and active involvement in the fixing process have made the website a better place. Best, Joaquín M López Muñoz

5 8

[release] The 1.86.0 release will close for major changes WEDNESDAY
by Marshall Clow 02 Jul '24

02 Jul '24

Calendar here: https://www.boost.org/development/ Next deadline: The master branch will close for the beta next Wednesday. — The release managers

3 2

1.86 release
by Andrey Semashev 01 Jul '24

01 Jul '24

Hi, Are we behind the 1.86 release schedule?

3 3

In Response to Mr. Falco's June 2024 Letter
by Kristen Shaker 01 Jul '24

01 Jul '24

Hello Boost Community, My name is Kristen. Admittedly, I am not the most active participant on the boost mailing list. However, I do serve on the Boost Foundation Board of Directors as Board Chair. It is lovely to e-meet you; Hopefully I'll have the opportunity to get to know you better during the course of my tenure. Recently, we became aware of a letter that was circulated to the Boost developer community. The Boost Foundation Board of Directors have penned the following note in response to that letter. _____________________________________ Dear Boost Community Members, Recently, Mr. Falco distributed a letter indicating intent to a) rescind his offer of hosting a new boost.org website, b) retract his agreement to retire the @BoostLibraries account on X in favor of the established @Boost_Libraries, c) create a new set of Boost mailing lists on boost.io, and d) attempt to purchase the boost.org domain name from Beman Dawes’s estate. While we are surprised and saddened by this turn of events, we agree with Mr. Falco that cutting ties between the C++ Alliance and the Boost Foundation is in everyone’s best interests. That being said, we want to acknowledge Mr. Falco and his employees’ tremendous contributions toward a modernized Boost website and significant investment in maintaining and extending the Boost Libraries. On March 28th, 2024, the Foundation voted to point the boost.org domain name at Mr. Falco’s new site. Given that we had every intention to move forward we were shocked to hear that Mr Falco felt we were “holding [his] work hostage.” The Boost Foundation was entirely unaware of Mr. Falco’s attempts to purchase the boost.org domain name. We were not consulted until it became clear to Mr. Falco that to proceed with the transaction, he would need the login credentials for the domain name provider. At that point, Mr. Falco did contact a board member requesting the credentials, which were not provided to him. We were hesitant to discuss these events publicly, but since Mr. Falco has openly described his attempts to purchase the boost.org domain name, this public response seems appropriate. The fact that he took these steps without coordinating with—or even notifying— the Boost Foundation, has shaken our confidence in the Alliance and Mr. Falco. While we very much appreciate Mr. Falco's financial investment, nonprofits like Boost are not—nor should they be—beholden to their largest financial contributors. We are committed to continuing to foster a collaborative environment where C++ developers can contribute great ideas to the open source community. Boost's consensus-based process is not always the fastest way to the best result, but it is consistent with that commitment. Ideally, Mr. Falco would be interested in contributing financially to a worthy cause without assuming control over the Libraries, but his letter indicates otherwise. Therefore, we agree with Mr. Falco’s assessment that there is no viable path forward for further coordination between The C++ Alliance and The Boost Foundation. We do, however, wish Mr. Falco and the Alliance all the best in their continued efforts to improve the C++ ecosystem. Sincerely, The Boost Foundation Board of Directors

13 16

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

3 3

Test
by Andrey Semashev 26 Jun '24

26 Jun '24

Hello, testing.

3 3

test77
by sam＠cppalliance.org 26 Jun '24

26 Jun '24

qq

1 1

test6
by Sam Darwin 26 Jun '24

26 Jun '24

test6

2 1

FYI: recent VS2022 17.10.x gives "Boost toolset is unknown (compiler MSVC 19.40.33808.0)" warning - due to Microsoft changing of the toolset version
by Dennis Luehring 21 Jun '24

21 Jun '24

...using Boost only CMake configure The MSVC toolset will increment its minor version number from|19.39|(VS 2022 v17.9) to|19.40|(VS 2022 v17.10). https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14… is still useable - did not check if building boost is a problem

2 3

[boost.QVM] can you explain quaternions in the docs?
by Andrzej Krzemienski 19 Jun '24

19 Jun '24

Hi Everyone, I landed on this library docs when trying to learn what quarterions are for. Although the library has a vast documentation it doesn't explain what quaternions are and why they are used. When I was taught algebra for the purpose of computer graphics, vectors and matrices were on the table, but no quaternions. The examples show that I need to create a quaternion only to turn it into a rotation matrix. I am pretty sure there has to be more to it. Could I request an introduction section in the docs that would explain what quaternions are and why one would want to use them? The corresponding GitHub issue: https://github.com/boostorg/qvm/issues/51 Regards, &rzej;

5 5

CppCast: Boost, The Beman Project and Beyond
by Niall Douglas 16 Jun '24

16 Jun '24

Given that some on here were expressing surprise at recent goings on, I thought in case nobody had seen it yet listening to this might be useful: https://cppcast.com/boost-the_beman_project_and_beyond/ Our own Zach Laine explains some of what's been going on behind the scenes. Niall

2 1

[Newbie] Problem receiving data with asio::serial_port
by Stefano Mora 14 Jun '24

14 Jun '24

Hi all, I’m writing a Qt application running on both Windows and MacOs platforms. The application is based on CMake project that includes boost-asio package 1.84.0 by vcpkg packager. The application must communicate with a board by USB cable = virtual serial port. I’m handling the communication with a small wrap around the asio::serial_port object, found in sample https://github.com/fedetft/serial-port/tree/master/2_with_timeout The problem is on MacOS platform; Windows version works correctly. The problem is that after some data exchanges (they are correct) the program does not receive a reply (with the TIMEOUT exception) and, after that, it receives only system_error = 89. This is a chunk of my log: ... ( I send a command and I receive the reply) [ReceiveLog] start [TP] start SendCommand 'log export' [WriteCommand] Byte[] Write - cmd: 'log export' [WaitForResponse] ms 1000 RX [34] : ' log export -> XModem receive file' [SendCommand] response: ' log export -> XModem receive file' [ReceiveLog] response1: 'XModem receive file' matching: 'XModem receive file' [ReceiveLog] ok -> XMODEM (now I send a byte to start the data from the board - 3 attempts) > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [WaitForXModemResponse] TIMEOUT TO diff: 4 > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error > Write BEGIN DATA RECEIVE .. [WaitForXModemResponse] ms 4000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error [TP][ReceiveLog] start XMODEM: 0 (now I sent an ACK, just to try ...) [WaitForXModemResponse] ms 1000 [ToSerial][readCompleted] error system:89 [ToSerial][readCompleted] byteTransf 0 [WaitForXModemResponse] Boost System_error [dlThread] ReceiveLog ret: 0 The read function is simply set the timeout and read 133 bytes: ... _serialPort.setTimeout( boost::posix_time::millisec(timeout)); char data[XMODEM_PACKET_LENGTH]; try { _serialPort.read( data, XMODEM_PACKET_LENGTH); ... } catch(timeout_exception){ ... } catch(boost::system::system_error){ ...} Please what error 89 means (in MACos context)? Any idea on how to exit from this situation? Thanks! Regards

2 8

CMake and Boost
by Robert Ramey 12 Jun '24

12 Jun '24

I'm trying to figure out how to switch to CMake to build and test my libraries. I have some experience with this as I've made such files on sort of an experimental/prototype basis. However it's been some time since I messed with this so a forgot a lot. Now I'm getting serious so I have some questions. I've looked over the official CMake documentation. It seems complete but some stuff is not well explained. I've spent some time studying https://github.com/boostorg/cmake at I'm beginning to see what I have to do. Never-the-less, I still have a few questions: 1) The first lines show mkdir __build cd __build cmake .. cmake --build . Does this presume that one starts from the library directory? Does this syntax work for out of source tree builds? That is, would the following work? mkdir /temp/__build cd /temp/__build cmake .. cmake --build . (very confusing usage of leading __) ahhhh - I see a problem. I'm thinking of starting from within the directory of a particular library. I'm presuming "modular boost". Is this supported? 2) BOOST_INCLUDE_LIBRARY I would like my CMakeLists.txt file to explicitly list the direct antecedent libraries (dependencies - bad word usage). So I'd expect to see something like add_directory(../filesystem) add_directory(../regex) ... So I could just cd to .../libs/serialization cmake --build and have it build the antecedent if and only if required. 3) CMAKE_INSTALL_INCLUDEDIR I would prefer not to "install" (copy) the include files but just use the ones from their original locations. 4) BUILD_TESTING I would prefer to have my library source to look like: ... libs/serialization CMakeLists.txt // includes add_directory for subdirectorys build, test, example, profile and ... // includes add_directory for antecedent libraries like add_directory(../libs/filesystem) include // directory with include files for users of serialization library build(or src) // source files for library build CMakeLists.txt // to build library test CMakeLists.txt example CMakeLists.txt profile CMakeLists.txt Maybe the add_directory would be conditioned on a CMAKE variable. So if I invoke CMake --build test_polymorphic_binary_archive It would recursively (re)build everything necessary and nothing not necessary If I didn't specify a list of targets, it would recursively (re)build everything that needs (re)building. This seems totally reasonable and natural to me - it work like make - but better. It would dovetail with efforts to "modularize" boost. Users would only have to download libraries they actually use - if that's what they want. I realized I've glossed over a couple of details, in particular recursive inclusion of header files and likely some other stuff. I've also experimented with CMake enough to have a feeling that what I want to do is not possible. And this is the short version of what I'd like to do. Any thoughts on this?

4 5

[container] Draft development plan for Boost.Container
by Ion Gaztañaga 11 Jun '24

11 Jun '24

Hi to all, Boost.Container was accepted in 2011 when container classes were spun off from Boost.Interprocess to form a new library. At that time it offered new features like emulated move semantics for "classic" STL-like containers and some new classes like flat_map and stable_vector. During these years more containers/main features were added: - The scoped allocator Model was added in Boost 1.50 (2012) - static_vector was added in Boost 1.54 (2013) - small_vector was added in Boost 1.58 (2015) - Polymorphic Memory Resources were added in Boost 1.60 (2015) - devector was added in Boost 1.75 (2020) Lately I've been collecting some ideas about how to improve the library and keep it interesting/useful both for other Boost libraries and Boost users. I've somewhat formalized a bit some of those ideas and I'd like to share them here in order to obtain feedback from the developers. Here's the document: https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8… Note that this document does not outline a schedule for all those ideas, it's an initial description of possible developments that should be evaluated/prioritized, as developing a substantial subset of the proposals would be a huge task. Thanks in advance for your attention and comments. Best, Ion

8 23