October 2020 - Boost-users - lists.boost.org

A question about boost::uuid
by Shishir Pandey 10 Oct '20

10 Oct '20

Hi all, I have been trying to figure out how to use murmurhash3 with boost::uuid. Looking at the documentation it is not entirely clear to me if a class implementing murmurhash3 that provides the interface defined by NameHashProvider would be sufficient. If yes, would creating a wrapper over the following implementation work? https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp Can anyone direct me to some similar implementation perhaps not of using murmurhash3 but of using any other algorithms? Regards, Shishir Pandey -- Necessity is not an established fact, but an interpretation. - Friedrich Wilhelm Nietzsche

1 0

Re: [Boost-users] [Boost-announce] [PFR][review] Result
by Antony Polukhin 09 Oct '20

09 Oct '20

On Thu, Oct 8, 2020, 13:51 Benedek Thaler via Boost-announce < boost-announce(a)lists.boost.org> wrote: <...> > Benedek > review wizard > Many thanks for beeng the review manager! >

1 0

Re: [Boost-users] [Boost-announce] [FPR] Review of FPR starts Today: Sept 28 - Oct 7
by Nat Goodspeed 05 Oct '20

05 Oct '20

On Mon, Sep 28, 2020 at 1:15 PM Benedek Thaler via Boost-announce < boost-announce(a)lists.boost.org> wrote: - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I have read only the announcement email, but it prompts a very interesting question: does the FPR library facilitate integration with Boost.Serialization? If not yet, how hard would it be to improve the interoperability of those two libraries? If the FPR documentation already addresses this point, a terse reply to that effect will suffice.

2 2

improve TypeTraits
by Gero Peterhoff 04 Oct '20

04 Oct '20

Hello John, you have probably already read that I think some new TypeTraits are useful. Here are the details: a) very useful: precise type classification - this is the basis of every abstraction and should definitely be implemented - is_character: contains only characters (char32/16/8_t, wchar_t, char); is_un/signed_character - is_integer: contains only integers and no characters and no bool (u/int8..X_t); is_un/signed_integer - is_logic: contains only logical types (bool and boost::tribool, *)) - is_string: contains everything that can be used as a string, but needs these specializations: 1) is_bounded_string (similar to is_bounded_array) 2) is_unbounded_string (similar to is_unbounded_array) 3) is_static_string (for boost::basic_static_string) 4) is_string_ref (for boost::basic_string ref) 5) is_string_view (for std::basic_string_view) 6) is_string_class (for std::basic_string) - character_of: the underlying character type based on is_string b) very useful - remove_cv_ptr (similar to remove_cv_ref) - make_same_signed (similar to make_un/signed): changes the sign depending on a type - conditional_signed: changes the sign depending on a truth value - is_same_signed: same sign c) also makes sense - is_tuple - is_rational (similar to boost::is_complex) - is_binary: if base==2 (numeric_limits::radix==2) - is_decimal: if base==10 (numeric_limits::radix==10) d) - is_native: a type is natively available on the platform (e.g. int64_t: Linux32:false, Linux64:true; float80_t: x86:true, else:false) - is_vectorisable: a type can be vectorized natively on the platform - there are basic SSE/AVX/SVE/... functions However, I have a problem: boost/std::is_integral contain bool. Perhaps you can do that like this, but it leads to problems with is_arithmetic, since is_arithmetic is based on is_integral and thus contains bool. I think the point of is_arithmetic is to be able to calculate numerically with the type - so the scenarios are not useful: abs(bool), sin/cos/...(bool), etc. The same applies to characters. There are two possible solutions: - redefine is_arithmetic -> is_integer || is_floating_point - a new TypeTrait is_numeric (e.g.) -> is_integer || is_floating_point There are some differences between boost- and std-TypeTraits. Can you please include that in the documentation? Furthermore there seem to be errors with char8_t, e.g. boost::is_unsigned<char8_t> -> false, std::is_unsigned<char8_t> -> true (correct). Summary With these measures, a large number of template functions/classes can then be tailored precisely to the application and incorrect use can be prevented. regards Gero *) I've written a couple of classes for logic: bool3_t (a modern variant of boost::tribool), bool4_t (http://www.filosofia.unimi.it/dagostino/wp-content/uploads/2017/05/Belnap.p…) and bool2_t (for completeness)

1 0

Using Boost.Random with fixed-point numbers
by John W 03 Oct '20

03 Oct '20

I have a fixed-point number class (based on libfixmath) which in code largely behaves like a float due to various operator overloading. Now, I am trying to generate random numbers with them. Uniform random is easy enough — just reinterpret some random bits as my fixedpoint type. However, I'd like to have other distributions, like boost::random::normal_distribution. But from what I can tell, Boost.Random might have some baked-in assumptions about only working on float/double/long double. Is that correct? Or are there ways I can more-or-less transparently use boost::random::xxx distributions with my custom type? Basically, I want to know how much the <RealType> template argument can be abused. In std::random, there is some clear language[1], saying: "The result type generated by the generator. The effect is undefined if this is not one of float, double, or long double." and I believe boost::random aims to be in agreement with std::random, generally. But I could not find such clear language in the Boost.Random docs. Thanks -John [1] https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution

2 1