September 2024 - Boost - lists.preview.boost.org

Pretty printer module
by Дмитрий Архипов 14 Apr '25

14 Apr '25

Recently Niall Douglas posted about his idea to embed GDB pretty printers into binaries using a header. At the time I was thinking about a good way to deploy pretty printers for JSON that facilitates their autoloading. After Niall's post I experimented a little bit more, and I came to the conclusion that indeed nothing beats embedding via a C++ header in terms of convenience. At the same time I was also thinking about testing that pretty printers do in fact work. Given that pretty printers (usually) are implemented as a Python module, it initially looked like one could just run a Python program and import GDB Python modules. But actually you cannot. It turns out, though, you can run a Python script with GDB as the interpreter. After several iterations I arrived at this setup: https://github.com/boostorg/json/blob/develop/test/printers.cpp. A script converts this file into a Python script that uses GDB to break on certain lines and check if a particular expression produces a particular output when printed. While doing all this I thought that most of this work can be useful to other libraries. So, I moved the reusable parts into a separate directory (https://github.com/boostorg/json/tree/develop/pretty_printers) and added both a b2 module, and a CMake module. For B2. Importing: https://github.com/boostorg/json/blob/develop/build.jam#L8-L9 https://github.com/boostorg/json/blob/develop/build/Jamfile#L13 (Re)generating the header: https://github.com/boostorg/json/blob/develop/build/Jamfile#L88-L95 Testing: https://github.com/boostorg/json/blob/develop/test/Jamfile#L96-L101 For CMake: Importing: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L54-L55 (Re)generating the header: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L56-L63 Testing: https://github.com/boostorg/json/blob/develop/test/CMakeLists.txt#L80-L88 My questions to the community: do you find this useful? Would you use it in your Boost or non-Boost library? If you do, the module should be moved to tools rather than stay in libs/json.

12 24

Boost cross-compilation and testing (Linux -> Windows)
by Martin Vejbora 16 Oct '24

16 Oct '24

Hello, we're working on a new target for MinGW compiler, we're intending to have a cross-compiler from Linux Arm64 to Windows Arm64. We want to have Boost library as a benchmark of how complete our C++ compiler is and gradually improve it to support more features. I'm struggling though to get the cross-compilation and subsequent testing working. 1) I'm having troubles to set up cross-building of Boost with MinGW (even standard MinGW from package manager Linux x64 -> Windows x64). I'm getting errors while building Context, Process and Stacktrace modules. (I added to the respective error messages to the end of the email or full logs can be found here: https://github.com/user-attachments/files/17133738/x64_boost_build.log) My build commands: git clone --recursive https://github.com/boostorg/boost.git boost-build cd boost-build git checkout develop git submodule update --init --recursive echo "using gcc : : x86_64-w64-mingw32-g++ ;" > "user-config-x64.jam" ./bootstrap.sh ./b2 --user-config=./user-config-x64.jam --prefix=./boost-x64 --debug-configuration target-os=windows address-model=64 variant=debug install > x64_boost_build.log >From the error messages, it seems like I'm doing something essential wrong as for example Process module tries to build assembler for ELF format and SYSV ABI and not Window's PE format and MS ABI. 2) Subsequently, I didn't have much luck finding resources for cross-testing of Boost. Currently, I'm building and running tests in Ubuntu 22.04 in WSL on Windows machine. In general, this approach seems to work decently, Boost itself and its tests are built on Ubuntu as Windows binaries and when test executables are run, WSL automatically propagates it to run those executables on underlaying Windows. But a lot of tests are failing. I'm gradually investigating them and finding issues like missing dlls because b2 uses LD_LIBRARY_PATH and Windows doesn't understand it. I'm workarounding these issues but it's a slow process, so I wanted to ask, is the cross-testing of Boost library supported, are you aware of some examples where it's being used? Thank you and kind regards, Martin ------------------------------------------------------------------------------- a) Context errors: (similar also for jump_x86_64_sysv_elf_gas.S and ontop_x86_64_sysv_elf_gas.S) gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ asm/make_x86_64_sysv_elf_gas.o make_x86_64_sysv_elf_gas.S: Assembler messages: make_x86_64_sysv_elf_gas.S:47: Warning: .type pseudo-op used outside of .def/.endef: ignored. make_x86_64_sysv_elf_gas.S:47: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Warning: .size pseudo-op used outside of .def/.endef: ignored. /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157: Error: junk at end of line, first unrecognized character is `m' /home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:160: Error: junk at end of line, first unrecognized character is `-' "x86_64-w64-mingw32-g++" -x assembler-with-cpp -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/context/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/type_traits/include" -c -o "bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o" "/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o... ------------------------------------------------------------------------------- b) Process errors: gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/ext/exe.o /home/vejby/boost-build/libs/process/src/ext/exe.cpp: In function ‘boost::filesystem::path boost::process::v2::ext::exe (HANDLE, boost::system::error_code&)’: /home/vejby/boost-build/libs/process/src/ext/exe.cpp:78:9: error: ‘QueryFullProcessImageNameW’ was not declared in this scope 78 | if (QueryFullProcessImageNameW(proc, 0, buffer, &size)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o" "/home/vejby/boost-build/libs/process/src/ext/exe.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/ext/exe.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/windows/default_launcher.o In file included from /home/vejby/boost-build/libs/process/src/windows/ default_launcher.cpp:16: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init <Executor, Inits ...> boost::process::v2::windows::default_launcher:: operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp: In static member function ‘static std::size_t boost::process::v2::windows:: default_launcher::escape_argv_string(wchar_t*, std::size_t, boost::basic_string_view<wchar_t, std::char_traits<wchar_t> >)’: /home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp:64:16: warning: unused variable ‘end’ [-Wunused-variable] 64 | const auto end = itr + sz; | ^~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o" "/home/vejby/boost-build/libs/process/src/windows/default_launcher.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/windows/default_launcher.o... ------------------------------------------------------------------------------- gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64 boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/environment.o In file included from ./boost/process/v2/default_launcher.hpp:17, from /home/vejby/boost-build/libs/process/src/environment.cpp:13: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW ./boost/process/v2/windows/default_launcher.hpp: In member function ‘boost::process::v2::windows::default_launcher::enable_init<Executor, Inits ...> boost::process::v2::windows::default_launcher::operator()(Executor, boost::system::error_code&, const typename std::enable_if<( boost::asio::execution::is_executor<T>::value || boost::asio::is_executor<Executor>::value ), boost::filesystem::path>::type&, Args&&, Inits&& ...)’: ./boost/process/v2/windows/default_launcher.hpp:312:10: error: ‘startup_info’ was not declared in this scope 312 | &startup_info.StartupInfo, | ^~~~~~~~~~~~ "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"." -I"/home/vejby/boost-build/libs/algorithm/include" -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/bind/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/detail/include" -I"/home/vejby/boost-build/libs/filesystem/include" -I"/home/vejby/boost-build/libs/function/include" -I"/home/vejby/boost-build/libs/function_types/include" -I"/home/vejby/boost-build/libs/fusion/include" -I"/home/vejby/boost-build/libs/iterator/include" -I"/home/vejby/boost-build/libs/move/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/optional/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/process/include" -I"/home/vejby/boost-build/libs/regex/include" -I"/home/vejby/boost-build/libs/scope/include" -I"/home/vejby/boost-build/libs/smart_ptr/include" -I"/home/vejby/boost-build/libs/system/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/tuple/include" -I"/home/vejby/boost-build/libs/type_index/include" -I"/home/vejby/boost-build/libs/type_traits/include" -I"/home/vejby/boost-build/libs/unordered/include" -I"/home/vejby/boost-build/libs/variant2/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o" "/home/vejby/boost-build/libs/process/src/environment.cpp" ...failed gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/ link-static/target-os-windows/threadapi-win32/threading-multi/ visibility-hidden/environment.o... ------------------------------------------------------------------------------- c) Stacktrace error: gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o /home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp:161:10: fatal error: dlfcn.h: No such file or directory 161 | #include <dlfcn.h> | ^~~~~~~~~ compilation terminated. "x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -I"." -I"/home/vejby/boost-build/libs/assert/include" -I"/home/vejby/boost-build/libs/container_hash/include" -I"/home/vejby/boost-build/libs/core/include" -I"/home/vejby/boost-build/libs/describe/include" -I"/home/vejby/boost-build/libs/mp11/include" -I"/home/vejby/boost-build/libs/predef/include" -I"/home/vejby/boost-build/libs/stacktrace/include" -I"/home/vejby/boost-build/libs/throw_exception/include" -I"/home/vejby/boost-build/libs/winapi/include" -c -o "bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/ target-os-windows/threadapi-win32/threading-multi/visibility-hidden/ from_exception.o" "/home/vejby/boost-build/libs/stacktrace/build/../src/from_exception.cpp" ...failed gcc.compile.c++ bin.v2/libs/stacktrace/build/gcc-10/debug/x86_64/link-static/target-os-windows/ threadapi-win32/threading-multi/visibility-hidden/from_exception.o...

