- Boost - lists.boost.org

(no subject)
by Suraj Nehra 28 Mar '21

28 Mar '21

Hi, I am Suraj Nehra, a pre-final year student at the National Institute of Technology (NIT), Warangal, India. This mail is to introduce myself to the boost community. Boost.Real is not added to boost project ideas page yet but I was discussing ideas with Vikram(vikram2000b(a)gmail.com) and also made several contributions to the library. I wish to work on this library in this GSoC and will start drafting the proposal. I received the competency task from Vikram and will start working on those. I was informed of the following potential ideas by him: 1. Library comparison and benchmarking with other similar libraries. 2. DAG internal representation 3. Propose and implement optimizations for trigonometric functions. I wish to work on ideas 1 and 3. I will start making the proposal for these ideas and share the draft with you. It will be a pleasure to hear any suggestions and guidance from you. Thanks & Regards Suraj Nehra

1 0

To contact project's mentor for GSoC21
by prince raj 26 Mar '21

26 Mar '21

Hello, My self Anish Kumar Singh and I want to participate to in boost organisation. But I have no idea how to contact mentor for project discussion and my ideas with him. So please help me contacting to mentor so that I can make my proposal good to summit. Thankyou...

3 2

[Boost] [Describe] Summary Review Summary
by Richard Hodges 26 Mar '21

26 Mar '21

Boost Describe Review Summary Boost Describe was submitted by Peter Dimov. The review period lasted from 1st March 2021 until 10th March 2021, inclusive. Overall Verdict Boost.Describe has been accepted into Boost. Detailed Results In all, 13 people submitted reviews. Of these 13, 11 reviews were an unconditional ACCEPT. The remaining two reviews were marked CONDITIONAL ACCEPT. This seems to be common practice, as committing firmly to accept or reject can seem like a bold position either way. However the Boost review process has no provision for attaching conditions to library acceptance. The verdict must be either that the library is sufficiently well written and documented, as well as providing sufficient utility, to be included in the Boost offering, or it is not. Conditional Acceptances In this review I counted the two remaining conditional acceptances as ACCEPT, and decided to pass the conditions as comments/suggestions on to the author for consideration, as well as enumerate them in this report in the hope that further study/debate is stimulated. Libraries evolve over time, and the comments will no doubt be useful to Peter when making future decisions about Boost.Describe. I will deal with the conditions mentioned by Julain Blanc first. Julian’s concerns centered around the fact that the bitfield supplied to the describe_members macro is not additive. I will quote his example here. Given the following code: struct C { int a; std::string b; double c; void f(float a, int b) { } void g() { } static void s() {} private: int p_; void h_(std::string const& s) {} BOOST_DESCRIBE_CLASS(C, (), (a, b, c, f, g, s), (), (p_, h_)) }; I would expect the following: static_assert(mp_size<describe_members<C, mod_public>>::value == 6); static_assert(mp_size<describe_members<C, mod_private>>::value == 2); That's not the case. Instead, the results are resp 3 and 1. By default, only data members are returned, not member functions. So, let's try another one. I want all my member functions: static_assert(mp_size<describe_members<C, mod_function | mod_public | mod_protected | mod_private >>::value == 4) --> fails. By default, it only returns non-static functions. So, let's try to include static function as well: static_assert(mp_size<describe_members<C, mod_static | mod_function | mod_public | mod_protected | mod_private >>::value == 4) That also fails. The result is one, now i only get the static functions. It looks that there's a mix of apples and orange in this enum. Some values acts as they will include more data in the results, some on the contrary will filter, and some will change completely the type of the members enumerated. This concern resonates with me, as I raised a similar (but less well written) query with Peter in the same area. Barrett Adair was the author of the second conditional accept. His reasoning was along the same lines as Julian’s, quoted: I don't like that I need to call describe_members multiple times to get static, non-static, data, and functions. I would appreciate the addition of mod_data and mod_nonstatic to keep the flags consistent. This is my only acceptance condition. Peter took time to respond to this concern: The reason the static/nonstatic and data/function members are returned separately is that the type of `pointer` changes. For nonstatic data, it's M T::*. For static data, it's M*. For nonstatic function, it's R (T::*)(A...). For static function, it's R (*)(A...). Since one typically does things with `pointer` in the loop over members, it's rarely the case that you want all of these at once, because the syntactic form of the code manipulating them changes. So I've found it in practice more convenient to separate them by default. It is fair to say that in less recent variants of C++, iterating over different pointer types would be problematic, although arguably less so with later variants of C++ if some accessor function template overloads or CPOs were made available in the library. The decision on whether this should be explored rests with Peter. Documentation and Examples Reviewers almost universally commented on the quality and completeness of the documentation. Particular attention was drawn to the numerous examples that clearly represent common real-world use cases. Features Requested Rainer Deyke requested the ability to annotate members with further attributes. Peter responded that he would look into whether this was possible while retaining compatibility with likely future standards adoptions of reflection, which is a design goal of the library. Maximilian Riemensberger wondered whether it would be possible to support reference members and overloaded functions. Peter’s response was that alas, no. The language itself is a limiting factor there. Maximilian also requested the ability to annotate enums with associated data. For example, representing an enum value as text when the text cannot be reasonably computed from the value’s symbolic name. Peter agreed to consider this further. Maximilian also touched on the single-pass iteration issue, which brings the number of observers who feel there is good grounds for future evolution to four. Overall Usefulness of the Library The reviewers were unanimous in calling out the need for this kind of library. From reading the reviews it is apparent that a great deal of developer effort is duplicated in writing custom reflection mechanisms. It struck me that (any kind of) language-level compile-time reflection would be welcomed with open arms by the developer community. Perhaps we can hope that the acceptance of Describe into Boost and its subsequent use can inform and encourage the C++ language group to bring something to the community sooner than later. Please join me in extending gratitude to Peter, who has taken time and painstaking effort to present us with such a useful, succinct and well documented library. Please also join me in thanking the reviewers, who can be sure that the detailed analysis included has been read and in for the most part, already elicited a response/bug-fix from Peter. Sincerely, Richard Hodges -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 mobile: +376380212

