- Boost-users - lists.boost.org

Re: [Boost-users] JSON Schema support in C++ with boost::json?
by Alex 08 Apr '25

08 Apr '25

> 3. Generate validation code that can emit informative messages about failed validation. Valijson ( https://github.com/tristanpenman/valijson ) apparently supports Boost.Json for schema validation, although I haven't used it personally. Most C++ implementations of schema validation don't support a lot of the newer JSON schema versions. You could take a look at some of the C++ tools at https://json-schema.org/tools?query=&sortBy=name&sortOrder=ascending&groupB… Regards, Alex Simpson

1 0

JSON Schema support in C++ with boost::json?
by Nigel Stewart 07 Apr '25

07 Apr '25

Hello all, There are a couple of things I'd like to do with JSON Schema in C++, which are similar to protobuf, but JSON-centric. 1. Generate a C++17 struct from a JSON Schema, names, types, optionality, nested data, arrays. 2. Generate C++17 code for serialising to/from the natve C++17 struct. 3. Generate validation code that can emit informative messages about failed validation. Seems to me this problem isn't specific to our application stack. Essentially we want to pass state between NodeJS and core C++ modules and have those interfaces evolve over time in a maintainable way. What's out there? - Nigel Stewart

3 3

Passing -D options with b2 to ASIO when compiling with mingw64 ucrt64?
by Joost Kraaijeveld 25 Mar '25

25 Mar '25

Hi, I try to compile Boost with MingW64 with ucrt64. I get warnings saying I should define _WIN32_WINNT with 0x0601 or higher and an error saying I must define USE_W32_SOCKETS. Is it possible to pass these on a command line to b2 or otherwise, without interfering with Boost's source? TIA -- Groeten, Joost

2 1

Re: [Boost-users] Boost-users Digest, Vol 5755, Issue 1
by Label 18 Mar '25

18 Mar '25

Hello, > Date: Mon, 17 Mar 2025 21:02:09 +0100 > From: Joost Kraaijeveld <J.Kraaijeveld(a)Askesis.nl> > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Passing -D options with b2 to ASIO when > compiling with mingw64 ucrt64? > Message-ID: > <dc4a6232934d0d77af53a3054afddbc5b22a8bc1.camel(a)Askesis.nl> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I try to compile Boost with MingW64 with ucrt64. I get warnings saying > I should define _WIN32_WINNT with 0x0601 or higher and an error saying > I must define USE_W32_SOCKETS. > > Is it possible to pass these on a command line to b2 or otherwise, > without interfering with Boost's source? > > TIA > you can append the following definitions to the b2 command line: b2 ... define=_WIN32_WINNT=0x0A00 define=BOOST_USE_WINAPI_VERSION=0x0A00 I do not know whether USE_W32_SOCKETS needs only be defined or wants a special value, you can try define=USE_W32_SOCKETS or define=USE_W32_SOCKETS=1 -- __________________________________ Freundliche Grüße * Best regards * Met vriendelijke groeten * Meilleures salutations * Atentamente * Saludos Holger Gerth EB-Soft GmbH Neckargartacher Strasse 114 74080 Heilbronn Germany Tel: +49 7131-94660 Fax: +49 7131-10990 E-Mail: holger.gerth(a)eb-soft.de Web: https://www.ebsoft.de Amtsgericht-Registergericht-Stuttgart HRB 102882 Geschäftsführerin: Hannelore Sigler

1 0

release] Boost 1.88.0 beta 1 released
by Marshall Clow 15 Mar '25

15 Mar '25

Boost release 1.88.0 beta 1 is now available at: https://archives.boost.io/beta/1.88.0.beta1/source/ The SHA256 checksums are: bc4948bc664fde0c2142badae2679a42124b464dc58019250afe0ef57fd7763e boost_1_88_0_rc1.zip 3c334a9a743b68a35452b0223be8932fb39f26a6938382f9b9e625c4df99602c boost_1_88_0_rc1.tar.gz 9e42c0611500151d795d66a07ef0a21036c02d24678e2e887caf6d97fcbc25ca boost_1_88_0_rc1.tar.bz2 7faf60c4cb12ee90270e41716cf3735a8739016d7346983ce9f5e899e510b26d boost_1_88_0_rc1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_88_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