3 4

[optional] Feedback on the range interface for Boost.Optional
by Andrzej Krzemienski 05 Oct '24

05 Oct '24

Hi Everyone, I have just recorded the following message in the Mailing List. sob., 14 wrz 2024 o 02:44 Alan de Freitas via Boost <boost(a)lists.boost.org> napisał(a): > - As people seem to imply, the WG21 issue goes way beyond the motivation > behind the proposals or the difficulty behind the Boost review process. Not > all Boost libraries are intended to go through WG21. Not all WG21 proposals > would make good Boost libraries (like begin/end iterators for > std::optional). We are in the process of implementing the range interface for Boost.Optional, as proposed in P3168R2 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3168r2.html> and to the extent possible in C++11. I would like to hear opinions from the people in this list, on if and why this would be a bad idea. Regards, &rzej;

9 18

Two mqtt libraries
by Robert Ramey 03 Oct '24

03 Oct '24

I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library: https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don't participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this. Robert Ramey

10 17

std::multiset functionality support in boost interprocess headers
by Murali Kishore 30 Sep '24

30 Sep '24

Hi all, I see multiset is not present in boost interprocess, so I tried to use a "set" with a customized comparator to achieve multiset functionality. sample code: struct set_comparator { bool operator()(const int& a, const int& b) const { return a < b; // if change a <= b then seeing an errror } }; bip::shared_memory_object::remove("SHM"); bip::managed_shared_memory segment(bip::open_or_create, "SHM", 2047*1024*1024); typedef bip::allocator<int, bip::managed_shared_memory::segment_manager> ShmemAllocator; typedef bip::set<int, set_comparator, ShmemAllocator> ShmemSet; segment.destroy<ShmemSet>("MySet"); ShmemSet *sample1 = segment.construct<ShmemSet>("MySet")(set_comparator(), segment.get_segment_manager()); std::cout << "Insert in shared set:" << std::endl; sample1->insert(40); std::cout << "Insert in shared set:" << std::endl; sample1->insert(40); // Crashing here sample1->insert(40); sample1->insert(40); sample1->insert(20); sample1->insert(20); sample1->insert(20); sample1->insert(20); sample1->insert(20); when i try duplicate insertion, seeing following error, /usr/include/boost/intrusive/bstree.hpp:1331: boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::iterator boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::insert_unique_commit(boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::reference, const insert_commit_data&) [with ValueTraits = boost::intrusive::bhtraits<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::normal_link, boost::intrusive::dft_tag, 3>; VoidOrKeyOfValue = void; VoidOrKeyComp = boost::container::value_to_node_compare<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::tree_value_compare<boost::interprocess::offset_ptr<int, long int, long unsigned int, 0>, main()::set_comparator, boost::move_detail::identity<int>, bool, true>, bool>; SizeType = long unsigned int; bool ConstantTimeSize = true; boost::intrusive::algo_types AlgoType = boost::intrusive::RbTreeAlgorithms; HeaderHolder = void; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::iterator = boost::intrusive::tree_iterator<boost::intrusive::bhtraits<boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, boost::intrusive::normal_link, boost::intrusive::dft_tag, 3>, false>; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::reference = boost::container::dtl::tree_node<int, boost::interprocess::offset_ptr<void>, boost::container::red_black_tree, true>&; boost::intrusive::bstree_impl<ValueTraits, VoidOrKeyOfValue, VoidOrKeyComp, SizeType, ConstantTimeSize, AlgoType, HeaderHolder>::insert_commit_data = boost::intrusive::insert_commit_data_t<boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void> >, long int, long unsigned int, 0> >]: Assertion `( p == this->end() || !this->comp()(*p, value) )' failed. "Need input on this or is this expected behaviour as per boost??" -- Regards, Murali Kishore

4 7

Shorter syntax for using a class constructor as a transform function.
by Andrzej Krzemienski 30 Sep '24

30 Sep '24

Hi Everyone, I would like to check if something like the following would be a useful addition to Boost.Core, or if something like this maybe exists: I have a class like ``` struct X { std::string str; explicit X(const std::string& s) : str(s) {} }; ``` I need to transform a vector of strings into a vector of X through invoking the constructor of X: ``` std::vector<std::string> strings = {"cat", "dog", "emu", "fox"}; std::vector<X> xs; std::transform(strings.begin(), strings.end(), std::back_inserter(xs),[](auto const& s) { return X(s); })); ``` It works, but a shorter version would be to introduce a component that is equivalent to the lambda: ``` std::transform(strings.begin(), strings.end(), std::back_inserter(xs), construct<X>)); ``` The full example: https://godbolt.org/z/85YoP9Pa9 Regards, &rzej;

4 4

Boost Asset Stewardship Review Result - Fiscal Committee Name
by Glen Fernandes 30 Sep '24

30 Sep '24

Ion wrote: > Fiscal Sponsorship Committee/Group sounds straightforward to me, > to make clear this group has no other duty than that. Thank you Ion - I agree. "Fiscal Sponsorship Committee" has my acceptance. Glen

3 2

Boost Asset Stewardship Review Result
by Glen Fernandes 29 Sep '24

29 Sep '24

Dear Boost developers and users, This concludes the Boost Asset Stewardship review was conducted between 09/03 and 09/22. I want to thank everyone who submitted a review and everyone who otherwise contributed to the discussion. What follows is my review result. For fairness and for the record, this is my connection to all parties involved: For the Boost C++ libraries I am or have been: - A Boost library author, - A maintainer of at least three Boost libraries, - A contributor to at least ten other Boost libraries, - A review manager of at least two Boost reviews, - A release manager, - A maintainer of the Boost GitHub organization, - A moderator of the Boost mailing lists, For the Boost Foundation I am or have been: - A former member of the Boost Steering Committee - A director on the board, For the C++ Alliance I have been: - A volunteer that helped review project specifications and resumes, On behalf of the Boost community, I accept the C++ Alliance Fiscal Sponsorship proposal with the following condition: - The new committee should be named something which clearly indicates that its purpose is confined to Boost's assets or infrastructure. There should be no confusion or question over whether it has any control or even other influence over the C++ library development. Please avoid any mention of "Steering" or "Direction". I accept the three initial members of the committee as proposed (Ion, Rene, Joaquin) without reservations. All three are Boost developers whom I respect and I am confident of their ability and their desire to serve the Boost community. While I appreciate the invitation to join, and would otherwise never refuse an opportunity to help Boost, I feel like my making the acceptance decision of the founding committee should prohibit me being on that list. The reviews and the discussion has convinced me that the Fiscal Sponsorship model is the right choice for Boost going forward. - It provides us with the financing we need now, and secures a very credible path for depending on them going forward. Moreover, it puts the administration of those resources in the hands of those representing our community. The Foundation can and has tried to achieve the same thing, but it should be obvious that it does not have the same level of financial resources, or technical and legal expertise at its disposal. - It has the support of a great majority of the Boost community. It is no secret that there has been a growing rift between the Boost developers and some of the Foundation members, despite my and others best attempts at healing it. Even with the same resources provided to the Foundation, I don't see it achieving the same level of acceptance and consensus that the C++ Alliance has. I want to thank the C++ Alliance for crafting this proposal, and giving us a solution for supporting those parts of Boost infrastructure that are increasingly expensive and complex to manage. This will allow the rest of us to focus on what we love doing: Working on C++ libraries. And I would be remiss if I did not repeat my gratitude to the C++ Alliance and to Vinnie for those times in the past he has come to Boost's rescue, many of these at my request. Next, I want to thank all present and past members of the Foundation and the Steering Committee for their service to the Boost project. Especially, I want to thank Michael Caisse for all the time and energy he has dedicated over the years to supporting the parts of Boost site and mailing lists that we take for granted. On that same note I want to thank the Foundation for agreeing to this review and committing to its result. If nothing else, I hope this act alone demonstrates to the community that despite past events, the intention of the Foundation is to act in accordance with the community's wishes. I would also like to make it known that I will submit a suggestion in the next meeting that the Boost Foundation rename itself to not include the word "Boost". Ultimately, it will come down to a vote between the board members, but I believe this is the best thing for the Foundation. Just as the rename from BoostCon to C++Now enabled the conference to achieve its goals of reaching the broader C++ community, the hope is that this will similarly enable the Foundation to succeed with its current mission, which spans beyond Boost. Finally, I want to repeat my thanks to the community for their voice in this review. While the list above of my involvement in Boost might seem significant, it really is not. I have contributed a small fraction of what some of the people who participated in this review have. But all of us are here because we are invested in Boost and want it to succeed more than it has already. And I hope that the decision above will help Boost do just that. Sincerely, Glen

8 13

Re: [boost] Boost Digest, Vol 7351, Issue 3
by Alfredo Correa 26 Sep '24

26 Sep '24

Hi Andrzej, Thanks for the continued conversation. > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > Subject: [boost] [multi] A successor to Boost.MultiArray? > Did I get it right that Multi can be considered a superior alternative to > Boost.MultiArray? > yes If so, it triggers a couple of points: > * Can Boost.MultiArray be upgraded instead? > MultiArray is a superset of BMA. I have a test in the CI to show that this library fulfills all the concepts BMA defines. There are still semantic differences in BMA, such as the quality of implementation issues or plain semantic bugs. Before we go down this road, I did try many times to overhaul BMA. The architecture of BMA is beyond repair. Some obstacles seem to be even purposeful features of the library, such as disallowing the assignment of arrays of different sizes. Layout information is heap allocated. Iterators are broken and too basic. Subblock views have a complicated, inefficient implementation. The lack of responsiveness of the original authors was also an issue. Don't get me wrong, BMA was a tour-de-force at the time. It even spearheaded C++ concept checking in C++98, which I have delayed integrating into the library until C++20 Concepts. * The same questions, "is it useful at all", apply also to Boost.MultiArray. > BMA is useful in principle and was a great leap forward then. In practice, it is unfortunately almost unusable. You can tour Stackoverflow questions on #boost-multi-array and see all its pain points. > * Whatever the motivation for using Boost.MultiArray is, it should also be > a good motivation for Multi. > yes > I read in the Boost.MultiArraydocs that it is a better replacement for > vector<vector<...>>. Yes, but this is a simplistic description. It is mainly used to explain the multi-index element access A[i][j], etc., but the analogy ends there. Of course it is a completely different data structure, vector<vector<...>> is more general (at a price), the "rows" can be staggered. In any case, it is, at worst a replacement for vector<vector<vector.< ....>>> *recursively*. > So, maybe a good use case is for simple use cases, > where you want to store and perform a simple access to relatively > small-sized data sets, where performance is important, but not > super-critical, and changing from nested vectors to Multi is already good > and sufficient an optimization. > I don't know how you conclude this is for small-sized data? Do you mean that vector<vector<...>> would be ok for large-size data in contrast? I don't think so. > As a side note, when comparing Multi with std::mdspan. The latter requires > C++23, while the former, only C++17. So, when someone has C++17, mdspan is > not an option. yes > BTW, why do you require C++17? > - The main reason was for ease of development: - implementing allocator propagation without if-constexpr is a nightmare. - c++17 provides polymorphic allocators, and I wanted to be compatible with them (at the time, I didn't know about __has_include, it was much simpler to just use C++17) - If I remember correctly, I could use some constexpr algorithms and make the arrays fully constexpr. These are not hard reasons to require C++17. I can port it to C++14 as soon as any user asks for it, but it hasn't happened yet. In fact, Vinnie Falco promised a gazillion dollars from Microsoft to port it back to C++14. ;P ( https://cpplang.slack.com/archives/C27KZLB0X/p1682786897070269) Thank you, Alfredo

2 2

A More Welcoming Community
by Vinnie Falco 26 Sep '24

26 Sep '24

We could stimulate participation, help the community cohesion, and provide a convenient place to post a rules reminder link. When someone signs up for the mailing list there can be an option checkbox if they want to have their name announced to the list. For example, upon signup, mailman could send something like this: From: boost(a)lists.boost.org Subject: New Member Please welcome "Patrick Programmer" to the Boost Developer's mailing list! As a friendly reminder please familiarize yourself with tips from the Boost Discussion Policy described here: https://www.boost.org/community/policy.html What do you think? Thanks

10 21

[multi] A successor to Boost.MultiArray?
by Andrzej Krzemienski 25 Sep '24

25 Sep '24

Alfredo, Did I get it right that Multi can be considered a superior alternative to Boost.MultiArray? If so, it triggers a couple of points: * Can Boost.MultiArray be upgraded instead? * The same questions, "is it useful at all", apply also to Boost.MultiArray. * Whatever the motivation for using Boost.MultiArray is, it should also be a good motivation for Multi. I read in the Boost.MultiArraydocs that it is a better replacement for vector<vector<...>>. So, maybe a good use case is for simple use cases, where you want to store and perform a simple access to relatively small-sized data sets, where performance is important, but not super-critical, and changing from nested vectors to Multi is already good and sufficient an optimization. As a side note, when comparing Multi with std::mdspan. The latter requires C++23, while the former, only C++17. So, when someone has C++17, mdspan is not an option. BTW, why do you require C++17? Regards, &rzej;

1 0

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

> > Date: Sat, 21 Sep 2024 20:10:25 +0300 > From: Artyom Beilis <artyom.beilis(a)gmail.com> > > I do scientific computing with large arrays, and nobody uses OpenCV. > > It would be fair if you had said that it is the de facto standard for > image processing, which I don't do. > > > > Ok... if you haven't used does not mean that it isn't very common > computing library that many developers/designers go by default. > Maybe we don't agree what numeric means, or we just work in different environments. Anyway, I would agree that OpenCV is unquestionably a standard for image processing. > > > Second, Multi is not a numerical library specifically; it is about the > logic and semantics of multidimensional arrays and containers, regardless > of the element type. > > ... > > > See, this is exactly the problem. Why would I need something like that > if I need to go to all the 3rd party libraries to actually use one > efficiently? > The same reason some of use the standard library containers, or ranges, etc, even if they don't "do everything". > cv::Mat is numpy like NDArray with strides, windows, offsets (yes it > supports more than two dimensions). I myself used/written several > Tensor like objects and used (pytorch C++ tensor, dlprimitives > and other objects). It is nothing new, by all means it is the easiest > part of any numerical library. > I don't know how generically OpenCV can treat strides, windows, offsets, etc.; I trust you. Again, this boils down to compare apples with oranges, frameworks vs components. I don't have experience with OpenCV, I have seen code using with OpenCV, it seems it has a lot of features, you can load images, render windows, and do some array computations. It doesn't look like generic code to me, STL can not be used directly, for example (which is fine). I propose that, if you need to read images, and do the standard things that openCV is build for, such image processing, and probably much beyond, by all means use OpenCV. And I propose that if you need to do generic programming with standard algorithms, iterators, and some level of abstraction, use Multi, or something else. If you are not interested in the second (which is fine) then you are not the right audience for the proposed library. > >> > >> 2. While actual ndarry handling is nice, it is basically a tip of an > >> iceberg. You need a decent set of high performance algo combined with > it. > > > I couldn't agree more. The thing that I appreciate about generic programming and programming with components is that it separates data structures and algorithms. And if one does it right, the goal is no loss of efficiency. Of course this requires a lot of work, specially for library developers. > > > > There is a clear separation of concerns here. > > The Multi library deals with the data structure, it uses when it needs > to fulfill its semantics, the best *existing* algorithms it can in > awareness of the datastructure. > > The Multi library doesn't provide algorithms, it uses the algorithms > that are provided to it via different mechanisms. > > > > But if you don't provide algorithms, maybe I'd better take a > library/framework that does. > Exactly, that is the appeal of frameworks. Frameworks are great if they do all that you need and no less. The moment you need to do something that the framework has not contemplated you are totally on your own, without much help. There are plenty of numpy-like arrays around. Usually they are called > tensors... > I agree, and almost all of them are frameworks. I don't think anything works with existing STL algorithms, iterators. If you are not interested in this, this is not for you. > >> > > I agree, promising all linear algebra is infinite work, like > reimplenting MATLAB or Mathematica, but BLAS has a finite number of > functions. > > The philosophy of the BLAS-adaptor in particular (again, an optional > component) is to interface to what BLAS offers and not more. > > It is more of a model how to interface a legacy library using the > features of Multi. > > > But that is exactly what make opencv useful and multi-array like a > fasade with emptiness behind. > This is like saying all the STL containers are just "emptiness behind". In some sense it is true; you need algorithms, that exists separately. I understand your feelings. The emptiness that you feel, the "rest" is the algorithms and adaptors that exists separately from the data structure. There are excellent libraries for that, starting from STL. >> I did breef look into implementation and it seems to be lacking of > >> vectorization (use of intrinsics/vector operators) or have I missed? > > > > > > You missed that this is a generic, not specifically numerical, library. > > > But, you making numpy-like library... You keep bringing up numpy. Some users of the library see the analogy with numpy because of the easy of use, and I appreciate that but I don't mention numerics or numpy in the documentation, except in one or two places with very clear context. If, for you, numpy implies numerics, then you are using the wrong analogy and point of comparison. > otherwise you wouldn't be > interfacing cblas. > Would you feel better about it if I remove the BLAS adaptor? This is a completely optional component. This is to make the library more immediately useful without converting it into a framework. The interface with BLAS is very strictly to be have to use BLAS through the Multi facilities in a functional (immutable) context that is friendly, for example, to STL algorithms that take lambdas. See, if you have been talking about multi-array as advanced > std::vector of generic objects... Ok - but you don't > "Advanced std::vector of generic objects" is a fair scope for the library, thank you. I would say it is *very* advanced version of std::vector, but this is just an opinion I have. I don't understand exactly what is your complain, what do you mean with "but you don't". This is what I say in the introduction: "This library offers array containers and subarrays in arbitrary dimensions with well-behaved value semantics, featuring logical access recursively across dimensions and to elements through indices and iterators." I don't know where you read numerics in there. you direct it to the numeric computations. > I don't direct it to the numerical computation; I clearly say in the introduction that this is not a numerical library. I use build-in types (preferably ints) in the examples for conciseness. I just say that if you want to use it in numerical context, it still should be ok for that. The reason I don't and I won't explicitly rule out numeric applications in the documentation is because in my opinion there are no obstacles to put to use the library in numerical context. The library is in fact used in numerical context by other projects. > The other thing to take into account is that > vectorization/parallelization is still provided by the external algorithms > the library uses internally. > > For example, then dealing with GPU or OpenMP arrays, the library uses > thrust algorithms if they are available, which are parallel. > > > Just for the record there are two levels of parallelization on CPU > level: 1 thread based parallelization, 2nd SIMD level parallelization > like SSE/AVX2/Neon - where you load vectors of 16, 32 bytes of data > and process them together in a single instruction. > These can increase the performance significantly. Yes, I gave the example about thread paralellization, through execution policies, because it is cleaner. SIMD parallelization is more difficult to apply in general because it depends on data to be continuous in at least one dimension, which is only realized by very specific layouts (this is the reason BLAS matrices always have at least one stride = 1). This is not the general case, when you manipulate arrays dynamically. But I agree it still can be applied with some effort. I would do everything I can to offer the possibility of doing SIMD through the library in combination with external algorithms and lift any obstacles to it, if there are any. Having said that, it is not a big concern for the library implementation because 1) it is not numeric specifically, 2) semantic operations in the library, such as assignment or construction do not involve computation. However, if you have a clear idea how to enable SIMD for a particular problem you are free to do it, once again, through specialized algorithms. > > OpenCV isn't 2d only. It support n-D tensors with views. > Ok, I stand corrected then. @Artyom, Can you help me understand how it compare in these aspects that are important for my library? I bet OpenCV will do very well in the comparison. It is a simple checkbox list. - external Deps ? - Arbritary number of dims (e.g. 11 dimensions) - Non-owning view of data (e.g. manipulate view memory provided by others) - Compile-time dim size - Array values (owning data) (e.g. can I put arrays inside a std::list?) - Value semantic (Regular) (can I assign, swap, with expected Stepanov regularity results) - Move semantics (e.g. will this copy data arr2 = std::move(arr1) ?) - const-propagation semantics (e.g. Mat const arr; ... is arr really read-only) - Element initialization (e.g. can the arrays be initialized at declaration e.g. Mat const arr = {1.0, 2.0, ...}) - References w/no-rebinding (e.g. can I name a subblock of an array, e.g. `auto sub = subblock of arr`? does it have reference semantics (no copy)?) - Element access (e.g. how easy is to access a speicif elements, e.g. in 4 dimensions `arr( 3, 4, 5, 6)`) - Partial element access, (e.g. take n-th column or n-th row of a 2D array) - Subarray views (e.g. generate a "view" 2D subblock of a 2D array) - Subarray with lower dim (e.g. generate a "view" nD subblock of a mD array, where n < m). - Subarray w/well def layout (e.g. access the layout of a subblock, if sunblocks can be referred to?) - Recursive subarray (e.g. can sunblocks "views" of subblocks "view" be temporaries) - Custom Alloctors (e.g. thrust::device_allocator, boost::interprocess::allocator) - PMR Alloctors (e.g. use std::pmr::monotonic_memory_resource) - Fancy pointers / references (e.g. use memory not represented by raw pointers, e.g. thrust::device_pointer, boost::interprocess::offset_ptr) - Stride-based Layout (e.g. supports strides layout, element, and can gives this information to low level libraries) - Fortran-ordering (e.g. left-index is the fast index in memory) - Zig-zag / Tiles / Hilbert ordering / (e.g. fancy layouts beyond strides) - Arbitrary layout (e.g. can data be laid out arbitrarily in memory in a user-defined way, not strides, not zig-zag) - Flattening of elements (e.g. any facilities to look at the elements in a flatted way beyond simply giving a pointer to the first element, which will not work for subblocks) - Iterators (e.g. have the array, in any useful sense, .begin and .end?) - Multidimensional iterators (cursors) (e.g. auto h = arr_subarray.home(); h gives access to elements but is light as a pointer) - STL algorithms or Ranges (e.g. would it work with `std::sort`, `std::copy`, `std::reduce`, `std::rotate`, or with any ranges algorithm) - Compatibility with Boost (e.g. put arrays in Boost containers, use Boost Serialization, Boost interprocess, Boost algorithms) - Compatibility with Thrust or GPUs (e.g. can the array elements be in the gpu, and use the array through its interface without segfaulting, or use thrust::device_pointer memory) - Used in production (e.g. major users or industries) > > > > I consider that Eigen, OpenCV, Kokkos, PETSc are frameworks. > > > It reminds me of a comparison of Boost.Beast and a full scale > framework like CppCMS. > When I reviewed beast it was clear that it does not do 10% of what is > expected from something > to make an actually useful web application. > I am not an expert on Boost.Beast, but it looks like you are not the typical audience for some of Boost libraries. The key to me, although not exclusively, is the availability of generic components and generic programming. > While it is nice to have an abstraction - if so either keep it basic > or go full way - you are stuck somewhere > in between std::vector ++ and something like OpenCV. > This is a fair assessment, if you see resemblances with OpenCV is welcomed but accidental, since it is a library that I don't use. Sorry if you are disappointed this library doesn't do (directly at least) things that OpenCV does; the library definitely can do other things that OpenCV can't (and you are not interested in), and even if OpenCV can do them, it will do them with an interface that I is not within the scope of the goals of my library. > > > > I don't fill confident adding an OpenCV column because I don't have > experience with it, but feel free to help me adding a library and answering > the points of each row in the comparison table. > > > I suggest getting some experience with OpenCV. It is a very good > library that already implements what you have (also in a different > way) > I doubt OpenCV implements everything that Multi has. But even if it does, it does it with a different interface that was a priority for my design. (To be fair, Multi doesn't implement everything that OpenCV does either, for sure) > It ain't perfect by any means. But it works, well debugged, understood > and is a widely available library that does the job. > I don't doubt this. I think it is good that both libraries are different, I don't need all the bells and whistles that OpenCV has and it is undeniably a heavy dependency. I don't need rendering images, loading images, or be optimized for element types that OpenCV offers. > >> What is not clear to me is why should I use one over some existing > solution > >> like OpenCV? > > > > > > - Because sometimes your elements are not numerical types. > > > Yeahhh... don't buy it. Sorry :-) > yeah, but I do need a 100x100 array of std::strings. and a 20x10 array of std::tuples. I would love to know if OpenCV can store those. > > > > > - Because sometimes you want to specify your element types as template > parameters not as OpenCV encoded types. > > > To make your code compilation slower and more horrible? Actually > OpenCV supports templated accessors. > This is the perennial discussion between header-only and pre-compiled libraries. I don't have anything to add, the idea is that you pay at compilation for what you use. Feel free to try the library in Godbolt to see the compilation times and the machine code it produces. It is a pity that OpenCV is not in Godbolt to compare both online. Having said that, I would welcome any comparison in timing and usability between the two libraries within or around the scope of what I am proposing. > > > > - Because sometimes you want arbitrary dimensionality (e.g. 2D, 3D, 6D) > to be compile-time. > > > And why it isn't possible with OpenCV > I don't know, is it possible? >From the examples I see online, all OpenCV arrays regardless of dimensionality have all the same type. Maybe I am mistaken. > > > > - Because sometimes you want to apply generic algorithms to your arrays > (STL, std::sort, std::rotate, std::ranges, boost::algorithms, serialization) > > > Yeah... good luck with that in numerical context. But Ok. I use the library in numerical context, I have no problem with that: https://gitlab.com/npneq/inq https://github.com/QMCPACK/qmcpack > In OpenCV > you can just get several pointers and work with them > You can not have it both ways. If you need a pointer and the sizes (and strides), Multi gives you access for that too; and then according to your definition, it would be equally powerful as OpenCV. https://gitlab.com/correaa/boost-multi#legacy-libraries-c-apis > > > > - Because sometimes you want to implement function that are oblivious to > the actual dimension or your array (e.g. simultaneously view a 3D array of > elements as a 2D array of something, for abstraction). > > - Because sometimes you want to control allocations, use fancy pointers, > parameterized memory strategies, polymorphic allocators, > > > OpenCV support custom allocations (actually something I exactly use > right now to monitor memory consumption) > That is great, can you point me to an example? >From what I quickly see online, openCV gives its own allocators. I am not interested in non-standard allocators for this library. It is not clear to me if you can use standard allocators and PMR allocator in OpenCV. Can it take allocators that do not return raw pointer types such as GPU? and if not, what if you allocate a raw pointer with cudaMalloc, how much of the library can you still use? > Once again - be careful what you wish for. Templated allocators are > huge headache to work with in comparison to run-time ones (in real - > non fancy template world that Boost Loves) > It is not a matter of what I wish. The library is not a framework, allocation is something that the user of the library brings in. I don't choose it for them. > > > - Because sometimes you want precise value semantics > > > I'm not sure it is a great idea for huge arrays/matrices. Virtually > ALL tensor libraries have reference semantics for a very good reason. > Sometimes you need it, sometimes you don't. If you don't need, don't make copies, don't pass by value, that is the right thing to do and allowing the option it is a priority of the library. I prevent the library to make copies as much as I can, until the user really means it. > > > > - Because sometimes you want to work with subblocks of an array in the > same way to need you work with the whole array. > > > And this is exactly what view is for... And this is common for any > tensor library. > Great, I would feel bad if I didn't provide this fundamental feature. The next question is whether arrays and subarrays/subblocks/views can be treated in equal footing. > > - Because sometimes you want to give guarantees in the presence of > exceptions (the library doesn't throw exceptions, to be clear). > > Ok this is one of the points I want to discuss here in terms of > design, exceptions and broadcasting. > Lets take an example (numpy - but same works for torch::Tensor) > > a=np.ones(5,10) > b=np.ones(2,5,1) > c=a+b > > It would perform broadcasting to Shape = (2,5,10) - automatically. How > it can be done - you broadcast shapes > of a to 2,5,10 using strides (0,10,1) and broadast b to same shape > using strides (5,1,0) (I hope I have not mistaken in calcs) > Then you can run easily on shape 2,5,10 and do all calculations, fetching > etc. > > Looking into your broadcasting docs - left me with the impression it > does not support anything like this. > What do you mean by "anything like this"? The library doesn't make algebraic assumptions about the arrays of the elements. There is no binary addition + in the library, you can define your own if you want, using well know algorithms or specializations of them. Once you tell me what is your specification and implementation of '+' I can tell you how to use broadcast for your case. If it is a good example I could even add it to the documentation. Note that + implies an algebra, I don't consider it part of the scope of the library. Broadcast instead is part of the library because I consider it a non-algebraic but very powerful array manipulation feature. Broadcast is implemented in the library within a certain design. I think you are disapointed because the broadcast is not "automatic", which is a different issue. > I read this: > > > First, broadcasted arrays are infinite in the broadcasted > dimension; iteration will never reach the end position, and calling > `.size()` is undefined behavior. > > Why? You certainly can iterate over broadcasted dimension... > Yes, you can iterate, that is fine. multi::array<int, 1> A1D = {1, 2, 3}; auto const& A2D = A1D.broadcast(); // A2D = { {1, 2, 3}, {1,2, 3}, {1,2, 3}, ....} assert( A1D[0] == {1, 2, 3} ); assert( A1D[1] == {1, 2, 3} ); ... what is your question? is your question what should A2D.size() return? > Also how do you handle incompatible broadcasting without exception - > for example if b in the example above was of shape (2,5,3) and not > (2,5,1) > The "raw" broadcast operation in the library is an operation that cannot fail. It is how the user of the broadcasted object uses it what can create problems down the road if he doesn't know what he/she is doing. The user may choose algorithms that throw when sizes are incompatible, or just assert or just continue. Who am I to choose for them? (I do it in a certain way in the BLAS adaptor but that is a completely different story). > Exceptions are useful. And claiming that you don't throw ones means > you don't use new... > Exceptions are great, that doesn't mean that every library should be throwing exceptions. And you are completely correct: the library doesn't use `new`. (I couldn't, even if I wanted since the arrays should work in especial memory too). The user of the library provides the allocator, the library itself doesn't throw. At most, it is the allocation (or element assignment) what can throw and I don't have control over that because it is an arbitrary element type and the library will handle it well. > I highly doubt the practicality of the library in the current form. > While generic multi-array can be nice to have, but actually it is > stuck at being little bit more that MultiArray > but too far even from basic numpy. > Thank you for your assessment. I think you don't agree with the scope of the library, which would be fine. May be you also think that the scope of the library is more than what I state, which is something I would like to clarify in some way. l don't think this is a little more than MultiArray, but it depends on the usage and how much you care about certain things. (there is a column in the table that will help you evaluate the differences). Thank you, Alfredo

3 3

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

Date: Sun, 22 Sep 2024 17:13:07 +0200 > From: Seth <bugs(a)sehe.nl> > Thanks Sehe for the feedback. I answered Artyom in a separate message in the mailing list. > > On Sat, Sep 21, 2024, at 7:10 PM, Artyom Beilis via Boost wrote: > > > > But if you don't provide algorithms, maybe I'd better take a > > library/framework that does. > Perhaps. > This is the eternal discussion of frameworks vs generic components. > > But, you making numpy-like library... otherwise you wouldn't be > > interfacing cblas. > > A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of > all the features you're missing here you decry "At least show ways to > interoperate with existing thirdparty libraries". Now, they went and did > that (if I'm not mistaken, clearly marked as an extension that might not > even be part of the proposed library), and you decry that. There's no > winning. > I couldn't have said it better myself. > > It [OpenCV] ain't perfect by any means. But it works, well debugged, > understood > > and is a widely available library that does the job. > > It's also a pretty heavy dependency, especially if you didn't need all the > other stuff, and appears to be an example of an intrusive framework (for > good reason, IFF you need the rest) > Right, comparing a framework with a generic component is a waste of time. One has to look at how things inside and "outside" the framework compare, and how the code scales after that. This takes a lot of time and effort and will keep boiling down to frameworks vs generic component. I will say "you can sort with std::sort a 2D array" and the other person will answer either that a) "he/she doesn't need to do that" or b) that "he/she can ask the developer of the framework to implement .sort_by_row and .sort_by_col`" or c) that "he/she can take the pointer to the data structure and do it himself". It is a never ending argument. > > Exceptions are useful. And claiming that you don't throw ones means > > you don't use new... > > Many things don't require allocation. Meanwhile `new(std::nothrow)` has > existed since c++11. > It is more general than that, the library tries to gives some guarantees for exceptions that happen during allocation or element copy/assignments. The library itself doesn't throw exceptions during these operations, but it handles the ones that the elements operations or allocators produce, if it needs to, Thank you all for you feedback, Alfredo