12 31

C++17 and "Alice in Wonderland"
by Edward Diener 24 Mar '21

24 Mar '21

I apologize for this non-Boost related post, but I ran into what I thought was a C++17 bug in clang ( also in vc++14.2 C++17 ), whose explanation to me of why it is not a bug really sounds like the non-logic of "Alice in Wonderland". I am not putting down the person who explains to me why it is not a bug in any way, as I know he is a C++ expert, but if this is really C++17 something must be wrong with my admittedly limited understanding of C++ and where it is going. My bug report is at https://bugs.llvm.org/show_bug.cgi?id=49684 and the explanation given there just eludes me as to what C++17 is doing, as my further comments makes apparent. Does anyone actually understand how this can possibly be ? How does C++17 apparently deduce a template argument different from what the actual type is and than declare therefore a mismatch ? This is really something from another world. My apologies for bringing this up in Boost, as it is purely a C++ issue, but my original problem comes from something I have been working on in the hopes it might eventually be a Boost library, so I decided to see if any of the expert Boost contributors might know what is going on in C++17. I realize that if everyone did as I have done here the mailing list would be a mass of irrelevant posts not Boost related.

9 11

Boost 1.76 beta - linking error when including Boost
by Luigi Ballabio 24 Mar '21

24 Mar '21

Hello, I'm afraid I don't have a minimal example yet, but I thought I'd give you a heads-up in case it rings a bell. I've been trying the Boost 1.76 beta to build a library I'm maintaining. The library builds, but when I link it to an executable I'm getting an "undefined reference to `bool boost::math::isnan<long double>(long double)". Everything works with 1.75 and earlier. My code is not using boost::math::isnan directly, so I'm guessing some other included boost component is forward-declaring it or doing something similar? The linking error disappears if I include <boost/math/special_functions/fpclassify.hpp> in a config file that is included by every file in the library. Today I'll try to pinpoint the problem by removing it there and including it before specific boost headers in the source files, but as I said, I'm posting this in case someone already has an idea about the underlying issue. Thanks, Luigi

