- Boost - lists.boost.org

boost::math::tools::promote_args not works with C++23 FP-types
by Gero Peterhoff 19 Feb '23

19 Feb '23

Hi, promote_args from <boost/math/tools/promotion.hpp> not works with new/extended C++23 FP-types https://godbolt.org/z/13fq8a3d7 The problem might be the outdated "manual variadic" implementation for C++03. Well, according to the documentation (https://www.boost.org/doc/libs/1_81_0) boost::math requires C++11 anyway; with a switch to C++11 it also works (std::common_type). This issue also affects some implementations in boost::math::policies. PS: We have (at least) 3 different definitions for the *same* boost::float128(_type/_t) type 1) <boost/config.hpp>: boost::float128_type 2) <boost/math/cstdfloat/cstdfloat_types.hpp>/<boost/math/cstdfloat/cstdfloat_cmath.hpp>: BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE/float128_t 3) <boost/math/tools/config.hpp>: BOOST_MATH_FLOAT128_TYPE :-( thx Gero

3 2

Mustache review has ended
by Klemens Morgenstern 19 Feb '23

19 Feb '23

The review of Mustache has ended, thanks to everyone who wrote a review! I would also like to thank the review wizards for granting the extension. That really helped to get us more reviews. I'll try to announce the review results soon, but please note that this is another close call that will need some careful consideration.

2 1

Release Notes: Markdown to replace QBK
by Vinnie Falco 18 Feb '23

18 Feb '23

We need to re-render all of this historical release notes, such as: <https://www.boost.org/users/history/version_1_81_0.html> to be in the style of the new website. This is being taken care of, but it will affect the release process as follows: * Each author will edit the release notes for their library using markdown instead of Quickbook format, as a pull request against a file here: <https://github.com/boostorg/website/tree/master/feed/history> The syntax will be GitHub flavored markdown, with a few Boost-specific extensions (for example, to link against an issue in a boostorg repo). Does anyone object or have comments about this? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 21

[mustache review] Period has been extended until the 18th
by Klemens Morgenstern 17 Feb '23

17 Feb '23

Due to the few reviews and the overlap with the WG21 meeting I have successfully petitioned the review wizards to extend the review period until next Saturday, the 18th of february. Please consider writing a boost.mustache review, since only two have been submitted up to now.

2 2

boost.mustache review reminder (ends this saturday)
by Klemens Morgenstern 14 Feb '23

14 Feb '23

This is a reminder that the boost.mustache review is currently going on and will end this saturday. Please consider submitting a review.

1 0

GSoC 2023 ideas proposals
by David Bellot 13 Feb '23

13 Feb '23

Hi everyone, Boost C++ is candidating again this year to be part of the Google Summer of Code 2023. Each year we are honoured to have students and contributors joining us for the summer and being sponsored by Google. Again, this year, I will ask for all the mentors who are interested in ... well... mentoring a student or contributor, to help us and write their ideas in this document: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2023 It will help our future students to choose, to develop their own proposal and to be part of our Boost journey. Best regards, David

1 0

[mustache] The docs
by Andrzej Krzemienski 09 Feb '23

09 Feb '23

Hi Everyone, I wanted to share my initial thoughts after reading the docs for the proposed Boost.Mustache. If some library docs said "I am implementing JSON", I more-less know what to expect, because JSON is popular, I used it, so one can reliably predict what the library delivers. This is not the case with Mustache. It is the first time I have heard this name. Apparently, it is a less popular thing. Therefore, I would expect some more introduction than just an external link. The linked page also doesn't contain sufficient information but further links. For instance to https://mustache.github.io/mustache.5.html, but this information also doesn't help me find answers to my questions: 1. What is considered an "optional part" of mustache? Boost.Mustache says it only implements the non-optional parts, but docs in mustache(5) do not indicate the optional parts. 2. It is clear to me that the procedure takes a template (with mustaches) and the data to be replaced. But what is the range of the acceptable formats of this data? The examples show that it is JSON, but does it have to be JSON? Boost.Mustache docs say it could be 'described' classes? But is that all? How about Boost.PropertyTree? What does the specification for Mustache say about it? 3. I do not see any specification (neither in Boost.Mustache docc, nor in the linked mustache(5)) for what is the required behavior when I have nested mustashes with the same name, or a JSON file with nested elements of the same name. Or did I miss this description? Regards, &rzej;

5 17

