- Boost - lists.boost.org

asio::strand: Order of execution
by Georg Gast 11 Feb '25

11 Feb '25

Hi, If I use a asio::strand and post() there multiple function objects, are they executed in the same order or is the order of execution not specified? I think to use it as a work queue but I need them to be processed in sequence... Thx Georg

5 9

Decimal Review Result and Summary.
by John Maddock 02 Feb '25

02 Feb '25

First off I'd like to thank Matt and Chris for submitting the library for review, and for all the reviewers who submitted comments. My apologies for not posting this sooner, but this has been a difficult review to reach a definite result on. First the headline result: the result of the review is INDETERMINATE. What this means in practice: I'd like to encourage Matt and Chris to come back for a mini-review at a later date which should focus exclusively on the open issues listed below. I forget which library we applied this to in the past, but I believe the result is not without precedent. I note that a greater weight of reviews, and/or a clearer path forward may well have tipped the balance here. And of course as someone who's worked with Matt and Chris, I may well be being over-harsh in order to avoid bias... or perhaps I'm just over thinking the whole thing... In my notes below, I've split my comments into: * "Settled Issues", these were issues that were raised at some point but found not to be true issues. * "Todo", straightforward usability and implementation issues such as we get from any review process. I've filed matching GitHub issues for each of these. * "Open", these are the harder knotty problems, where it's not clear (yet) what the solution is. RATIONALE: we had five reviews (4 public, one direct to me), of which 4 were generally positive, and one was for reject. In addition, some of the positive reviews were directly contradictory in the direction they thought the library should progress in ("we should only support the fast types", vs "we should only support the fixed width types" etc). There were also some conditions for acceptance - mostly performance based - where it's not clear whether the objectives are possible in a sane time-frame. For example the often referenced Intel C library is frankly huge (source files > 6Mb in size) and makes heavy use of the "every function is a macro" C idiom, which at least for me renders the code virtually unreadable. As things stand I consider it unreasonable to ask the authors to replicate that work. In late breaking news, I also hear from Matt that GCC and IBM both "cheat" by using (mutually incompatible) non-IEEE binary encodings. There is also the "do we actually need decimal arithmetic" question - it is clear that many people think we do - there have been repeated attempts from researchers at IBM, Intel and others to push this towards standardization, in addition to some (rather patchy) hardware support. It's in C23, which means eventually C++ compiler support will be required too. Oh and python has a decimal library. However the authors need to articulate the case better - the killer application seems to be exact round tripping from human-readable and machine representations (ie exact representation of human data input). John Maddock (Decimal Library Review Manager) OPEN ISSUES ~~~~~~~~~~~ The case for decimal floating point needs to be better made - despite support from IBM and Intel, plus repeated standardization efforts, true killer examples seem to be thin on the ground. Perhaps liaison with other experts in the field would be helpful here (I note that Robert Klarer at IBM and also once around these parts has been involved in decimal proposals, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1977.html)? Should arithmetic operations always be performed on the performance optimized forms? If so, perhaps storage optimized forms should have no operators (or their operators return the unpacked versions)? Review managers note: can we use DEC_EVAL_METHOD to set behavior here? How do we address the performance gap? Add the option to wrap the Intel library? Rewrite using the same methodology as Intel (this looks like a truly massive amount of work)? Several reviewers make this a condition of acceptance however. Should we use _fast integers or width specific ones? The answer appears to be platform specific. Perhaps it's a question of changing the correct instances of _fast integers rather than all of them? Should we abolish the _fast types and only provide fixed-width std compliant types: this is the forward looking option in line with what the standards are doing... but it directly contradicts the requests of some other reviewers. SETTLED ISSUES ~~~~~~~~~~~~~~ The decimal32 decimal64 names etc are reserved by various standards especially IEEE-754, we need to stick to those names. Over long literals are acceptable without warning or error, though a static warning facility would be nice. One reviewer suggests removing BOOST_DECIMAL_FAST_MATH, however as it performs similar optimizations to other libraries / compiler options, it looks reasonable to stay if the authors wish. One reviewer suggested shortening the namespace names - this is a tricky one, I see the issue, but we have a tradition (rightly or wrongly) for long_descriptive_names in boost. Plus there are always using declarations and/or namespace aliases. I will leave this to the authors to decide. long/int overloads of scalbln are fine by me as these are std mandated, however the reviewer makes a valid point that these are useful only on 16 bit platforms (I do note that the library is intended to be micro-controller compatible though, so this may well be an issue there). One reviewer suggests passing arguments by value is a mistake especially for 128 bit types, other reviewers refuted this. Other than some experimentation / double checking on windows and non-Intel platforms this does not appear to be an issue in practice. Suggest no change unless the double checks prove otherwise, a comment in the source or the design rationale may well be welcome. One reviewer suggested using CLZ in num_digits, but this has been checked and is slower (a comment in the source to that effect would be welcome. Note that std::lower_bound is not constexpr until C++26. REQUESTED CHANGES ~~~~~~~~~~~~~~~~~ Literals should be in their own namespace. https://github.com/cppalliance/decimal/issues/827 Allow implicit conversions for all conversions which do not lose precision: https://github.com/cppalliance/decimal/issues/828 Remove sprint support. https://github.com/cppalliance/decimal/issues/829 Split into "use what you need" smaller headers, in particular iostream and std lib support code should be in separate optional headers rather than in #ifdef blocks. https://github.com/cppalliance/decimal/issues/830 I'm also not convinced about the value added by the other cstdio functions, namely printf, fprintf and snprintf. They only support decimal arguments. This means that printf("Value for id=%s is %H", id, value) is an error if id is a const char*. Integers work because they are cast to decimal types, which I found surprising, too. Given an int i, printf("Value for %x is %H", i, value) works but doesn't apply the hex specifier. The integer is promoted to a decimal type, which is then printed. I'd have expected the latter to be a compile-time error. I'd say that this will be the case if you replace std::common_type by std::conjunction as Peter suggested. https://github.com/cppalliance/decimal/issues/831 Are concept names supposed to be public? If they are, please document them as regular entities. If they are not, please move them into the detail namespace. https://github.com/cppalliance/decimal/issues/832 Collected documentation improvements: https://github.com/cppalliance/decimal/issues/833 Do the exponent_type typedefs need to be public? Do they need to be 64 bit? I suspect the latter is all about extracting the bits from the representation, and the former is a convenience to avoid a long list of friends - although the list doesn't look *that* long? If they remain public then a comment in the source with rationale would suffice. https://github.com/cppalliance/decimal/issues/834 Can we add (possibly explicit) constexpr construction from string literal? https://github.com/cppalliance/decimal/issues/835 There is an undocumented public constructor: constexpr decimal32(bool coeff, T exp, bool sign = false) noexcept; which appears to be a mistaken addition? https://github.com/cppalliance/decimal/issues/836 I wonder if constexpr decimal32(T coeff, T2 exp, bool sign = false) noexcept; is under-constrained? The sign argument appears to be superfluous given that coeff can be negative, and we know up front the size of integer required to represent the coefficient and exponent so we might as well make this a non-template: smaller integer arguments will get promoted and larger arguments will quite correctly issue a warning (I wouldn't use a type smaller than int though, otherwise the things get altogether too picky): https://github.com/cppalliance/decimal/issues/837 There are a few places where pow10 is used with a constexpr argument, but while the function is constexpr it is not used in a constexpr context. The example picked up from the review was auto res_sig {(static_cast<unsigned_int128_type>(lhs_sig) * static_cast<unsigned_int128_type>(rhs_sig)) / pow10(static_cast<unsigned_int128_type>(13))}; in mul_impl.hpp but there may be others. https://github.com/cppalliance/decimal/issues/838 Consider using delegating constructors in for example constexpr decimal128::decimal128(bool coeff, T exp, bool sign) (if we keep this... but check for other opportunities). https://github.com/cppalliance/decimal/issues/839 Ensure that +0 and -0 are equivalent. https://github.com/cppalliance/decimal/issues/840 Make uint128 a non-detail type given that it is used in public interfaces. Such a shame that it can't be a real std::uint128_t, but perhaps a conversion operator could be provided when the type is available? https://github.com/cppalliance/decimal/issues/841 Rationalize traits class usage to make the code easier to read: https://github.com/cppalliance/decimal/issues/842 Code duplication: comparison operators calling into `equal_parts_impl()` for `decimal32_fast`, but the definition being placed directly into the comparison operator functions for `decimal64_fast` and decimal128_fast`. For me, this makes it seem like these 3 types must be implementing the comparison operators in different ways, when in reality they are doing exactly the same calculation, implemented in 3 separate places. https://github.com/cppalliance/decimal/issues/843 Code duplication with `bias_v`: https://github.com/cppalliance/decimal/issues/844 Explicit conversions need much better documentation for overflow behavior - I had to look at the source for to_integral to figure this out - I'm also wondering if returning zero on error is the right solution or if the result should be saturated? https://github.com/cppalliance/decimal/issues/845 Remove the footgun of lossy conversion from decimal floating point types. https://github.com/cppalliance/decimal/issues/846

6 9

Decimal: Formal review begins.
by John Maddock 31 Jan '25

31 Jan '25

The review of the proposed Decimal Number library by Matt Borland and Chris Kormanyos begins today and runs until 22nd Jan. You will find documentation here: https://cppalliance.org/decimal/decimal.html And the code repository is here: https://github.com/cppalliance/decimal/ Boost.Decimal is an implementation of IEEE 754 <https://standards.ieee.org/ieee/754/6210/> and ISO/IEC DTR 24733 <https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf> Decimal Floating Point numbers. The library is header-only, has no dependencies, and requires C++14. Please provide feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions).header-only, has no dependencies, and requires C++14. Best, John Maddock (review manager).

18 94

Author assistance for WG21 display content
by Robert Beeston 30 Jan '25

30 Jan '25

Hello everyone, My name is Rob Beeston, and I’m the Product and Creative Director for C++ Alliance. I’m currently making arrangements for the upcoming WG21 event, and could use some help from some of the authors. We will be making posters, similar to this mockup ( https://downloads.cppalliance.org/images/boost-poster.png) to highlight the following libraries at the event: Hash2 Math Parser Scope Unordered Each poster would need a brief description, a longer explanation (perhaps 1-2 short paragraphs of what it does and/or how it works) and a code snippet that would best represent how to use it. Thanks and I’m looking forward to working with you. Rob

4 6

Interest for C++20 modules support of boost officially
by Chuanqi Xu 29 Jan '25

29 Jan '25

Hi Boost Developers, I am Chuanqi Xu, the maintainer for modules & serialization in clang and also a fan of C++20 modules. The post itself was motivated by a discussion (https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 <https://cpplang.slack.com/archives/C27KZLB0X/p1734335425348809 >). You don’t need to read it if you’re not interested. I’ll try to make the post itself self contained. The original story comes from a high quality experiment for C++20 modules in boost (https://anarthal.github.io/cppblog/modules2 <https://anarthal.github.io/cppblog/modules2 >). The blog reads pretty good to me. However, anarthal (the author) told me later that the process of supporting modules in boost got suspended since the authors (or the maintainers) don’t want it since no one is going to use them. And if I want it, I need to send a mail here. Then this is the beginning of the story. First of first, I want to emphasize that “no one is going to use them” is not true. We’ve already used C++20 modules at larger scale internally for roughly a year. For boost (and other third party libraries), we choose to wrap a module ourselves as a workaround (with some compiler extensions to ease the refacotoring, but we don’t like it. We still want standard behavior). We didn’t reach out since we feel boost will support C++20 modules later or sooner so we don’t need to do anything specially. (Maybe we were wrong. We didn’t understand the ecosystem enough). Until yesterday, I just knew that boost didn’t know such needs. Before I wrote this email, I wondered a lot of words to emphasize that our need are a good example and the users of closed source are important users too. But just now, I searched the use of boost in modules in GitHub. I just realized I can show it (the importance of C++20 modules support for boost) much easily with the open source world. I searched `boost path:*.cppm` in GitHub and got the following list: https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… <https://github.com/infiniflow/infinity/blob/fa922afd58c973a9a317d2c09ad8cea… > https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… <https://github.com/ossia/score/blob/0ce6f62a97651a1248a92b3e13ce6ede10341d1… > https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… <https://github.com/RichardLuo0/make-dot-cpp/blob/e2ef10fd43060a2b56fc8f87f1… > https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… <https://github.com/slaakko/cmajor-mod/blob/32e6eb8dc099b395fa751340de96f478… > https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… <https://github.com/df-com/dragonfly/blob/9dfcbc1153f292eb8581f1df7459600cc3… > https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… <https://github.com/nofe1248/Helium/blob/92ec4452b8c05e6d86c972f843196a4392a… > https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… <https://github.com/LagrangeDev/liblagrange/blob/10e3b48f8d47fd65de00b14cfed… > https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… <https://github.com/yudaichen/feature-db/blob/e94ade969af682ed5dd25d70bf282b… > This is not a complete list even for my search only and I believe there are other patterns to use boost with modules now (e.g., at least `*.cppm` is not the defacto suffix). And I also believe, from my experience as a C++ user, if boost provide modules, I may try to use it. But if boost didn’t provide it, maybe I won’t ask for it if I don’t want modules super bad. Since modules doesn’t add any new functionality actually. So most users may not ask for it explicitly. But if boost provides it, people may give it a try. The above text are the body of the post. I hope it can show it is needed. — Following of are some technical discussion for the extra maintainance burden by introducing modules. The conclusion is, I think, the burden is pretty low. Since modules are not complex to users. Different from other big features in C++, modules are pretty easy to understand. The complexity of modules are majorly on tools and the ecosystem. For programmers who don’t get involved to much to the ecosystem (or infrastructure), modules should be pretty easy to understand. For authors of libraries, after boost introduce modules, you only need to do 2 extra things: - In headers, add a macro (assume its name as BOOST_MODULE_EXPORT, which will be ‘export’ conditionally) to the entities that need to be exported. - In headers, include standard headers and other dependent headers conditionally so that we don’t include anything if the headers are in a module unit. e.g., https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… <https://github.com/boostorg/pfr/blob/f09e6aeae9d050897fff72b93d5f5e866cc5e1… > then that’s roughly all you need for maintaining it at source level. For building and distributing related things, anarthal told me that the boost will handle it globally so the individual arthors don’t need to care about it. — In slack, there are some other discussion about module names and linking problems (https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 <https://cpplang.slack.com/archives/C27KZLB0X/p1734345716728609 >). But I feel they are implementation details. I may not talk too much for that as a user at least now. And also there are opinions for configuration flags. These are the jobs of build systems (cmake is working on it). I think boost don’t need to worry for that. Similarly, at least libc++ has similar problems but libc++ still released std module. — Boost has a special position in the C++’s ecosystem. The most simple and impressive answer I’ve heard for the question “when can we start to use modules” is, “when boost makes it”. Thanks, Chuanqi

15 85

observing process blocked on find_or_construct
by Murali Kishore 28 Jan '25

28 Jan '25

Hi , We are trying interprocess scenario, one process created shared memory objects and killed and second process open the object using find_or_construct seeing this process blocked at getting lock. bt as shown below, #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007fa6b6733eb6 in _L_lock_941 () from /lib64/libpthread.so.0 #2 0x00007fa6b6733daf in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7fa6b198b070) at ../nptl/pthread_mutex_lock.c:113 #3 0x0000000001bc3822 in lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90 #4 lock (this=0x7fa6b198b070) at /x86/include/boost/interprocess/sync/interprocess_recursive_mutex.hpp:163 #5 scoped_lock (m=..., this=<synthetic pointer>) at /x86/include/boost/interprocess/sync/scoped_lock.hpp:81 #6 boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_named_construct<char> (this=0x7fa6b198b010, type=<optimized out>, name=0x7ffde183ca20 "reported_slice_config_list", num=1, try2find=<optimized out>, dothrow=<optimized out>, table=..., index=..., is_intrusive=...) at /x86/include/boost/interprocess/segment_manager.hpp:1076 #7 0x0000000001bee007 in boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>::priv_generic_construct (this=<optimized out>, name=name@entry=0x7ffde183ca20 "reported_slice_config_list", num=num@entry=1, try2find=try2find@entry=true, dothrow=dothrow@entry=true, table=...) at /x86/include/boost/interprocess/segment_manager.hpp:760 #8 0x0000000001bf112d in generic_construct<boost::container::map<unsigned int, gnb::broadcast_plmn_list, std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > > > (table=..., dothrow=true, try2find=true, num=1, name=0x7ffde183ca20 "reported_slice_config_list", this=<optimized out>) at /x86/include/boost/interprocess/segment_manager.hpp:704 #9 operator()<std::less<unsigned int>, boost::interprocess::allocator<std::pair<unsigned int const, gnb::broadcast_plmn_list>, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long int, long unsigned int, 0ul>, 0ul>, boost::interprocess::iset_index> >&> (this=<optimized out>) at /x86/include/boost/interprocess/detail/named_proxy.hpp:132 please let me know in which cases this can be occured, we see first process also hangs in termination. -- Regards, Murali Kishore

3 3

End of Boost.Decimal Review
by John Maddock 25 Jan '25

25 Jan '25

The review of the proposed Decimal library has now ended - although given that there was a lot of lively discussion for me to sort through, there is still time to submit a late review if you wish. If I've counted correctly there were 5 reviews (4 on the list, one private): one firm reject and 4 conditional accept, plus many more people involved in the discussion than gave reviews. I have to be honest, I would have liked to have seen a couple more reviews in order to have reached a clearer consensus, so please bare with me while I sift through all the comments and try and reach a conclusion. My thanks to everyone who took part, and of course to Matt and Chris for submitting the library. Best, John.

1 0

GSoC 2025 Projects
by Matt Borland 24 Jan '25

24 Jan '25

All, In the modules thread and on Slack, I asked if Boost had a current plan for participation in GSoC 2025. I haven't received any responses yet, so I'll assume there isn't a plan. I'm wondering if anyone has: a) Projects they would like to propose for GSoC, and b) An interest in mentoring. Here are some ideas that I think could be beneficial and approachable: 1) A proof of concept for a Boost module, including distribution and installation processes, and potentially adding support to select libraries. This project could have easy access to the Clang and MSVC teams via their mentor it seems. 2) Bi-variate interpolation has been requested before in Math. ACM TOMS algorithms 751 and 761 could fit the bill, but their references are written in F77. A faithful translation and implementation of those papers would be a good start. 3) Chris Kormanyos and I are working on a cryptographic module that we intend to have certified under FIPS 140-3 and then propose to Boost. An extension of this could be a TLS project where a student provides a proof of concept with a generic file transfer server or similar that works securely with OpenSSL, and then also with our new module. I can mentor at least one of these projects. If anyone has past applications for the organization, please send a link or copies. We have until mid-Feb to apply as an organization, which I can do if no one else volunteers. Best, Matt

