- Boost-users - lists.boost.org

TypeTraits
by Gero Peterhoff 27 Dec '21

27 Dec '21

Hello John, Some time ago I asked whether further type traits would be included in boost. Unfortunately that somehow fizzled out. Because based on this, many useful functions and classes can first be defined that behave correctly. But the problems are much deeper and I would like to show a solution here. 1) For some types there are feature-tesing-macros (e.g. __cpp_char8_t, __cpp_unicode_characters), but not for most. So this is incomplete. So we need this (plus the __cpp_lib-macros): - __cpp_char8/16/32_t, __cpp charw_t, __cpp_char_t - __cpp_int8/16/32/64/128_t - __cpp_float16/32/64/80/128_t, __cpp_float16b_t - __cpp_bool_t 2) Building on this, we can then query, e.g. struct has_float80: bool_constant < #if defined (__cpp_float80_t) true #else false #endif > {}; template <typename Type> struct is_float80: bool_constant < #if defined (__cpp_float80_t) is_same_v<Type, float80> #else false #endif > {}; This has to be done for all types. 3) Then we can further classify; plus is_X_v and concepts: character: template <typename Type> struct is_character: bool_constant < #if defined (__cpp_char32_t) is_same_v<Type, char32_t> || #elif defined (__cpp_char16_t) is_same_v<Type, char16_t> || #elif defined (__cpp_char8_t) is_same_v<Type, char8_t> || #elif defined (__cpp_charw_t) is_same_v<Type, wchar_t> || #endif is_same_v<Type, char> > {}; template <typename Type> struct is_unsigned_character: bool_constant < is_unsigned_v<Type> && character_v<Type> > {}; template <typename Type> is_signed_character: bool_constant < is_signed_v<Type> && character_v<Type> > {}; float: template <typename Type> struct is_floating_point: bool_constant < #if defined (__cpp_float128_t) is_same_v<Type, float128_t> || #elif defined (__cpp_float80_t) is_same_v<Type, float80_t> || #elif defined (__cpp_float64_t) is_same_v<Type, float64_t> || #elif defined (__cpp_float32_t) is_same_v<Type, float32_t> || #elif defined (__cpp_float16b_t) is_same_v<Type, float16b_t> || #elif defined (__cpp_float16_t) is_same_v<Type, float16_t> || #endif false > {}; integer: template <typename Type> struct is_unsigned_integer: bool_constant < #if defined (__cpp_int128_t) is_same_v<Type, uint128_t> || #elif defined (__cpp_int64_t) is_same_v<Type, uint64_t> || #elif defined (__cpp_int32_t) is_same_v<Type, uint32_t> || #elif defined (__cpp_int16_t) is_same_v<Type, uint16_t> || #elif defined (__cpp_int8_t) is_same_v<Type, uint8_t> || #endif false > {}; template <typename Type> struct is_signed_integer: bool_constant < #if defined (__cpp_int128_t) is_same_v<Type, int128_t> || #elif defined (__cpp_int64_t) is_same_v<Type, int64_t> || #elif defined (__cpp_int32_t) is_same_v<Type, int32_t> || #elif defined (__cpp_int16_t) is_same_v<Type, int16_t> || #elif defined (__cpp_int8_t) is_same_v<Type, int8_t> || #endif false > {}; template <typename Type> struct is_integer: bool_constant < is_unsigned_integer_v<Type> || is_signed_integer_v<Type> > {}; logic: template <typename Type> struct is_logic: bool_constant < is_same_v<Type, bool> > {}; With that we would have created the basics to be able to continue working properly at all. 4) 3 more steps to make things easier #define bitsof(ARG) (size_t(sizeof(ARG) * CHAR_BIT)) Like std::numbers with std::strings with various constantans namespace strings { constexpr static auto empty = ""; constexpr static auto nullptr = "nullptr"; constexpr static auto Void = "void"; constexpr static auto True = "true"; constexpr static auto False = "false"; constexpr static auto indeterminate = "indeterminate"; constexpr static auto overdeterminate = "overdeterminate"; constexpr static auto underdeterminate = "underdeterminate"; constexpr static auto bin = "bin"; constexpr static auto oct = "oct"; constexpr static auto dec = "dec"; constexpr static auto hex = "hex"; constexpr static auto literal_bin = "0b"; constexpr static auto literal_oct = "0o"; constexpr static auto literal_dec = "0d"; constexpr static auto literal_hex = "0x"; } and more and for streams so that you don't have to fumble with the flags namespace detail { using format_flags_t = typename std::ios_base::fmtflags; static inline constexpr format_flags_t defaultfloat = format_flags_t{}, hexfloat = std::ios_base::fixed | std::ios_base::scientific; inline format_flags_t get_flags (const std::ios_base & stream, const format_flags_t & fieldmask) noexcept { return stream.flags () & fieldmask; } } // detail inline bool is_boolalpha (const std::ios_base & stream) noexcept {return (stream.flags () & stream.boolalpha) == stream.boolalpha; } inline bool is_showbase (const std::ios_base & stream) noexcept {return (stream.flags () & stream.showbase) == stream.showbase; } inline bool is_showpoint (const std::ios_base & stream) noexcept {return (stream.flags () & stream.showpoint) == stream.showpoint; } inline bool is_skip (const std::ios_base & stream) noexcept {return (stream.flags () & stream.skipws) == stream.skipws; } inline bool is_uppercase (const std::ios_base & stream) noexcept {return (stream.flags () & stream.uppercase) == stream.uppercase; } inline bool is_lowercase (const std::ios_base & stream) noexcept {return! is_uppercase (stream); } inline bool is_float_bin (const std::ios_base & stream) noexcept {return false; } inline bool is_float_hex (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.floatfield) == detail::hexfloat; } inline bool is_float_fixed (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.floatfield) == stream.fixed; } inline bool is_float_default (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.floatfield) == detail::defaultfloat; } inline bool is_float_scientific (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.floatfield) == stream.scientific; } inline bool is_integer_bin (const std::ios_base & stream) noexcept {return false; } inline bool is_integer_oct (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.basefield) == stream.oct; } inline bool is_integer_dec (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.basefield) == stream.dec; } inline bool is_integer_hex (const std::ios_base & stream) noexcept {return detail::get_flags (stream, stream.basefield) == stream.hex; } 5) And now we can finally get correctly working functions, e.g. template <integer Type, unsigned_integer Bits> inline constexpr Type shl(const Type& arg, const Bits& bits) noexcept { using unsigned_type = make_unsigned_t<Type>; const type res {Type(arg << unsigned_type(bits))}; return (bits < bitsof(Type)) ? res : Type{0}; } template <integer Type, unsigned_integer Bits> inline constexpr Type shr(const Type& arg, const Bits& bits) noexcept { using unsigned_type = make_unsigned_t<Type>; const type ovl {is_signed_integer_v<Type> ? ((arg < Type{0})? Type(-1) : Type{0}) : Type{0}}, res {Type(arg >> unsigned_type(bits))}; return (bits < bitsof(Type)) ? res : ovl; } and classes, e.g. constexpr bool2/3/4 with template <> struct is_logic<bool4>: true_type {}; template <> struct is_logic<bool3>: true_type {}; template <> struct is_logic<bool2>: true_type {}; (I am happy to send it to you, because boost::tribool does not meet the requirements). PS: I could have used the days multi-array/multi-index; but that's done because all of these libs are not constexpr. Will these be updated again? thx Gero