3 4

Any Interest in a port of ZLib to C++?
by Vinnie Falco 24 Mar '21

24 Mar '21

Beast currently has its own port of ZLib to C++: <https://github.com/boostorg/beast/tree/develop/include/boost/beast/zlib> Is there any interest in having this proposed as its own separate Boost library (with a separate review, which has nothing to do with Beast)? The differences would be as follows: * Ported to use C++11 idioms * Same header-only / compiled source model as Boost.JSON * Better documentation and clear API * Improved tests Programs which use this C++ port of ZLib would get their zlib dependency from Boost instead of the official zlib distribution. And they can integrate it into their projects the same way that Boost libraries are integrated. Or they can include <boost/zlib/src.hpp> in any one translation unit (like JSON). The motivation for this is twofold: * Provide an easier way for users to access ZLib's functionality * To use this in some new libraries that I'm going to propose -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 14

[Boost.JSON] Security Review
by Vinnie Falco 23 Mar '21

23 Mar '21

As part of our commitment to producing the very finest C++ libraries that application developers can trust, the C++ Alliance has commissioned Bishop Fox to perform a security audit of the Boost.JSON library. The report is linked here: <https://cppalliance.org/pdf/C%20Plus%20Plus%20Alliance%20-%20Boost%20JSON%2…> This will report will be published starting in Boost 1.76.0 -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

boost library incubator planning shutdown
by Robert Ramey 22 Mar '21

22 Mar '21

I had high hopes for the boost library incubator when I made it. But I think it's pretty clear that those hopes haven't been realized. Maintaining and Enhancing this website required more effort than I had anticipated so it hasn't evolved. I do notice that people do use it from time to time (a couple hundred page hits/day), so it's not totally dead. But it would either have to go forward or be shut down. If someone wanted to take it over that would be fine. But I don't expect anyone to come forward so I'll be shutting it down probably in the next 30 days or so. Robert Ramey

1 0

Mentor application for Boost.Real
by Vikram Chundawat 21 Mar '21

21 Mar '21

Hello everyone, I am Vikram Singh Chundawat, I worked on Boost.Real previous GSoC and I am actively working on the library since. Now, one of the potential mentors Damian Vicino is not mentoring this year, I wish to mentor this project in GSoC 2021 with Laouen Belloli. We have some potential candidates who are working on the library and also some good ideas for the library. The aim last year was to bring Boost.Real to review ready state and some work is still remaining to make it review ready, we found some bugs in the review. Now, we are working on optimizations, bug fixes, and benchmarking. I went through the guidelines of Google and wish to know the procedure for mentor application. Thank You Regards Vikram Singh Chundawat

2 1

Proposing a library to include in Boost
by Mohit Saini 20 Mar '21

20 Mar '21

Hi, This is Mohit Saini. I developed a lazy_map library, whose interface is similar to std::unordered_map but lazy_map is O(1) copiable. Other operations like Deletion, Lookup, Insertion etc. continue to cost O(1).. which also implies that lazy_map is not a simple cow_wrapper<std::unordered_map> .. lazy_map is way more clever than that. Learn more at : https://github.com/tinytrashbin/lazy_map Specially, checkout the section which explains the "Fragment" tree. Lazy_map is heavily used in our codebase for taking snapshot of a very large state ( of size ~ 5 GBs), enabling "fork" of a snapshot in O(1) time for further modification in the forked snapshot, allowing a large number of threads to operate on different snapshots of very large size, concurrently without interfering with each other where each of the thread is even "writing" to their snapshot. I believe such a utility will be very helpful for others too. I'm looking for boost-maintainers who can review and suggest what all I need to do so that lazy_map can be accepted in Boost. Thanks -- Mohit Saini

1 0