- Boost - lists.preview.boost.org

Re: [boost] Replacing the ML with a forum
by Niall Douglas 26 Apr '23

26 Apr '23

On 26/04/2023 15:43, Vinnie Falco via Boost wrote: > On Wed, Apr 26, 2023 at 7:12 AM Marshall Clow via Boost > <boost(a)lists.boost.org> wrote: >>> Are you using a threaded e-mail reader? If so, do you care if >>> discussions are changed to be flat (like Discourse)? >> >> Yes, and Yes. > > The current situation is this. For various reasons, we have no forum > for the new website. And a new forum is crucial for attracting new > people, as no one in their twenties or earlier wants to use a mailing > list. Twenty somethings don't use discussion forums either. Too passe. Re: Implementation last time this was discussed here and options investigated we found that https://fossil-scm.org/forum/forum implemented a web discussion forum with mailing list interface. One could use either interface, they were equivalent, and the UI seemed to meet approval here. I remember there were also other web discussion forum implementations with mailing list interface, but Fossil was the least unacceptable of them according to here, back in the day. Now, as to whether it could be improved upon, surely yes. However ever since Google stopped indexing discussion forms, I don't think they're the draw of users that they were. Nowadays if you can't find it on TikTok, it doesn't really exist for the under thirties. Niall

1 0

Re: [boost] Replacing the ML with a forum
by Andrea Bocci 26 Apr '23

26 Apr '23

On Wed, 26 Apr 2023 at 16:09, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? > Very simply, if you replace the mailing list(s) with a forum (or fora), I will stop following any Boost discussion. Best of luck, .Andrea -- Dr. Andrea Bocci Applied Physicist, CMS Experiment <https://cms.cern/>EP-CMD, CERN <https://home.cern/>168990 (+41 75 411 8990) CERN 40/1-B01 <https://maps.cern.ch/mapsearch/mapsearch.htm?n=['40/1-B01']> E27810 Esplanade des particules, 1, CH-1211 Geneve 23, Switzerland <https://goo.gl/maps/AMjHdhXzYk2itSu7A>

2 2

Re: [boost] Replacing the ML with a forum
by Stefan Seefeld 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 10:53 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > > Pros of Writing It Ourselves > > * Uses Python, a popular language > * Preserved mailing list experience > * Threaded discussions > * Customized to suit our needs > > Cons of Writing it Ourselves > > * More expensive long-term > * Takes longer to reach feature parity > * We have to maintain it > > Note, the C++ Alliance is covering all of the expenses for development > so the expense issue is not of particular importance, our priority is > on getting things done perfectly for users even if it costs a bit > more. > Perhaps there is a middle-way: layering whatever customization you need on top of existing infrastructure (e.g. Mailman) ? This could even be submitted upstream, if there is enough common interest, so Boost wouldn't have to own and maintain it in the long term... ...ich hab' noch einen Koffer in Berlin...

2 3

Re: [boost] Replacing the ML with a forum
by Andrey Semashev 26 Apr '23

26 Apr '23

On April 26, 2023 5:08:49 PM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? Personally, I don't group posts by threads and read everything flat. But I recognize that others may have different preference, and one of the advantages of ML is that everyone can configure their mail client the way they want. I think this liberty should be preserved.

1 0

Re: [boost] Replacing the ML with a forum
by Vinnie Falco 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 7:12 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > Are you using a threaded e-mail reader? If so, do you care if > > discussions are changed to be flat (like Discourse)? > > Yes, and Yes. The current situation is this. For various reasons, we have no forum for the new website. And a new forum is crucial for attracting new people, as no one in their twenties or earlier wants to use a mailing list. However, we also recognize the importance of preserving the mailing list interface and threaded discussion model. After spending months of doing tests and looking at existing solutions, we have reached the conclusion that the only way to bring maximal satisfaction to the community is for us to implement our own web-based forum which supports threaded discussion and also has a mailing list interface, such that the mailing list experience is unchanged for those who still want to use it (which seems to be quite a few people). The other alternative is to do a clean break and deploy something completely new, which would be Discourse. The downside of Discourse is that it does not support threaded discussions, and because of their philosophical objection to hierarchical conversations, it most certainly never will. Check this out: https://community.lsst.org/t/understanding-and-using-discourses-flat-thread… This rationale sounds very good on paper and it probably works for things such as support fourms. But it is poorly suited for the specific nature of the Boost mailing list where discussions can rage for months (I miss that). Enormous discussions were the bread and butter of the social experience and that needs to be revitalized. Anyway... Pros of Discourse: * Already written * Has an email interface * Can be restyled to match the site (mostly) * Probably cheaper long-term Cons of Discourse: * No threaded discussion * Written in Ruby, a dying language --- Pros of Writing It Ourselves * Uses Python, a popular language * Preserved mailing list experience * Threaded discussions * Customized to suit our needs Cons of Writing it Ourselves * More expensive long-term * Takes longer to reach feature parity * We have to maintain it Note, the C++ Alliance is covering all of the expenses for development so the expense issue is not of particular importance, our priority is on getting things done perfectly for users even if it costs a bit more.