boost::json question
by Keeling, William 12 Feb '25

12 Feb '25

json::value RCamCfg::GetCfgValue(const std::string& key) { try {return config_.at_pointer(key);} catch(...) { json::value x; return x;} } bool RCamCfg::SetCfgValue(const std::string& key, const json::value& val) { try {config_.set_at_pointer(key, val);} catch(...) {return false;} return {true}; } The first function compiles and runs but the second fails to compile with the following: error: 'class boost::json::value' has no member named 'set_at_pointer'; did you mean 'at_pointer'? config_is defined as "json::value config_;" Any ideas what I am doing wrong? Thanks William Keeling

3 4

Newbie - Using Boost ASIO and Boost Thread from CMake based project
by Russell Haley 11 Feb '25

11 Feb '25

Hello, I am implementing a serial port protocol in a Linux based library. We build boost ourselves (1.86.0) for inclusion in thrift so I am trying to use as much as I can just from the Boost libraries to gain some experience with them. My serial port driver is using the serial_port class from Boost ASIO. It's super cool and working well. To include Boost ASIO in my CMake target, all I have done is this: cmake_minimum_required(VERSION 3.30) set(CMAKE_CXX_STANDARD 20) set(BOOST_ROOT "${PROJECT_SOURCE_DIR}/../dataman_service/boost-install-x86_64-Debug/") find_package(Boost CONFIG) #This is an alternate use? #find_package(Boost NO_MODULE) add_library(L2PUtility L2Packet.cpp L1Transport.cpp crc1021.cpp) target_include_directories(L2PUtility PUBLIC ${CMAKE_SOURCE_DIR} ${BOOST_ROOT}/include) Note there is no target_link_libraries, but ASIO works. I thought that was because it's an HPP/Header only implementation? Since I need to add some threading to the project, I thought I would use the boost_thread library. Examples online show the inclusion of boost/thread.hpp, so I assumed it is another header only implementation and no link library is needed but I am getting a linking error: [2/4] Linking CXX executable L2PSecondary FAILED: L2PSecondary : && /usr/bin/c++ -g CMakeFiles/L2PSecondary.dir/main.cpp.o -o L2PSecondary libL2PUtility.a && : /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): warning: relocation against `_ZTVN5boost6detail16thread_data_baseE' in read-only section `.text._ZN5boost6detail16thread_data_baseC2Ev[_ZN5boost6detail16thread_data_baseC5Ev]' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `L1Transport::start_detached()': /home/rhaley/tuleap/BoostAsioL2p/L1Transport.cpp:440:(.text+0x1b32): undefined reference to `boost::thread::detach()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::detail::thread_data_base::thread_data_base()': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/pthread/thread_data.hpp:162:(.text._ZN5boost6detail16thread_data_baseC2Ev[_ZN5boost6detail16thread_data_baseC5Ev]+0x24): undefined reference to `vtable for boost::detail::thread_data_base' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::thread::start_thread()': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/detail/thread.hpp:182:(.text._ZN5boost6thread12start_threadEv[_ZN5boost6thread12start_threadEv]+0x28): undefined reference to `boost::thread::start_thread_noexcept()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::thread::~thread()': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/detail/thread.hpp:257:(.text._ZN5boost6threadD2Ev[_ZN5boost6threadD5Ev]+0x18): undefined reference to `boost::thread::detach()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::thread::get_id() const': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/detail/thread.hpp:738:(.text._ZNK5boost6thread6get_idEv[_ZNK5boost6thread6get_idEv]+0x27): undefined reference to `boost::thread::native_handle()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::thread::join()': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/detail/thread.hpp:762:(.text._ZN5boost6thread4joinEv[_ZN5boost6thread4joinEv]+0x90): undefined reference to `boost::thread::join_noexcept()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o): in function `boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf<void (L1Transport::*)(), void, L1Transport>, boost::_bi::list<boost::_bi::value<L1Transport*> > > >::~thread_data()': /home/rhaley/tuleap/BoostAsioL2p/../stroma_dataman_service/boost-install-x86_64-Debug/include/boost/thread/detail/thread.hpp:94:(.text._ZN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi2mfIM11L1TransportFvvEvS6_JEEENS2_4listIJNS2_5valueIPS6_EEEEEEEED2Ev[_ZN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi2mfIM11L1TransportFvvEvS6_JEEENS2_4listIJNS2_5valueIPS6_EEEEEEEED5Ev]+0x26): undefined reference to `boost::detail::thread_data_base::~thread_data_base()' /usr/bin/ld: libL2PUtility.a(L1Transport.cpp.o):(.data.rel.ro._ZTIN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi2mfIM11L1TransportFvvEvS6_JEEENS2_4listIJNS2_5valueIPS6_EEEEEEEEE[_ZTIN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi2mfIM11L1TransportFvvEvS6_JEEENS2_4listIJNS2_5valueIPS6_EEEEEEEEE]+0x10): undefined reference to `typeinfo for boost::detail::thread_data_base' /usr/bin/ld: warning: creating DT_TEXTREL in a PIE collect2: error: ld returned 1 exit status I tried adding a target_link_library: target_link_libraries(L2PUtility PUBLIC boost_thread) To no avail. I now get a missing library in the EXECUTABLE, not in the library that actually includes boost_thread! Does that mean it found it for the L2Utility library? (so confused...) Here is my executable target: add_executable(L2PSecondary main.cpp) target_include_directories(L2PSecondary PRIVATE ${CMAKE_SOURCE_DIR} ${BOOST_ROOT}/include) target_link_libraries(L2PSecondary PRIVATE L2PUtility) And here is the linking error: [1/2] Linking CXX executable L2PSecondary FAILED: L2PSecondary : && /usr/bin/c++ -g CMakeFiles/L2PSecondary.dir/main.cpp.o -o L2PSecondary libL2PUtility.a -lboost_thread && : /usr/bin/ld: cannot find -lboost_thread: No such file or directory collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. I confirmed that my boost installation has the library libboost_tread.a. rhaley@linuxdev2:~/tuleap/dataman_service/boost-install-x86_64-Debug$ find . -iname "*thread*.a" ./lib/libboost_thread.a Adding link libraries to the executable targets doesn't fix anything. Can anyone point out what I am doing wrong? Thanks in advance, Russ

1 0

"error: Unable to find file or target named" when using BCP to change Boost namespace
by Nicholas Williams 17 Jan '25

17 Jan '25

Background: My organization uses Boost internally for one of its software products, which is itself a C++ library. Users of our library also often use Boost. As such, we must compile our Boost in a different namespace so that the Boost symbols loaded when our library loads do not interfere with whatever different-version Boost symbols our users might load. Historically, another member of the team has been responsible for building new versions of Boost, but now it's me. I am doing this the same way our code/documentation has previously done it, but it is no longer working, and the errors I'm receiving are not familiar to the team member who was previously responsible for this. The last time we built a new Boost version was 1.80.0. I am now doing it with 1.87.0. The example: Further below, I include a lot of information and build commands, but that might not be useful to you. To help, I have created a minimal reproduction program for reproducing the error. You can clone and use it here: https://github.com/beamerblvd/unable-find-target-with-boost-bcp The good: With minimal effort and using our existing tools and configurations, I was easily able to bootstrap `b2` and then run `b2` to build stock Boost with the normal `boost` namespace. All of that worked perfectly and without error. The bad: When I went to do the same thing but with our custom namespace (via bcp), things fell apart. Our existing tooling copies the untouched 1.87.0 source tree into {dir}/_src. {dir}/user-config.jam is configured as follows: ``` constant BOOST_VERSION : mybranchname-1.87.0.a ; constant MY_PLATFORM : macos15-clang16-arm-d ; constant MY_LABEL : MYextralLabel ; constant BOOST_USER_CONFIG : <my_boost/config/user.hpp> ; using clang : 16 : clang++ : <cxxflags>-fvisibility=hidden <cxxflags>-fvisibility-inlines-hidden ; ``` Within {dir}/_src, I call `bootstrap.sh` and then build `bcp` with: bc -sBOOST_ROOT={dir}/_src \ --boost-build=tools/build/src \ cxxstd=20 \ -d \ 2 \ -j \ 2 \ -q \ --prefix={dir}/bcp \ --build-dir={dir}/bcp \ --stagedir={dir}/bcp/stage \ --user-config={dir}/user-config.jam \ --layout=system \ toolset=clang-darwin \ threading=multi \ link=shared \ architecture=arm \ instruction-set=nocona \ address-model=64 \ --without-python \ --disable-icu \ variant=release tools/bcp That takes a few minutes to complete and does so without error. Once `bcp` is built, I run it with: mkdir {dir}/_dst && \ {dir}/bcp/bin/bcp --boost={dir}/_src --namespace=boost_MYextralLabel --namespace-alias Jamroot boost boost-build.jam boostcpp.jam bootstrap.bat bootstrap.sh build status tools [insert_name_of_every_dir_in_libs] {dir}/_dst That takes a few minutes to complete and does so without error. The contents of {dir}/_dst look as I would expect them to look, with diffs against {dir}/_src reflecting the change in namespace. Once complete, I cd into {dir}/_dst, re-bootstrap, and run `b2` to compile the modified Boost: b2 -sBOOST_ROOT={dir}/_dst \ --boost-build=tools/build/src \ cxxstd=20 \ -d \ 2 \ -j \ 2 \ -q \ --prefix={dir} \ --build-dir={dir}/shobj \ --stagedir={dir}/stage \ --user-config={dir}/user-config.jam \ --layout=system \ toolset=clang-darwin \ threading=multi \ link=shared \ architecture=arm \ instruction-set=nocona \ address-model=64 \ --without-python \ --disable-icu \ variant=debug This fails quickly, here: ... - native syslog supported : yes [2] - pthread supports robust mutexes : no [2] - Boost.Regex is header-only : yes [2] error: Unable to find file or target named error: '/boost/align//boost_align' error: referred to from project at error: '{dir}/_dst/libs/atomic/build' make: *** [build] Error 1 I have tried dozens of different things over the past two days and can't remember most of them, but they didn't change the outcome, so I don't supposed they're relevant. The one thing that *did* change the outcome is that, after running `bcp` and before re-bootstrapping in {dir}/_dst, I tried deleting the {dir}/_dst/boost directory. This still failed, but it got slightly further and failed with a different (albeit extremely similar) error: ... - std_wstreambuf : no [2] - std_wstreambuf : no [3] - BOOST_COMP_GNUC >= 4.3.0 : no [2] - BOOST_COMP_GNUC >= 4.3.0 : no [4] error: Unable to find file or target named error: 'libs/thread/build//boost_MYextralLabel_thread' error: referred to from project at error: '.' make: *** [build] Error 1 I feel like I've exhausted my ability to discern what the problem is. Other than updating a handful of compiler flags (like changing cxxstd=17 to cxxstd=20), I'm doing this the same way we have (allegedly) always done it, but it's not working anymore and I don't know why. I would appreciate any guidance you can offer. Thank you, Nick

2 6

"error: No best alternative for {dir}/libs/mpi/build/boost_mpi", but the build succeeds
by Nicholas Williams 17 Jan '25

17 Jan '25

I'm building the full stock, unmodified Boost 1.87.0. I have previously built Boost 1.80.0 without issue. After bootstrapping, when running `b2` to actually build Boost, I get the following "errors": ... - has stat::st_birthtimespec : yes [5] - has fdopendir(O_NOFOLLOW) : yes [5] - has dirent::d_type : yes [5] - has POSIX *at APIs : no [5] - has fallocate : no [5] - cxx11_static_assert : yes [5] error: No best alternative for {dir}/libs/mpi/build/boost_mpi with <abi>aapcs <address-model>64 <architecture>arm <asynch-exceptions>off <binary-format>mach-o <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off <cxxstd-dialect>iso <cxxstd>20 <debug-symbols>off <exception-handling>on <extern-c-nothrow>off <inlining>full <instruction-set>nocona <known-warnings>hide <link>shared <optimization>speed <os>MACOSX <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.9 <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>darwin <testing.execute>on <threadapi>pthread <threading>multi <toolset-clang:platform>darwin <toolset-clang:version>14 <toolset>clang <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <x-deduced-platform>arm_64 matched: (empty) matched: (empty) error: No best alternative for {dir}/libs/mpi/build/boost_mpi with <abi>aapcs <address-model>64 <architecture>arm <asynch-exceptions>off <binary-format>mach-o <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <coverage>off <cxxstd-dialect>iso <cxxstd>20 <debug-symbols>off <exception-handling>on <extern-c-nothrow>off <inlining>full <instruction-set>nocona <known-warnings>hide <link>shared <optimization>speed <os>MACOSX <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.9 <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>darwin <testing.execute>on <threadapi>pthread <threading>multi <toolset-clang:platform>darwin <toolset-clang:version>14 <toolset>clang <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <x-deduced-platform>arm_64 matched: (empty) matched: (empty) - gcc visibility : yes [2] - cxx14_decltype_auto : yes [2] - cxx14_generic_lambdas : yes [2] ... I used scare quotes around "errors," because these errors do not appear to actually break anything. The build completes fully and successfully, and all the libraries are built as expected. It appears to be more of a warning than an error, but I don't love warnings either, so I'd like to solve it. The only relevant result I could find Googling about this was [this other mailing list message]( https://lists.boost.org/Archives/boost/2024/11/258275.php) which was a reply to "[release] Boost 1.87.0 Beta 2 Release Candidate is available," and to which nobody ever replied. Doesn't really clear anything up for me. FWIW, I get these "errors" on RHEL 8 GCC 8, 9 GCC 11, and 9 GCC 14; Ubuntu 20.04 GCC 9, 22.04 GCC 11, and 24.04 GCC 13; macOS 12 Clang 14 (Intel and ARM), 14 Clang 16 (Intel and ARM), and 15 Clang 16 (Intel and ARM); Windows 10 MSVC 2022 and 11 MSVR 2022; and Windows Server 2022 MSVC 2022 and 2025 MSVC 2022. Any insights or guidance would be appreciated. Thanks, Nick

2 4

ICU not found while building Boost
by Cory Riddell 13 Jan '25

13 Jan '25

I'm having trouble building Boost 1.87 on Windows using the latest VS2022. I'm starting from the "x64 Native Tools Command Prompt for VS 2022". I've downloaded the latest ICU binaries and updated my PATH, LIB, and INCLUDE environment variables: set PATH=%PATH%;D:\icu\bin64 set LIB=%LIB%;D:\icu\lib64 set INCLUDE=%INCLUDE%;D:\icu\include I go into my boost directory and run bootstrap.bat. It seems to complete, creating b2.exe. I then run "b2 address-model=64" and it's not finding icu: E:\boost_1_87_0>b2 address-model=64 Performing configuration checks - default address-model : 64-bit [1] - default architecture : x86 [1] Building the Boost C++ Libraries. warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam. note: to suppress this message, pass "--without-graph_parallel" to bjam. - icu : no [2] - iconv (libc) : no [2] - iconv (separate) : no [2] - cxx11_auto_declarations : yes [2] - cxx11_decltype : yes [2] I ctrl-c to quit at this point and looked at my config.log and it doesn't seem to find icu when building has_icu_test.obj: compile-c-c++ bin.v2\libs\locale\build\msvc-14.3\debug\x86_64\link-static\threading-multi\has_icu_test.obj has_icu_test.cpp E:\boost_1_87_0\libs\locale\build\has_icu_test.cpp(6): fatal error C1083: Cannot open include file: 'unicode/coll.h': No such file or directory The file D:\icu\include\unicode\coll.h does exist though. Is there some reason my environment variables don't make it to the processes kicked off by b2? Or am I overlooking something obvious? Any help is greatly appreciated. Cory

3 3