2 1

Re: [boost] Boost Digest, Vol 7345, Issue 1
by Alfredo Correa 25 Sep '24

25 Sep '24

Hi Artyom, Thank you for you for noticing the proposal and the feedback. > It can be excellent to have something like standard MD arrays like numpy is > today for python, but... > yes, this is one of the goals. > 1. You haven't mentioned even once OpenCV which today is the de-facto > standard for numerical computing in today's C++ world. I do scientific computing with large arrays, and nobody uses OpenCV. It would be fair if you had said that it is the de facto standard for image processing, which I don't do. Second, Multi is not a numerical library specifically; it is about the logic and semantics of multidimensional arrays and containers, regardless of the element type. Having said that, the library should still be very performant with numerical data, and for that, I delegate that responsibility to the algorithms it uses behind the scenes, which are very customizable. Unfortunately, people read "arrays" immediately jump to "numerics" and "linear algebra". >From the introduction "The library's primary concern is with the storage and logic structure of data; it doesn't make algebraic or geometric assumptions about the arrays and their elements. (It is still a good building block for implementing mathematical algorithms, such as representing algebraic dense matrices in the 2D case.) In this sense, it is instead a building block to implement algorithms to represent mathematical operations, specifically on numeric data." > While it isn't > perfect - it actually has similar features in terms of array layout - and > what is more important it has a library of high performance algorithms to > process the data. You must talk at least about interoperability between > cv::Mat and this library > Multi is not an algorithms library, but it carefully plays with existing algorithms and facilitates as much as possible to interface with many numerical libraries. > 2. While actual ndarry handling is nice, it is basically a tip of an > iceberg. You need a decent set of high performance algo combined with it. > There is a clear separation of concerns here. The Multi library deals with the data structure, it uses when it needs to fulfill its semantics, the best *existing* algorithms it can in awareness of the datastructure. The Multi library doesn't provide algorithms, it uses the algorithms that are provided to it via different mechanisms. > > Looks like there is a basic BLAS but the typical library has way-way more > to make it useful. > This is an add-on that is separate from the main library. I cannot even guarantee that it will ship with the proposed version of the library. What do you mean by the "typical library" in "the typical library has way-way more to make it useful"? I agree, promising all linear algebra is infinite work, like reimplenting MATLAB or Mathematica, but BLAS has a finite number of functions. The philosophy of the BLAS-adaptor in particular (again, an optional component) is to interface to what BLAS offers and not more. It is more of a model how to interface a legacy library using the features of Multi. > I looked over the code and didn't find include to cblas... Did I miss > something? Also I see request to link cblas/openblas or so. > Yes, you missed that depending on cblas would tie it the application to cblas, not all BLAS implementations can be used through cblas. BLAS is uses through the ABI directly. (basically I have my own version of the cblas header as an implementation detail). Also the BLAS interface is the same for cuBLAS, which is another story. > I did breef look into implementation and it seems to be lacking of > vectorization (use of intrinsics/vector operators) or have I missed? > You missed that this is a generic, not specifically numerical, library. The other thing to take into account is that vectorization/parallelization is still provided by the external algorithms the library uses internally. For example, then dealing with GPU or OpenMP arrays, the library uses thrust algorithms if they are available, which are parallel. vectorization is use by passing execution policies, or whatever mechanism the underlying algorithms use as long as they conform to a certain syntax. (there are some commits coming regarding the passing of execution policies Remember that I don't use many algorithms internally, only those that are necessary to implement the semantics of the array types, assignment, move assignment, construction and destruction. The rest of the operations generate views mostly, so they don't involve computation or algorithms. For the rest, as a user, you have to use algorithms, and I can help if you find that algorithms do not perform as you expect. > 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and > even uBlas (I know it isn't good) > Multi is for multidimensional arrays, not specifically 2D numerical arrays (i.e. matrices). I would be interested in improving the code if someone claims that operations in these libraries are better performant. I wouldn't want the documentation to be a comparison with so many libraries to which there is just very partial overlap. Specially I don't like to compare with frameworks that lock you in into using their own facilities. I consider that Eigen, OpenCV, Kokkos, PETSc are frameworks. Eigen is listed in one column comparing to other libraries. https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… I don't fill confident adding an OpenCV column because I don't have experience with it, but feel free to help me adding a library and answering the points of each row in the comparison table. 4. If you do implement many high performance algorithms this library by any > means shouldn't be header only. > I don't implement any high performance algorithms here, I just give the possibility to interface with them and use them internally when needed to fulfill the semantics of a container. > What is not clear to me is why should I use one over some existing solution > like OpenCV? > - Because sometimes your elements are not numerical types. - Because sometimes you want to specify your element types as template parameters not as OpenCV encoded types. - Because sometimes you want arbitrary dimensionality (e.g. 2D, 3D, 6D) to be compile-time. - Because sometimes you want to apply generic algorithms to your arrays (STL, std::sort, std::rotate, std::ranges, boost::algorithms, serialization) - Because sometimes you want to implement function that are oblivious to the actual dimension or your array (e.g. simultaneously view a 3D array of elements as a 2D array of something, for abstraction). - Because sometimes you want to control allocations, use fancy pointers, parameterized memory strategies, polymorphic allocators, - Because sometimes you want precise value semantics - Because sometimes you want to give guarantees in the presence of exceptions (the library doesn't throw exceptions, to be clear). - Because sometimes you want to work with subblocks of an array in the same way to need you work with the whole array. Thanks, Alfredo

4 7

Re: [boost] [Multi] Proposal
by Alfredo Correa 25 Sep '24

25 Sep '24

> > > > Date: Sun, 22 Sep 2024 17:30:04 +0100 > From: John Maddock <jz.maddock(a)googlemail.com> > To: Seth via Boost <boost(a)lists.boost.org> > > >> But, you making numpy-like library... otherwise you wouldn't be > >> interfacing cblas. > > A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of > all the features you're missing here you decry "At least show ways to > interoperate with existing thirdparty libraries". Now, they went and did > that (if I'm not mistaken, clearly marked as an extension that might not > even be part of the proposed library), and you decry that. There's no > winning. > > +1, I've only been lurking in this conversation, but it seems to me that > trying to compete with low level and highly optimized BLAS libraries is > a fools errand. > I completely agree, I am not even going to try to include vectorized operations inside this library, even as a specialized cases But I will do anything I can for people to be able to exploit them when possible through algorithms and execution policies. At most what I am doing is to interface with BLAS the best I can with some features that are unique to the library in what personally I think is a fairly original way. (capturing a functional-programming interface). Other *numerical* libraries went that way and that is commendable. Thank all for the feedback, Alfredo

1 0

Asset Stewardship Review
by Arnaud Becheler 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets to it and to form a new Steering Committee. I have been using Boost for almost a decade now for my science project, and had some interactions with its community. - My first interaction with the Boost mailing list was to evaluate whether my small science library might be a suitable proposal. The response was pretty clear: no. Boost was seen as too large, and my project too niche (plus, I assume there might have been some quality concerns as well). While I understood the rationale, it did discourage me from further participation in the mailing list. After all, if my project couldn’t be part of Boost, what was the point of staying engaged and spammed ? This experience might help explain at least one data point in the chart from the Alliance proposal, which highlights the mailing list’s decline in participation. - On the other hand, I was still actively using Boost and seeking a community. I was pleasantly surprised by how welcoming the community was to beginners, especially on the Cpplang Slack channel. As a gay person who enjoys sprinkling my Slack posts with rainbow kitties, I never felt ostracized or discriminated against, nor did I witness any bullying. It seems like the community self-regulates quite well, without an apparent need for the enforcement mechanisms proposed by the Foundation. - More significantly, I only became aware of the Foundation through these proposals. I've never had the chance to interact with any of its members, except for Peter, which makes me a bit skeptical of their motivations. In contrast, members of the C++ Alliance—like Vinnie, Rene, and Joaquin—have been consistently accessible and supportive on the Boost channel of the Cpplang Slack. - The quality of the proposal documents is worth noting: the C++ Alliance’s proposal is highly detailed, well-illustrated, and presents a long-term vision that reignited my enthusiasm for the community. In contrast, the Foundation’s proposal felt more like a brief but reassuring affirmation of the importance of our long-held open-source values, without sparking the same level of excitement. Additionally, members of the C++ Alliance were readily available for real-time discussions and debates about their proposal, whereas members of the Foundation were less/not present and communicative on the platforms I personally use. - I believe in values, principles—and results. I can highlight the success of the C++ Alliance with two personal stories. (i) Recently, a colleague mentioned that Boost was outdated and irrelevant. I disagreed and showed them the new website developed by the C++ Alliance. They quickly changed their mind. (ii) Similarly, a colleague who had switched to Rust was convinced C++ was obsolete due to well-known C++ vs. Rust issues. They even compiled a bullet-point list to persuade others to move away from C++. I showed them the C++ Alliance’s Safe C++ initiative in partnership with Sean Baxter. After reading it, they came back excited, saying the proposal addressed every point on their list and could be a game-changer. Unfortunately, I don’t have comparable stories about the Foundation. - As several reviewers have pointed out, there are shared goals and ideologies at the core of the conflict. The community must embrace these common values and reinforce the collaborative spirit that Boost was built on, ensuring the focus remains on innovation and mutual progress rather than division. Continuing down this path of personal conflict only detracts from the mission, diluting the collective potential of the project. It’s essential that we return to a focus on the project's true objectives—technical excellence, inclusivity, and shared success. By prioritizing cooperation and mutual respect, we can ensure that Boost remains a thriving environment for growth. I personally take home these points from the two proposals: - *Foundation Proposal:* - Uphold core values of the open-source community (openness, collaboration, inclusivity). - Push for immediate inclusivity. - Concerned that financial involvement may compromise the project’s integrity. - Recognizes the importance of not becoming too distanced from the community. - Move slowly, but surely, and freely. - *C++ Alliance Proposal:* - Leverage funding to handle unappealing yet necessary tasks. - Focus on modernizing and appealing to younger developers. - Aim to keep the project relevant and attractive to new talent. - Want to maintain a close relationship with developers. - Move fast and throw money at problems. - *Conclusion:* - Both the C++ Alliance and the Foundation share aligned values but focus on different approaches. - They are complementary, addressing different aspects of the same mission. - Their coexistence can provide a balance, acting as counterweights to maintain both ethical standards and practical sustainability. - Transferring assets to the C++ Alliance would enable them to fulfill their part of the mission more quickly. I don't believe it would impede the Foundation's ability to achieve their goals. - The next question for the community is: how can we support the Foundation in return? For example, a reasonably-sized data science project to collect insights on inclusivity and diversity within the Boost community could help them shape future initiatives around the values they prioritize, and would benefit the entire community. Thank you once again for giving us the chance to review these great documents and visions, and for the hard work from all sides that has allowed me to develop my little science project while standing on the towering shoulders of giants ;) Best, Arno

4 3

CODE_OF_CONDUCT.adoc
by Vinnie Falco 23 Sep '24

23 Sep '24

The subject of a code of conduct has come up a few times, and I think it is worth having a discussion. I hope that everyone will find the following statements uncontroversial: 1. Social spaces have rules, either stated or implied 2. Rules need to state clearly what is allowed and what is disallowed, so that people who may be interested in joining can determine if the culture is the right fit. 3. Rules need to be enforced 4. The Boost mailing lists already have rules 5. The rules for the mailing list are outdated 6. The rules for the mailing list are not particularly visible There is value in refreshing the rules for the Boost mailing list, which are currently described here: https://www.boost.org/community/policy.html I think we should do the following: * Update the rules to be relevant for 2024 * Make the rules visible on the sign-up and administration page for the mailing lists (at https://lists.boost.org) * Consider renaming the rules to something other than "Boost Discussion Policy" * Send a periodic announcement to the mailing lists reminding everyone of the rules. These could be timed to coincide with the releases (three times per year) The community needs to discuss the things above and come to a consensus. And we need to make a final decision on what the changes will look like given the feedback. I don't know that the review process is right for this, because it will likely be an iterative process where we all work on a "shared document" to make edits. The nice thing is that we don't need to wait for the outcome of the Boost Asset Stewardship review to do this, because the content of the website and mailing lists is not controlled by the Boost Foundation, the C++ Alliance, or the proposed Steering Committee. And even before the need to decide which revision of the updated rules will be accepted by the project, discussion can take place with no governing body. There is one hiccup though. Where do we discuss this? The mailing list is one possibility. However, anyone who joins the mailing list late, or is not a member of the mailing list, has the problem that the visibility of the discussion is not very great. They would have to use the archives, and the archives are not very pleasant. One cannot see the entire discussion as a single page. And if someone changes the subject, then new related threads of conversation become more difficult to find. And at the end of the day, our workflow requires GitHub issues to triage and assign work items to staff. Therefore, here is a GitHub issue for this. Everyone can feel free to participate in a discussion there. Alternatively, if you feel that the mailing list is a better place, then reply to this post and have a discussion here. There might be two discussions. Or one. Or none (hopefully not). And when we are done we can compare the pros and cons of GItHub issues versus the mailing list. There could be value here. This is the issue: https://github.com/boostorg/website-v2/issues/1269 What do you think? Thanks

3 4

Asset Stewardship Review
by Adam C Getchell 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets and form a new Steering Committee. I’ve been a downstream user of Boost for more than a decade for my research project, and joined the mailing list to get help on using the project effectively. My initial interactions were to sort out build errors, which were mostly resolved with the adoption of vcpkg (after trying biicode and then Conan) and the work on making Boost compatible with CMake. I have appreciated the C++ Alliance’s sponsorship of tools such as the Slack workspace and CI, and I believe this is necessary to ensure progress. I also learned a lot reading the documentation and code of Louis Dionne’s Boost.Hana and Vinnie Falco’s Boost.Beast. As a side note, my research involves writing low-level simulations of the universe, and unfortunately the various memory errors and other bugs have convinced me to go reluctantly down the path of using Rust to write low-level memory-safe abstractions that I can count on to run for months at a time without segfaults or other issues that compromise the validity of the data. Thus, Circle and the recent Safe C++ proposal are very interesting to me, and if they are ever adopted I might back port them to my current codebase. However, this probably won’t be effective until the libraries I depend on make similar efforts. By then, I will probably have everything I need written in Rust. -- Adam Getchell https://adamgetchell.org <https://adamgetchell.org/>

1 0

Boost.LEAF in Embedded Systems (CppCon)
by Vinnie Falco 23 Sep '24

23 Sep '24

At CppCon 2024 the C++ Alliance sponsored a program to interview conference goers about Boost-related topics. This is the first video in the series: Boost.LEAF in Embedded Systems: Insights from Ex-Google Engineer Khalil Estelle at CppCon https://www.youtube.com/shorts/BksBxnTLltY Enjoy! Thanks

1 0

Boost Asset Stewardship Review begins today (3rd Sept)
by Glen Fernandes 22 Sep '24

22 Sep '24

Dear Boost community, The Boost Asset Stewardship Review begins today, 3rd September and ends on 22nd September. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The submission which initiated the review is the following proposal from the C++ Alliance: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf It proposes a Fiscal Sponsorship which: 1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used. 2) donates the assets that it funds to the Boost project (domains, hosting, etc.) The "Boost developer community" here refers to: - Boost library authors - Boost library contributors - Boost release managers For a high level overview of these terms (which I needed) see the following email with definitions: https://lists.boost.org/Archives/boost/2024/09/257579.php The Boost Foundation asks the Boost developer community to consider the following alternative: https://docs.google.com/document/d/1XFt7Bh71e4_uE0iK4jifhR__P0iG5_c1cDfBsMj… The Boost Foundation proposal presents a path forward where it continues to be the steward the assets in question, but offers a change in how these are managed. The assets here refer to the following: - The boost.org domain - Website hosting - Mailing lists - Downloads storage and CDN - Drone CI Currently, the Boost Foundation owns and pays for the following: - Website hosting - Mailing lists The C++ Alliance pays and manages for the following: - The Drone CI - The CDN for the downloads - The download archive - Technical assistance and support for the Boost release process - Backup domain names (in case boost.org expires) - Hosting and downloads for the new website prototype (boost.io) The boost.org domain is absent from both lists above: The Boost Foundation technically does not own it yet. The domain was owned by Beman and he had the credentials. The Boost Foundation is working with Beman's widow and the Dawes Estate to transfer ownership to it. For reference, see Kristen's email: https://lists.boost.org/Archives/boost/2024/08/257563.php Note that the content of the current boost.org site and the new boost.io website is still the province of the Boost developer community. To be clear, the review is not about deciding governance over Boost C++ library development. That remains in the hands of the Boost developer community. Please send all reviews to the Boost developer mailing list. If you do not want to create an account, you can email me at glenfe -at- boost.org with your review and I will post it to the list for you. Include "Asset Stewardship Review" or "Asset Stewardship" in your email subject. In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.) Thank you, Glen