1 0

Re: [boost] Replacing the ML with a forum
by René Ferdinand Rivera Morell 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 9:08 AM Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > Are you using a threaded e-mail reader? I use Gmail, so no? > What is important> to you (besides that you can continue to use your email client)? Good, email/forum specific search. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] Replacing the ML with a forum
by Stefan Seefeld 26 Apr '23

26 Apr '23

On Wed, Apr 26, 2023 at 10:08 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? What is important > to you (besides that you can continue to use your email client)? > yes !! Boost discussions sometimes go on for months, so having a structured view of the whole conversation is essential not to get lost. ...ich hab' noch einen Koffer in Berlin...

1 0

Re: [boost] Replacing the ML with a forum
by Marshall Clow 26 Apr '23

26 Apr '23

On Apr 26, 2023, at 7:08 AM, Vinnie Falco via Boost <boost(a)lists.boost.org> wrote: > > Before we replace the mailing list with a forum (and implement a mail > gateway) can I get feedback on how you use the mailing list from your > email client? > > Are you using a threaded e-mail reader? If so, do you care if > discussions are changed to be flat (like Discourse)? Yes, and Yes. — Marshall

1 0

Replacing the ML with a forum
by Vinnie Falco 26 Apr '23

26 Apr '23

Before we replace the mailing list with a forum (and implement a mail gateway) can I get feedback on how you use the mailing list from your email client? Are you using a threaded e-mail reader? If so, do you care if discussions are changed to be flat (like Discourse)? What is important to you (besides that you can continue to use your email client)? Thanks

1 0

Re: [boost] Help Boost, Please!
by David Sankel 25 Apr '23

25 Apr '23

On Mon, Apr 24, 2023 at 2:03 PM Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > Issues can be opened against the documentation for anything at all by > pressing the “Report an Issue” button located at the top right of every > documentation page, or simply by visiting > https://github.com/cppalliance/site-docs/issues I added https://github.com/cppalliance/site-docs/issues/17 for *The 'Getting Started Doc' should use CMake as the primary way to build and use Boost.* I think one of the key areas to focus on is new user success. Whatever we can do to prevent folks from giving up when they attempt using Boost for the first time will have a substantial impact. -- David

1 0

Re: [boost] Help Boost, Please!
by Kostas Savvidis 24 Apr '23

24 Apr '23