1 0

Boost geometry: 3d difference and union?
by KL 13 Dec '21

13 Dec '21

2 1

Question on boost shared memory allocators
by Da Xu 08 Dec '21

08 Dec '21

Hi folks, got a couple of questions about using shared memory allocators. Please see below. I have the following code template <typename T> using CAP_Alloc = cached_adaptive_pool<T, segment_manager_t>; using CAP_Shmem_String = basic_string<char, std::char_traits<char>, CAP_Alloc<char> >; using CAP_Shmem_String_Alloc = CAP_Alloc<CAP_Shmem_String>; using CAP_Shmem_Void_Alloc = CAP_Alloc<void>; class MyDataBlock{ using pointer = CAP_Shmem_String_Alloc::pointer; pointer strData; float extraData; MyDataBlock(): strData(nullptr), extraData(0.0) {} MyDataBlock(const CAP_Shmem_Void_Alloc& alloc) { /* My question is how do I convert CAP_Shmem_Void_Alloc to type CAP_Shmem_String_Alloc to call allocate? And do I pass in the void allocator as a construction argument? Is there a difference between allocate and construct? */ } ~MyDataBlock() { /* To delete the memory, do I need to keep around a copy of the original allocator, so I can call deallocate or destroy? Or can that be derived or converted from somewhere, like calling strData->alloc() ? */ } } Any help would be greatly appreciated. Thank you.