15 26

Boost Asset Stewardship Review concludes 09/22
by Glen Fernandes 21 Sep '24

21 Sep '24

Everyone, Tomorrow (September 22) is the last day to submit a review. To date there have been no requests for an extension. I have received suggestions for potential reviewers I should reach out to, and I believe only one review is forthcoming. Thank you to everyone who has submitted a review, or has otherwise contributed to the discussion. Glen (I was reminded that there are still answers pending from certain members of the Boost Foundation. I understand that CppCon is ongoing and they might not be able to reply yet).

1 0

Re: [boost] Boost Digest, Vol 7346, Issue 1
by Alfredo Correa 20 Sep '24

20 Sep '24

Hi Seth, On Fri, Sep 20, 2024 at 5:00 AM <boost-request(a)lists.boost.org> wrote: > > Date: Thu, 19 Sep 2024 16:28:28 +0200 > From: Seth <bugs(a)sehe.nl> > > On Thu, Sep 19, 2024, at 1:13 PM, Artyom Beilis via Boost wrote: > > 1. You haven't mentioned even once OpenCV > > [...] > > 4. If you do implement many high performance algorithms this library by > any > > means shouldn't be header only. > > > > What is not clear to me is why should I use one over some existing > solution > > like OpenCV? > > All of the points raised are actually a single one, and seem to > misunderstand the scope of the library? I suppose it should be seen as a > successor to Boost MultiArray, leveraging modern language features and > side-stepping some of the pitfalls. > yes, exactly. You seem to understand exactly what I am talking about. (Also a big fan of your Stackoverflow answers). I just gave a long answer to Artyom's message in the list. > That's not at all useless, and interop examples would be very valuable. > However, not all code needs vectorization (beyond what the compiler will > automatically do). I'm more interested in the relation to > https://en.cppreference.com/w/cpp/container/mdspan - which seems to fill > the same space: building block for flexibly indexed contiguous storage. > >From this section: https://gitlab.com/correaa/boost-multi#substitutability-with-standard-vecto… "Multi-dimensinal arrays can interoperate with C++23's non-owning mdspan. Preliminarily, Multi's subarrays (arrays) can be converted (viewed as) mdspan." https://godbolt.org/z/aWW3vzfPj Also see https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… Thank you, Alfredo