> On Apr 24, 2023, at 21:03, Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > > The more that people help out, the better the results will be. I just asked GPT-4 to do it! Of course, without too much context it produces nonsense, see below, but providing it with more detailed instructions and previously existing documentation on this and asking to change this and that can possibly do the job. Below the contributor guide I am posting an even more exotic "beginner's guide to asio". I suspect it might be complete nonsense too, but enjoy! Cheers, Kostas =============================================================================== Boost Library Contributor Guide Thank you for your interest in contributing to the Boost library collection. The following guide outlines the requirements and guidelines for submitting a library to Boost. Requirements To ensure a smooth submission process and avoid rejection, the library you submit must meet the following requirements: License requirements: The license must be simple to read and understand. The license must grant permission without fee to copy, use, and modify the software for any use (commercial and non-commercial). The license must require that the license appear on all copies of the software source code. The license must not require that the license appear with executables or other binary uses of the library. The license must not require that the source code be available for execution or other binary uses of the library. The license may restrict the use of the name and description of the library to the standard version found on the Boost website. Restricted licenses like the GPL and LGPL are not acceptable. Copyright ownership: The copyright ownership of the library must be clear. Include a copyright notice in all the important files you submit. Portability requirements: The library's interface must be portable and not restricted to a particular compiler or operating system. The library's implementation must, if possible, be portable and not restricted to a particular compiler or operating system. If a portable implementation is not possible, non-portable constructions are acceptable if reasonably easy to port to other environments. Implementations must be provided for at least two popular operating systems (such as UNIX and Windows). The library must run on at least two C++ compilers implementing the latest ISO C++ standard. Boost contributors often try to ensure their libraries work with popular compilers. Use the boost/config.hpp configuration header to work around compiler deficiencies. Organization requirements: The library must be generally useful. The library must adhere to the Boost standard library organization upon acceptance. The author must be willing to participate in discussions on the mailing list and refine the library accordingly. Guidelines To increase the chances of your library being accepted and to maintain consistency within the Boost library collection, follow these guidelines: Backwards compatibility: Provide a stable interface for your library, and avoid breaking changes unless absolutely necessary. If you must introduce breaking changes, provide a clear and easy migration path for users. Design and programming: Follow the C++ standard library conventions and idioms whenever possible. Avoid overly complex designs and keep the library simple and easy to use. Filenames: Use lowercase filenames, with words separated by underscores. Use the .hpp extension for header files, and the .cpp extension for implementation files. Naming consistency: Use consistent naming conventions for classes, functions, and other identifiers. Follow the Boost naming conventions as closely as possible. Documentation: Provide thorough and clear documentation for your library. Use Doxygen-style comments in your header files to document interfaces and functions. Provide examples and usage scenarios to demonstrate how to use your library. Rationale For a detailed explanation of the reasons behind these requirements and guidelines, refer to the Boost Library Requirements and Guidelines document. Acknowledgements We appreciate your contribution to the Boost library collection and thank you for following these requirements and guidelines. If you have any questions or concerns, please don't hesitate to ask for help on the Boost developers mailing list. ============================================================================================= could you write a new user guide for the boost.asio library? Sure, I can provide a beginner's guide to using the Boost.Asio library. Here it is: Boost.Asio is a library for network and low-level I/O programming in C++. It provides a set of abstractions for dealing with sockets, timers, and other I/O objects. Boost.Asio is designed to be portable across operating systems and platforms and is built on top of the Boost C++ libraries. To use Boost.Asio, you'll need to have the Boost libraries installed on your system. You can download the latest version of Boost from the Boost website, and follow the instructions for installation. Once you have Boost installed, you can include the Boost.Asio header file in your C++ code: cpp #include <boost/asio.hpp> This gives you access to the Boost.Asio library. Here's a basic example that demonstrates how to use Boost.Asio to create a TCP server that listens for incoming connections and sends a simple message to the client: cpp #include <iostream> #include <boost/asio.hpp> using boost::asio::ip::tcp; int main() { boost::asio::io_context io_context; tcp::acceptor acceptor(io_context, tcp::endpoint(tcp::v4(), 8888)); while (true) { tcp::socket socket(io_context); acceptor.accept(socket); std::string message = "Hello, World!"; boost::system::error_code error; boost::asio::write(socket, boost::asio::buffer(message), error); } return 0; } In this example, we create an io_context object, which is the central object that drives the Boost.Asio library. We then create a tcp::acceptor object, which listens for incoming TCP connections on port 8888. Inside the while loop, we accept incoming connections using the acceptor.accept() method, which blocks until a new connection is established. We then create a new tcp::socket object to handle the communication with the client. Finally, we send a simple message to the client using the boost::asio::write() method, which writes the message to the socket. This is just a basic example, but Boost.Asio provides a wide range of abstractions for handling network and low-level I/O programming in C++. You can find more information in the Boost.Asio documentation. Here are a few tips for using Boost.Asio: Use asynchronous I/O operations whenever possible. This can help you avoid blocking and maximize the throughput of your application. Use the io_context object to manage the lifecycle of your I/O objects, such as sockets and timers. Use the deadline_timer object to schedule timeouts for I/O operations. Use the streambuf object to handle variable-length data, such as incoming messages over a socket. Be aware of thread safety issues when using Boost.Asio in a multi-threaded environment. The library provides a number of synchronization primitives, such as mutexes and condition variables, to help you manage concurrency. With a little practice, you should be able to use Boost.Asio to build complex network and low-level I/O applications in C++. Good luck! > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Help Boost, Please!
by Vinnie Falco 24 Apr '23

24 Apr '23

On Mon, Apr 24, 2023 at 11:03 AM Louis Tatta via Boost <boost(a)lists.boost.org> wrote: > Issues can be opened against the documentation for anything at all by > pressing the “Report an Issue” button located at the top right of every > documentation page, or simply by visiting > https://github.com/cppalliance/site-docs/issues In case this wasn't clear - if YOU (the person reading this) want to have ANYTHING changed or added in the site documentation, all you need to do is open an issue and it will be triaged and attended to: https://github.com/cppalliance/site-docs/issues Thanks

1 0

Re: [boost] Help Boost, Please!
by Ruben Perez 24 Apr '23

24 Apr '23