5 8

Another Boost.Decimal Review
by Jeff Garland 23 Jan '25

23 Jan '25

Thanks to Matt Borland and Chris Kormanyos for this good work. I vote to ACCEPT the library. I trust the authors to improve documentation, api, and performance as a matter of continued development. Let me say a few things about some discussions in the review threads up-front. *Standardization:* I'm an advocate for it and would be willing to help the authors with the process. Rationale: 1) this standardizes existing practice (aka IEEE 754), something like it is supported in many languages (specifically C23), and there's significant use cases for this in many domains even if it's slightly slower. 2) While a standalone library can go far, often a compiler/library can more easily optimize fundamental things like numeric types. 3) I spoke with Dietmar about the review and standardization -- he's still an advocate for having this capability, but has higher priorities at the moment. *N2849*: It's a decent design for 2009 -- less so in 2025. Specifically, w.r.t. conversion we should only perform automatic conversions from types (see below). The library already takes care of from_chars, format and some other more modern things N2849 wouldn't address. *C23 and _Decimal** Should this library consider being a layer over C23 types where that's possible? GCC supports them at least in a limited fashion. https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html > Does this library bring real benefit to C++ developers for real world use-case? > Do you have an application for this library? Yes and yes. > Does the API match with current best practices? I have some quibbles here. *Construction*: template <typename T, typename T2>constexpr decimal32(T coeff, T2 exp, bool sign = false) noexcept; Is the sign flag helpful here? It seems simpler to just handle a negative coefficient -- like it already does. When I look at it there's already cognitive dissidence in my brain about if the sign flag *overrides* or *inverts* the coefficient sign. The N2849 api doesn't have this flag. *Fast Types:* I read through the list conversation about the _fast types. My suggestion is to drop them. Simplifies everything for users and implementers. The movement in c++ over the last decade(s) has been to precisely say the size of the type to ensure correctness and not 'let the platform decide' (aka uint32_t, int64_t, etc). In my comment on documentation you'll notice the c++20 extended floating point types *only provide* fixed sizes. Also N2849 and C23 don't support _fast types for decimal. *Conversions:* I'd like to see the library *pull back* on convertibility. long double ld{1.23456789234567}; decimal32 d(ld); // what happens -- round, truncate, doesn't compile? The best answer is doesn't compile. There's been significant work in the standard now to define floating point rank and limit conversions with the extended floating point types. Specifically: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html#rank There's also other work on type traits and value preserving conversions in the SIMD capabilities. Also, std::chrono basically already does this -- any value destroying conversion has to be explicit. At a minimum the answer needs to be better documented - aka does what 754-2008 says? For other examples of things I'd remove and make a free function cast/round -- aka explicit user decision: class decimal64 { ... explicit constexpr operator std::int8_t() const noexcept; This is highly likely to not be value preserving so shouldn't be possible without a decision on how to handle overflow. class decimal64 { ... explicit constexpr operator decimal32() const noexcept; *Literals* constexpr auto operator "" _DF(const char* str) -> decimal32constexpr auto operator "" _df(const char* str) -> decimal32 Why not _d32, _d64, _d128? _df makes me think fast, not 32. > Is the documentation helpful and clear? Not bad, but as usual improvements can be made. As a user I'm going to need to select one of these types -- I'd love to see a table like this one at cppreference for named floating point types: *Type name* Defined in header <stdfloat> <https://en.cppreference.com/w/cpp/header/stdfloat> Literal suffix Predefined macro C language type Type properties bits of storage bits of precision bits of exponent max exponent std::float16_t f16 or F16 __STDCPP_FLOAT16_T__ _Float16 16 11 5 15 std::float32_t f32 or F32 __STDCPP_FLOAT32_T__ _Float32 32 24 8 127 std::float64_t f64 or F64 __STDCPP_FLOAT64_T__ _Float64 64 53 11 1023 std::float128_t f128 or F128 __STDCPP_FLOAT128_T__ _Float128 128 113 15 16383 std::bfloat16_t bf16 or BF16 __STDCPP_BFLOAT16_T__ (N/A) 16 8 8 127 Not sure how it renders in email so source: https://en.cppreference.com/w/cpp/types/floating-point Not looking for exact replication, but something like this. In the *using the library* section I'd like to see some: - examples of using it it math - examples of the behavior of NAN/inf values - conversions from other types like float expanded Where is the design decisions section? Some of the things I'm asking about should be covered in the docs. > Did you try to use it? What problems or surprises did you encounter? I didn't have time to play with it unfortunately -- godbolt would be helpful. That's all for now. Jeff

4 5

Re: [boost] Decimal: Formal review begins
by Glen Fernandes 23 Jan '25

23 Jan '25

I mentioned this to Matt, but I would like to see benchmarks comparing boost::decimal64_fast to a Decimal64 backed by Intel's DFP library, which is what I know to be in actual use today: https://www.intel.com/content/www/us/en/developer/articles/tool/intel-decim… Not that the benchmarks comparing to GCC's Decimal64 (which is based on the libbid which ships with libgcc) aren't useful, I personally don't know anyone using that today. Benchmarks should ideally also include Intel's compiler, because at least one of the relevant parties who motivated me to suggest the Decimal64 library (to Vinnie as a potential project) do use the Intel C++ compiler (and their Fortran compiler) for areas where they perform better. (The non-fast versions don't matter to me. I don't know anyone who would want to use them). Glen

12 36