1 0

Video on Boost.Cobalt available
by Richard 20 Sep '24

20 Sep '24

Utah C++ Programmers has released a video on the Boost.Cobalt coroutines library: Using Coroutines with Boost.Cobalt <https://www.youtube.com/watch?v=yElSdUqEvME> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

2 1

Asset Stewardship Review
by Phil Endecott 19 Sep '24

19 Sep '24

I've been a Boost user and subscriber to this mailing list for most of this century, but I'm not a library author. It's tempting to write a long navel-gazing essay about the history of Boost and what it needs to do to remain vital, and then to pretend to forensically study the competing proposals to determine which will give the best result in the longer term. But in this post I'll try to be more honest: isn't this review more like a referendum on whose side we favour in the Vinnie Falco vs. David Sankel clash of personalities? Somehow we've reached a point where "this town ain't big enough for the two of them" and we're being asked to choose who to exile. What do I think about the Boost Foundation? I have always been mystified by why the Foundation, and the Steering Committee before them, have interacted so little with the list. The most extraordinary example of this was that the very establishment of the Foundation was not announced to the developers! Periodic, brief updates on Foundation activities to the mailing list would not have taken much effort could even have resulted in more offers of help. The foundation's present proposal starts by talking about "Transparency"; perhaps they would be more transparent in the future, but that would be a departure from how they have worked in the past. Regarding Vinnie and his C++ Alliance, I've not had a very positive view of them since he posted this back in 2023: "Something which should not surprise anyone is that I despise paying taxes." This statement is repeated in his current proposal. Personally, I'm proud of the tax that my business and I pay as it funds education, health, pensions and other public services that make my community a better place in which to live. In the world I inhabit, this is a mainstream view. It's one thing to despise paying taxes, but I think it's quite another to tell everyone that and assume that they share the same view. When I read that the boost.io domain for the "temporary" website had cost $135,000, my reaction was that you could feed a lot of hungry children with that sort of money. My conclusion is, "a plague on both your houses". I fear that Boost is doomed. This review will result in Vinnie's hostile takeover succeeding, but eventually he'll lose interest - maybe when the "young developers" that he hopes to attract don't materialise, or maybe after another falling-out with someone else. Then the project will sink. I think this is the right time for me to unsubscribe from this list; being here doesn't help me, and my contributions don't seem to help anyone else. I extend my best wishes and thanks to all those whose libraries I have used over the years. Regards, Phil.