> Peter Turcan is a new face at The C++ Alliance but a veteran at Technical > Writing. He needs your help to make these pages shine. Specifically, we > need volunteers for the following: > > Check the documentation for accuracy > Make suggestions for improvements or changes > Contribute directly to the documentation (pull requests VERY welcomed) > Review pull requests that are awaiting merge > Report problems with links or styling > I'm happy to help. Ruben.

1 0

Help Boost, Please!
by Louis Tatta 24 Apr '23

24 Apr '23

To improve Boost we are writing new documentation for the website, divided into four documentation projects: User’s Guide https://docs.cppalliance.org/doc/user-guide/ Contributor’s Guide https://docs.cppalliance.org/doc/contributor-guide/ Formal Review Manual: https://docs.cppalliance.org/doc/formal-reviews/ Release Process Book https://docs.cppalliance.org/doc/release-process/ (“develop” branch versions of these docs can be viewed at the corresponding https://stage.docs.cppaliance.org URL). The source code repository for the documentation is located here and will be moved to the Boost organization after final approval: https://github.com/cppalliance/site-docs Peter Turcan is a new face at The C++ Alliance but a veteran at Technical Writing. He needs your help to make these pages shine. Specifically, we need volunteers for the following: Check the documentation for accuracy Make suggestions for improvements or changes Contribute directly to the documentation (pull requests VERY welcomed) Review pull requests that are awaiting merge Report problems with links or styling Issues can be opened against the documentation for anything at all by pressing the “Report an Issue” button located at the top right of every documentation page, or simply by visiting https://github.com/cppalliance/site-docs/issues The more that people help out, the better the results will be. Note that the current stylesheets for these documentation pages are using the “Antora default UI” but before this goes on to https://www.boost.org it will be restyled to match the look and feel of the site. If you wish to help out please respond to this message on-list so that others know you are pitching it, that we might get a snowball effect. Best Regards, Louis Tatta The C++ Alliance

1 0

Re: [boost] multiprecision issues
by John Maddock 23 Apr '23

23 Apr '23

On 22/04/2023 22:48, Gero Peterhoff via Boost wrote: > Hi John, > i stumbled over some more issues https://godbolt.org/z/x5srG9eof : > - the unary operator- does not work with > boost::multiprecision::cpp_bin_float_N on nan > - operator<<(boost::multiprecision::float128) does not support > std::showpos with std::hexfloat > - operator<<(boost::multiprecision::cpp_bin_float_N) does not support > std::hexfloat and in the case of nan does not support std::showpos > > I also miss C++17 from_chars/to_chars. > I realize that this is extremely tedious work, but multiprecision > should be as compatible to the standard as possible. > If you want, I'll be happy to look for various issues and report them > to you, but you'll have to fix them yourself. Can you please report these as separate issues on github (https://github.com/boostorg/multiprecision/issues) so we have something to track? Thanks! John.

1 0

multiprecision issues
by Gero Peterhoff 22 Apr '23

22 Apr '23

Hi John, i stumbled over some more issues https://godbolt.org/z/x5srG9eof : - the unary operator- does not work with boost::multiprecision::cpp_bin_float_N on nan - operator<<(boost::multiprecision::float128) does not support std::showpos with std::hexfloat - operator<<(boost::multiprecision::cpp_bin_float_N) does not support std::hexfloat and in the case of nan does not support std::showpos I also miss C++17 from_chars/to_chars. I realize that this is extremely tedious work, but multiprecision should be as compatible to the standard as possible. If you want, I'll be happy to look for various issues and report them to you, but you'll have to fix them yourself. cu Gero

1 0

Re: [boost] ccmath::copysign/signbit
by Matt Borland 22 Apr '23

22 Apr '23

Gero, > 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) I think you are conflating signbit and copysign here. Copysign is to return the magnitude of the first argument (which by definition is the absolute value) with the sign of the second argument. We use signbit in the implementation of this because copysign can be used to manipulate the signs of NaNs. > 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. You will find implementations of IEEEl2bits here https://github.com/boostorg/math/blob/develop/include/boost/math/ccmath/sig…. They account for 64, 80, and 128 bit long doubles based on LDBL_MANT_DIG and LDBL_MAX_EXP. If for instance you use compiler flags on GCC to alter the size of a long double those macros are changed accordingly. > PS > gcc13 is about to be released (https://gcc.gnu.org) so it is high time to support std::floatN_t as well. Yes, the release of GCC 13 is scheduled for next week. Once it’s available for download I will open issues/PRs to fix any breakages that come from the new types. In the interim I believe, but cannot confirm that if you use a policy that disables promotion you should be fine. Matt

2 1

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