1 0

[release] Boost 1.78.0
by Marshall Clow 08 Dec '21

08 Dec '21

Release 1.78.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.78.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.78.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse, Glen Fernandes

1 0

[release] Boost 1.78.0 Release Candidate 1
by Marshall Clow 03 Dec '21

03 Dec '21

The first release candidates for the 1.78.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/> The SHA256 checksums are as follows: 94ced8b72956591c4775ae2207a9763d3600b30d9d7446562c552f0a14a63be7 boost_1_78_0_rc1.tar.gz f22143b5528e081123c3c5ed437e92f648fe69748e95fa6e2bd41484e2986cc3 boost_1_78_0_rc1.zip 090cefea470bca990fa3f3ed793d865389426915b37a2a3258524a7258f0790c boost_1_78_0_rc1.7z 8681f175d4bdb26c52222665793eef08490d7758529330f98d3b29dd0735bccc boost_1_78_0_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 3

[Graph] Occasional crash when removing a vertex
by Anne van de Graaf 29 Nov '21

29 Nov '21

Hello all, When I remove a vertex from a graph, I occasionally experience a crash (on a system running Red Hat Enterprise Linux 8.5). I have been able to replicate the behavior with the following test program: #include <boost/graph/adjacency_list.hpp> int main() { using MyGraph = boost::adjacency_list<boost::setS, boost::vecS, boost::undirectedS>; using MyVertexDescriptor = boost::graph_traits<MyGraph>::vertex_descriptor; using MyVertexDescriptorVec = std::vector<MyVertexDescriptor>; MyGraph g; MyVertexDescriptorVec vertices{ boost::add_vertex( g ), boost::add_vertex( g ), boost::add_vertex( g ) }; boost::add_edge( vertices[0], vertices[1], g ); boost::add_edge( vertices[1], vertices[2], g ); boost::clear_vertex( vertices[0], g ); boost::remove_vertex( vertices[0], g ); return 0; } Also on a Windows platform, I observe similar behavior. When I build the above code with Microsoft Visual Studio 2019 (MSVC 14.27.29110) and run it with a debugger, a debug assertion is triggered ("cannot increment value-initialized map/set iterator"). In both cases (on Linux and Windows platforms), the debugger reveals that the problem is at line 2071 of boost/graph/detail/adjacency_list.hpp. For clarity, I have copied the involved template function below: template < class EdgeList, class vertex_descriptor > inline void reindex_edge_list( EdgeList& el, vertex_descriptor u, boost::disallow_parallel_edge_tag) { for (typename EdgeList::iterator ei = el.begin(); ei != el.end(); ++ei) // line 2071: increment operator fails { if (ei->get_target() > u) { typename EdgeList::value_type ce = *ei; el.erase(ce); --ce.get_target(); el.insert(ce); } } } While I was searching for a proper place to post my question, I found the following issue at GitHub (which was opened on July 1 of this year): https://github.com/boostorg/graph/issues/268. This appears to be the exact same issue. So last week, I added a comment saying that I am facing the exact same problem. Unfortunately, so far no one has responded yet. To me, it seems that the problem is well-understood. Also, some have proposed a bug fix to resolve the issue (including a pull request). Nevertheless, no progress has been made over the past months. So I was just wondering what is the best way to proceed if we want to fix the issue in Boost itself? Is there anything that I can do (apart from starting this thread) to help in resolving the issue? Any feedback is greatly appreciated. Kind regards, Anne van de Graaf

1 0

assigning a "float128" variable with a regular "double" variable
by Jacques Mequin 27 Nov '21

27 Nov '21

