April 2023 - Boost - lists.preview.boost.org

Re: [boost] ccmath implementations
by John Maddock 21 Apr '23

21 Apr '23

On 21/04/2023 15:05, Gero Peterhoff via Boost wrote: > Hi Matt, > the ccmath functions must/could only work with std types. Is this > assumption correct? > The constexpr code path is almost certainly for std types only. However, they can be used in generic functions declared constexpr, which are not necessarily used in a constexpr context: in that case the argument could be any suitable type. John.

1 0

ccmath::copysign/signbit
by Gero Peterhoff 20 Apr '23

20 Apr '23

Hi Matt, I see the following problems in your implementations for ccmath::copysign/signbit: 1) copysign uses abs, which is wrong. copysign/signbit may *only* change/check the sign (https://en.cppreference.com/w/cpp/numeric/math/copysign https://en.cppreference.com/w/cpp/numeric/math/signbit) 2) In signbit.hpp you implement struct IEEEfN2bits. But these are incomplete: - long double can be 16/12/10 bytes depending on platform/compiler option. You do not take this into account. - Correct types are already available in boost/math/cstdfloat/cstdfloat_types.hpp. Therefore, I provide the complete structures in ccmath/bits.hpp. This also contains structures for std::(b)float16_t and can be extended if needed. Extended type-traits for floats To minimize completely sprawling manual checks (#if + std::is_same) I provide more advanced TTs in type_traits/is_floating_point_more.hpp. This way ccmath::copysign/signbit can be implemented correctly. Possibly other functions are affected. thx Gero PS gcc13 is about to be released (https://gcc.gnu.org) so it is high time to support std::floatN_t as well.

1 0

ccmath implementations
by Gero Peterhoff 20 Apr '23

20 Apr '23

Hi Matt, the ccmath functions must/could only work with std types. Is this assumption correct? If true: Wouldn't it make sense to do such a check for CT? This way errors can be detected early and it generally simplifies error handling. namespace boost::math::ccmath { namespace detail { template <typename type> inline constexpr auto foo_impl(const Type x) noexcept { return x; } } // detail template <typename Type> constexpr auto foo(const Type x) noexcept { BOOST_IF_CONSTEXPR (std::is_arithmetic_v<Type>) { if (BOOST_MATH_IS_CONSTANT_EVALUATED(x)) { BOOST_IF_CONSTEXPR (std::is_integral_v<Type>) { return detail::foo_impl(double(x)); } else { return detail::foo_impl(x); } } else { using ::std::foo; return foo(x); } } else { static_assert(boost::dependent_false_v<Type>, "foo is not supported with this type or platform"); return 0; } } } // boost::math::ccmath 1) In particular, this approach is useful for functions that require BOOST_MATH_BIT_CAST in their implementation. To be honest, I don't like your implementations of signbit/copysign (buggy) - I'll write you something more on that. 2) The idiom "always false" (dependent_false) guarantees that static_assert is only used for Type!=is_arithmetic. cu Gero

1 0

Re: [boost] Master is open for merges
by Vinnie Falco 19 Apr '23

19 Apr '23

On Sat, Apr 15, 2023 at 7:37 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > Next milestone: June 21 Boost 1.83.0 closed for new libraries and breaking changes Are we going to do a bugfix update for the overly aggressive inline function issue? Thanks

1 0

Re: [boost] using boost::multiprecision functions
by Seth 19 Apr '23

19 Apr '23

This is what ADL (argument dependent lookup) is for: https://en.cppreference.com/w/cpp/language/adl See e.g. https://compiler-explorer.com/z/oej1ehhnY template <typename T> T foo(T x) { using std::sin; return sin(x) * 42; } int main() { using A = double; using B = boost::multiprecision::cpp_bin_float_oct; A a = foo(A(23)); // ok B b = foo(B(23)); // ok std::cout << std::setprecision(32); std::cout << "a: " << a << "\n"; std::cout << "b: " << b << "\n"; using std::abs; std::cout << "|b-a|: " << abs(b-a) << "\n"; } As you'd expect, b is more precise than a: a: -35.541256975357164549222943605855 b: -35.541256975357166680135703420035 |b-a|: 2.1309127598141799216575314028644e-15 Seth On Sun, Apr 16, 2023, at 9:02 PM, Gero Peterhoff via Boost wrote: > Hello John, > * problem description > The functions of boost::multiprecision are not available in std, e.g. > template <typename type> > Type foo(const Type x) noexcept > { > return std::sin(x) * 42; > } > > using A = double; > A a = foo(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = foo(B(23)); // error > > > > As a workaround you currently have to write > template <typename Type> > Type bar(const Type x) noexcept > { > using ::std::sin; > using ::boost::multiprecision::sin; > return sin(x) * 42; > } > > using A = double; > A a = bar(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = bar(B(23)); // ok > > > This contradicts the template idea and is time-consuming/error-prone. > > > thx > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > Attachments: > * OpenPGP_signature

1 0

Re: [boost] Typo in Mysql URL on release page
by Ruben Perez 18 Apr '23

18 Apr '23

Hi Tim, Thanks for reporting! That's now fixed. Regards, Ruben. On Fri, 14 Apr 2023 at 21:27, Tim Haines via Boost <boost(a)lists.boost.org> wrote: > > The link to Mysql on the release page ( > https://www.boost.org/users/history/version_1_82_0.html) points to > > https://www.boost.org/doc/libs/1_82_0/libs/msyql/ > ^^ > > Thanks. > - Tim > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] using boost::multiprecision functions
by John Maddock 17 Apr '23

17 Apr '23

On 16/04/2023 19:52, Gero Peterhoff via Boost wrote: > Hello John, > * problem description > The functions of boost::multiprecision are not available in std, e.g. > template <typename type> > Type foo(const Type x) noexcept > { > return std::sin(x) * 42; > } > > using A = double; > A a = foo(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = foo(B(23)); // error > > > > As a workaround you currently have to write > template <typename Type> > Type bar(const Type x) noexcept > { > using ::std::sin; > using ::boost::multiprecision::sin; > return sin(x) * 42; > } > > using A = double; > A a = bar(A(23)); // ok > > using B = boost::multiprecision::cpp_bin_float_oct; > B b = bar(B(23)); // ok > > > This contradicts the template idea and is time-consuming/error-prone. > We are not allowed to overload anything in namespace std, so the correct incantation for any generic code is: template <typename Type> Type bar(const Type x) // cannot be noexcept if used in multiprecision case { using ::std::sin; return sin(x) * 42; // potentially found via ADL } John.

1 0

using boost::multiprecision functions
by Gero Peterhoff 16 Apr '23

16 Apr '23

Hello John, * problem description The functions of boost::multiprecision are not available in std, e.g. template <typename type> Type foo(const Type x) noexcept { return std::sin(x) * 42; } using A = double; A a = foo(A(23)); // ok using B = boost::multiprecision::cpp_bin_float_oct; B b = foo(B(23)); // error As a workaround you currently have to write template <typename Type> Type bar(const Type x) noexcept { using ::std::sin; using ::boost::multiprecision::sin; return sin(x) * 42; } using A = double; A a = bar(A(23)); // ok using B = boost::multiprecision::cpp_bin_float_oct; B b = bar(B(23)); // ok This contradicts the template idea and is time-consuming/error-prone. thx Gero

1 0

Master is open for merges
by Marshall Clow 15 Apr '23

15 Apr '23

Master is open again, with no restrictions. Boost version numbers bumped (boost, config, more), and new release notes stubbed (website). Next milestone: June 21 Boost 1.83.0 closed for new libraries and breaking changes Release calendar: https://boost.org/development <https://boost.org/development> — Marshall

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 14 Apr '23

14 Apr '23

niedz., 9 kwi 2023 o 03:11 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/9/23 03:20, Andrzej Krzemienski wrote: > > > > Well, in my experience, the scope fail/success is exclusively about > > exceptions, so I will still focus on exceptions. > > Here is a small benchmark comparing the deactivation-based mechanism > > of a scope_guard with uncaught_exception-based mechanism of > scope_fail. > > The former performed like 36 times faster, as it doesn't have to > > perform the calls to the runtime. > > > > Sorry. Forgot the link. Here it is: > > https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74 > > <https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74> > > The thing with manually dismissing (or activating) the scope guard > before leaving the scope diminishes the usefulness of the scope guard. > The first and foremost reason to use a scope guard is to automate > execution of the action upon exiting the scope. If you now have to > manually ensure this at every point where you might leave the function, > what's the point of using it in the first place? > To "automate" is just one goal. A more modest one is to "make it manageable". Like in the case where you want to push_back into two vectors in a transactional-like fashion: vec1.push_back(Connection{params}); scope_guard pushGuard {[&]{ vec1.pop_back(); }} vec2.push_back(Storage{params}); pushGuard.deactivate(); The problem is contained, so I do not mind the call to deactivate(). But without the scope_guard, I would have to define my own class that does a pop-back in the destructor. > > Yes, you can manually (de)activate the guard in small and contained > cases, but in general I would very much prefer it to work automatically. > Otherwise, it quickly becomes a maintenance nightmare that it was > supposed to fix. > True. Therefore in my code I would contain the code that requires a guard. (In general, I prefer RAII.) But even contained cases need a scope guard. So, the trade-off is this: scope_fail: - requires no manual deactivate scope_guard with deactivate(): - works uniformly and unsurprisingly in all contexts, including coroutines - is fast. I would recommend that this trade-off is documented. Regards, &rzej; > > > Regarding failure conditions other than exceptions, the problem with > > coroutines may still appear if a thread-local storage is used, such > > as errno. > > errno is volatile (not in core C++ terms but in terms of it changing its > value in various non-obvious ways), so you would normally read its value > into a local variable immediately after a syscall for testing before > returning. It is that local variable that you check in the scope guard, > not errno itself. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2