6 5

Re: [boost] proposal Multi multidimensional array library
by Artyom Beilis 19 Sep '24

19 Sep '24

Hi, Only now have I noticed this proposal, and here are some of my thoughts. It can be excellent to have something like standard MD arrays like numpy is today for python, but... 1. You haven't mentioned even once OpenCV which today is the de-facto standard for numerical computing in today's C++ world. While it isn't perfect - it actually has similar features in terms of array layout - and what is more important it has a library of high performance algorithms to process the data. You must talk at least about interoperability between cv::Mat and this library 2. While actual ndarry handling is nice, it is basically a tip of an iceberg. You need a decent set of high performance algo combined with it. Looks like there is a basic BLAS but the typical library has way-way more to make it useful. I looked over the code and didn't find include to cblas... Did I miss something? Also I see request to link cblas/openblas or so. I did breef look into implementation and it seems to be lacking of vectorization (use of intrinsics/vector operators) or have I missed? 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and even uBlas (I know it isn't good) 4. If you do implement many high performance algorithms this library by any means shouldn't be header only. What is not clear to me is why should I use one over some existing solution like OpenCV? Artyom On Thu, Apr 27, 2023 at 12:30 AM Alfredo Correa via Boost < boost(a)lists.boost.org> wrote: > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > >

2 1