I am a fresh new user ( I need to extend some EIGEN library feature by using your float128 ) How to assign a "float128" variable with a regular "double" variable ? With my source code in attachement double double_pi = 3.141592653589793 ; float128 float128_pi = 3.141592653589793Q ; produces the output that looks fine to me double_pi = 3.141592653589793e+00 float128_pi = 3.141592653589793000000000000000000e+00 but thestatement float128_pi = double_pi ; produces float128_pi = 3.141592653589793115997963468544185e+00 How to get 3.141592653589793000000000000000000e+00 also from an assigment ??? What am I doing wrong ? Thanks for any help Regards, Jacques

2 2

Fw: How to access global fixture class member
by Ming Cheng 21 Nov '21

21 Nov '21

________________________________ From: Ming Cheng Sent: Thursday, November 18, 2021 6:52 AM To: Boost-interest(a)lists.boost.org <Boost-interest(a)lists.boost.org> Subject: How to access global fixture class member Hi struct Myconfig{ int m_any; }; BOOST_GLOBAL_FIXTURE(Myconfig) How to access m_any?

1 1

boost units and single-precision floats
by Carel Combrink 19 Nov '21

19 Nov '21

Hi, I have aliases for radians and degrees that use float as the storage type. When I convert between these two units I see the assembly promote the values to doubles and then back to floats. How can I make sure that all operations and conversions stay in floats? PS: I would not be surprised if I have defined my aliases or/and my conversion functions incorrectly. My Code: === using radians_f = boost::units::quantity<boost::units::si::plane_angle, float>; using degrees_f = boost::units::quantity<boost::units::degree::plane_angle, float>; degrees_f to_degrees(const radians_f& angle) { return static_cast<degrees_f>(angle); } radians_f to_radians(const degrees_f& angle) { return static_cast<radians_f>(angle); } === >From compiler explorer I see the following assembly instructions: https://godbolt.org/z/Gnjr54dn6 cvtss2sd - Converts a single-precision floating-point value in the “convert-from” source operand to a double-precision floating-point value in the destination operand. mulsd - Multiplies the low double-precision floating-point value in the second source operand by the low double-precision floating-point value in the first source operand. cvtsd2ss - Converts a double-precision floating-point value in the “convert-from” source operand to a single-precision floating-point value Any help will be appreciated. Regards, Carel

1 0

Using Boost Compute with ArrayFire
by Muhammad Hassan Khan 17 Nov '21

17 Nov '21

Hi, I am trying to run a code which uses functions from both boost compute library and arrayfire library. I am getting the following errors when I try to build the code: Scanning dependencies of target hello [ 50%] Building CXX object CMakeFiles/hello.dir/hello.cpp.o In file included from /opt/arrayfire/include/CL/cl.h:32, from /usr/include/boost/compute/cl.hpp:19, from /usr/include/boost/compute/system.hpp:20, from /usr/include/boost/compute/algorithm/accumulate.hpp:17, from /usr/include/boost/compute/algorithm.hpp:18, from /usr/include/boost/compute.hpp:14, from /home/rcms/debruijn/arrayfire/hello.cpp:2: /opt/arrayfire/include/CL/cl_version.h:34:104: note: #pragma message: cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2) 34 | #pragma message("cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)") | ^ [100%] Linking CXX executable hello /usr/bin/ld: CMakeFiles/hello.dir/hello.cpp.o: undefined reference to symbol 'clGetDeviceIDs@@OPENCL_1.0' /usr/bin/ld: /opt/arrayfire/lib64/libOpenCL.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/hello.dir/build.make:85: hello] Error 1 make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/hello.dir/all] Error 2 make: *** [Makefile:84: all] Error 2 The code I am using is a very simple helloworld using functions from both libraries. #include <iostream> #include <boost/compute.hpp> #include <arrayfire.h> namespace compute = boost::compute; using namespace af; int main() { // Boost Compute Part // get the default device compute::device device = compute::system::default_device(); // print the device's name and platform std::cout << "hello from " << device.name(); std::cout << " (platform: " << device.platform().name() << ")" << std::endl; // Array Fire Part std::cout<< "ArrayFire Part:" << std::endl; af::setDevice(0); af::info(); return 0; } The CMakeList used to build the project is: cmake_minimum_required(VERSION 3.0) project(deBruijn_Graph) find_package(ArrayFire) add_executable(hello hello.cpp) target_link_libraries(hello ArrayFire::afopencl) I do not have a programming background. Please guide me on what I am doing wrong. Regards, Hassan <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0