Boost.Buffers: network-agnostic buffer types and algorithms
by Vinnie Falco 07 Feb '23

07 Feb '23

Greetings. I am asking if there is any interest in a Boost.Buffers library, which consists of the following: * ConstBuffer, MutableBuffer concepts * ConstBuffers, MutableBuffers concepts * const_buffer, mutable_buffer types * DynamicBuffer concept * `source` and `sink` abstract interfaces used to define the Source and Sink concepts * metafunctions for checking all type requirements * implementations of common buffers and dynamic buffers: - buffers_pair - array_of_buffers - circular_buffer - dynamic_string_buffer * Algorithms: - buffer_copy - buffer_size The twist is that this library has no dependency on Asio or Boost.Asio (but Asio will still recognize them thanks to some template heroics and a splash of forward declarations). Why am I proposing this? Well, let me tell you some things... I am currently working on these two libraries: Boost.Http.Proto Boost.Http.Io The Proto library implements HTTP/1 to a fuller feature set than Beast and fixes all the design flaws in Beast (but it is completely not API compatible). This library does not do any network I/O, it is expressed purely in terms of buffer concepts (i.e. depends on Boost.Buffer and not Boost.Asio). The Io library depends on Asio and the Proto library to provide the network algorithms which use Asio to implement HTTP/1. This is the equivalent HTTP functionality of what Beast offers today. Websockets is not included but when I am done with Http I will redo websockets with improvements and new features, and similarly they will be developed as two libraries: Boost.Websockets.Proto Boost.Websockets.Io My motivation for splitting libraries this way is as follows: * Each library is smaller and compiles more quickly * CI turnarounds are faster * Separation of concerns The HTTP Protocol library is designed in a way that much of an application's HTTP business logic can be expressed independently of Asio using only the constructs found in Http.Proto. This especially means fewer templates and faster compilation because Http.Proto is designed from the ground up to avoid templates whenever possible. However during the development of Http.Proto I find myself having to reach for the same buffer algorithms and containers that I developed for Beast (such as the circular buffer and the dynamic buffer). So Http.Proto has been steadily growing these things: <https://github.com/CPPAlliance/http_proto/blob/a3a284f06597ad12ca6cc1782beb…> Extract this independent buffer functionality into a separate library Boost.Buffers would bring these benefits: * Again a smaller library, faster compilation * Faster CI turnarounds * Separation of concerns Additionally, algorithms can be expressed in terms of asio-independent buffer types and concepts. For example, Boost.JSON could implement the boost::buffers::sink and boost::buffers::source interfaces which would enable its use in Boost.Http.Proto and Boost.Requests (an upcoming HTTP client library from Klemens), without having to depend on either of those libraries or Asio. Is this style of development of smaller, fine grained libraries that separate concerns something that is desirable for Boost? Glad for any feedback. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 29

Interest in cpp-member-accessor?
by Hans Dembinski 07 Feb '23

07 Feb '23

Dear all, Hubert Liberacki wrote this library https://github.com/hliberacki/cpp-member-accessor that uses a loophole in the C++ standard which allows one to access private members and methods in classes in external libraries that are not under the control of the library author. Since the loophole is legal, it works with all major compilers and on all platforms. No special compiler flags required nor illegal macros like #define private public. I think this should be integrated in Boost, is there interest other from myself? Before you say it is evil, consider all the good that can be done with this in responsible hands. You can add serialisation support to classes that you do not control and you can write efficient Python bindings. I have used this library now in three projects. I used it to add serialisation support and to provide memory views of C++ structures in Python (via the Numpy module), both wouldn't have been possible to do or not would not have been efficient without this. It is a single-header library with 85 lines of code, some of which are comments. This seems a bit small for a separate library, but I am not sure where it would fit in. Best regards, Hans

3 4

[ublas][odeint] PR merge questions
by Antony Polukhin 06 Feb '23

06 Feb '23

Hi, 1) What is the status of adding CMakeLists.txt to ublas and odeint libraries? That file are essential for using Boost in big companies. Especially it is crucial for integrating Boost into buld systwms other that b2. I see there is a https://github.com/boostorg/ublas/pull/142 but no actions for a year. Please, just merge it. 2) Please, merge the fix https://github.com/boostorg/ublas/pull/153 3) Please, merge the fix https://github.com/boostorg/ublas/pull/153 There are many other PR waiting for merge. I do realise that the maintainers could be short on time. May be there are some developers that you trust and write permission could be given to them?

1 0