- Boost - lists.boost.org

Potential Launch of Boost Website: Request for Final Feedback
by Louis Tatta 17 Feb '24

17 Feb '24

Louis here from the C++ Alliance. With the potential launch of the new Boost website on the horizon this week, we're making a final call for your feedback. Your insights a few months ago were incredibly helpful, and as we approach the launch, we'd value your final review. If you have a moment to look over the site again and note any issues or suggestions, it would be of great help. Feedback can be submitted on our GitHub issues page: https://github.com/cppalliance/temp-site/issues. Thank you for your ongoing support and contributions to the Boost community. Looking forward to your feedback. Best regards, Louis C++ Alliance

18 79

Re: [boost] New Website Repositories
by Glen Fernandes 16 Feb '24

16 Feb '24

On 2024-02-16, Vinnie Falco wrote: > On Fri, Feb 16, 2024 at 12:33, Glen Fernandes wrote: > > If you want to follow the tradition of source files, the easiest > > convention to follow is to state that your files, e.g. > > > >  > > We can do that, or alternatively is it possible to just plop a LICENSE > file at the root of the repository? I would prefer both (thanks). Glen

1 0

New Website Repositories
by Vinnie Falco 16 Feb '24

16 Feb '24

All: The contribution of a brand new, mostly complete website at the level of quality of what we at The C++ Alliance have developed (see https://preview.boost.org) is a rare event. We are proud to share this special moment in Boost history. As is the Boost tradition we propose to do the following: * Transfer of all website related repositories to the Boost GitHub organization (these will also be renamed to something sensible): https://github.com/cppalliance/temp-site https://github.com/cppalliance/temp-site-documentation https://github.com/cppalliance/site-docs https://github.com/cppalliance/boost-mailman ...plus any other miscellaneous necessary repositories that Sam has created for the administration of the website, mailing list, and release process. * Whatever is the appropriate license for the artwork to be used on the website, with copyright to "The C++ Alliance, Inc. (https://cppalliance.org)" With respect to the artwork licensing, I have to admit I am not an expert so we will work to find out what the proper solution is. Thanks

3 3

Slack Workspace Link
by Spencer Strickland 16 Feb '24

16 Feb '24

Hi all - I’ve submitted a pull request to add the Official C++ Language Slack Workspace link to the website, can someone please merge this? https://github.com/boostorg/website/pull/815 Adding Slack link by 4down · Pull Request #815 · boostorg/website github.com Thanks, Spencer

2 1

Proposal to make Boost easily citable in academic works with Zenodo
by Hans Dembinski 15 Feb '24

15 Feb '24

Dear all, Nick Smith, an academic colleague, approached me with the question of how to cite Boost in academic works. As far as I am aware, we don't have a policy on that. Here is a proposal, mainly directed towards the admins of the Boost super-project on Github. Since a few years now zenodo.org <http://zenodo.org/> provides an easy to make software citable without requiring us to publish a paper in some journal. You can just sign in to Zenodo with your Github account and enable your repositories. On the next release, a Zenodo entry will be automatically generated, that academics can then cite easily. The procedure (with pictures) is explained here: https://inbo.github.io/tutorials/tutorials/git_zenodo I use Zenodo since a while for my scientific Python libraries and it works well. Once you set it up, it is a maintenance-free solution. It would be great if the admins of https://github.com/boostorg/boost would set this up for the Boost super-project, so that all of Boost becomes citable on the next release. Best regards, Hans

2 2

Preview Site Link for Boost Website Feedback
by Louis Tatta 13 Feb '24

13 Feb '24

In my last email, I forgot to include the preview link for the new Boost website. Here it is: https://www.preview.boost.org/ <http://preview.boost.org>. Please take a look and report any feedback or issues on our GitHub page: https://github.com/cppalliance/temp-site/issues. Thanks for your help. Louis C++ Alliance

3 3

Should boost::core::string_view be made public?
by Дмитрий Архипов 08 Feb '24

08 Feb '24

boost::core::string_view is a string_view implementation that (unlike boost::string_view from Utility) can interconvert with std::string_view. This functionality was necessary for Boost.JSON to drop the standalone mode, because people who have access to C++17 prefer to use std::string_view wherever they can. At the time there was no consensus on whether the type should be made public. Now in addition to Boost.JSON the type is also used at least by Boost.URL. And recently added Charconv is also using it. So, I want to raise the question again: should we make the type public and refer to it directly in our libraries' docs, rather than considering it an implementation detail?

5 21

Re: [boost] [Scope] Peer review conclusion
by Andrey Semashev 06 Feb '24

06 Feb '24

On 2/6/24 22:29, Дмитрий Архипов wrote: > Looks good to me. I consider the review conditions satisfied. Thank you Dmitry. And especially for taking the time to review the documentation and point out errors. > пн, 5 февр. 2024 г. в 03:47, Andrey Semashev <andrey.semashev(a)gmail.com>: > >> >> On 1/15/24 22:50, Дмитрий Архипов via Boost wrote: >>> Dear Boost community, the formal review of Boost.Scope has taken place >>> between 26th of November and 5th of December of the previous year. I >>> have received 5 reviews in total, including 4 here on the mailing list >>> and 1 on Reddit. Two of the reviews recommended unconditional, and 3 >>> conditional acceptance. The >>> reviews came from: >>> - Klemens Morgenstern, >>> - Janko Dedic, >>> - Julien Blanc, >>> - David Sankel, >>> - /u/jonesmz on Reddit. >>> >>> Also, several people have given insightful comments but did not provide a >>> review. I would like to thank all of the people who took their time to write >>> reviews or participate in the discussions. Your effort was very important and >>> valuable. >>> >>> The outcome of the review is that Boost.Scope is ACCEPTED with several minor >>> CONDITIONS. >>> >>> 1. noexcept specification on destructors of scope guards should be properly >>> documented. Andrey has already commented that the technical hurdle that >>> prevented it was eliminated. >>> >>> 2. There should be a good motivating example for scope_success. There was a lot >>> of comments regarding scope_success and its seeming uselessness. Without a >>> good example I see the same pattern occurring with future users. >>> >>> 3. The examples should better describe what they are trying to achieve. Several >>> comments about examples suggested incorrect changes, which signals that readers >>> failed to understand them. >>> >>> After a lot of consideration I decided against requesting the author to remove >>> unique_resource and related functionality from the library. While several >>> reviewers wanted a more "concise" library, all noted that the component is >>> useful. >>> >>> One last thing I wanted to point out is that all reviewers and most commenters >>> were adamant that compatibility with the Technical Specification on which this >>> library was initially based should not be a goal. In fact, Andrzej Krzemienski >>> even noted that such compatibility has prevented him from adequately evaluating >>> the library on its own merit. In my opinion this should be a sign to all of us >>> that people prefer better APIs over standard APIs. I recommend Andrey to >>> re-evaluate those parts of the library's APIs that he copied from the TS and >>> potentially pick better names for member functions. >>> >>> Thanks to Andrey for submitting this library to Boost. And thanks again to the >>> reviewers and everyone who provided feedback, who ultimately made this review >>> possible. >> >> I have updated the library according to review comments and conditions. >> To specifically address the acceptance conditions: >> >> 1. Noexcept specifications for destructors are now present in the docs. >> For example: >> >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/defer_guar… >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_exit… >> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/unique_res… >> >> The fix for the BoostBook stylesheets is currently in develop. >> Hopefully, it will get merged to master soon. >> >> 2. I have added an example showing usage of all three conditional scope >> guards, including scope_success, here: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> The example is based on the one I posted during the review. >> >> 3. I have added more comments to some examples, as well as the >> discussion around them. For example, the examples on the front page are >> better commented now: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> Some examples were modified or completely rewritten. For example, the >> locked_write_string was modified to reduce code duplication: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> The leading example for unique_resource was rewritten: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> >> And a new example for unique_resource was added on the front page: >> >> https://lastique.github.io/scope/libs/scope/doc/html/index.html >> >> There are many more additions and modifications than I can mention here. >> >> >> There were also changes that were requested by reviewers or were the >> result of the discussion. The changelog here lists most of the changes: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/changelog.html >> >> To mention the most prominent changes: >> >> * BOOST_SCOPE_FINAL was renamed to BOOST_SCOPE_DEFER and scope_final to >> defer_guard. >> * The `release()` member of scope guards was removed. `set_active()` is >> still present and is the way to activate and deactivate scope guards. >> * Added `operator bool()` to `unique_resource`. >> * Added a C++17 `unallocated_resource` class template that simplifies >> declaration of resource traits when all unallocated resource values can >> be listed. Along with the recently added to Boost.Core `functor` >> template, this can significantly reduce the amount of code one needs to >> write to declare a `unique_resource`. For example, a `unique_resource` >> for Windows handles could be declared like this: >> >> unique_resource< >> HANDLE, >> functor< CloseHandle >, >> unallocated_resource< INVALID_HANDLE_VALUE, (HANDLE)NULL > >> > handle; >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> https://www.boost.org/doc/libs/develop/libs/core/doc/html/core/functor.html >> >> * `unique_resource` now enforces requirements on the resource traits >> with static asserts rather than falling back to the "no resource traits" >> mode of operation. >> * `unique_resource` no longer supports the "reduced" resource traits, >> where the traits were only used to customize the default resource value >> but not to distinguish allocated and unallocated resource values. >> * Added documentation sections discussing differences with the Library >> Fundamentals TS: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> https://lastique.github.io/scope/libs/scope/doc/html/scope/unique_resource.… >> >> * On the front page, removed comparison with Boost.ScopeExit from the >> table. There is a separate section for it: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> Also added another row to the table that shows explicit deactivation of >> the scope guards by calling `set_active(false)`. >> >> * There is now a section discussing caveats of capturing variables by >> reference in scope guards: >> >> https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.htm… >> >> There are probably other changes that I forgot to mention. >> >> >> Dmitry, please let me know if you consider the review conditions >> satisfied or if there needs to be done something more. >> >> If everything's fine, what needs to be done to move the library into >> boostorg? >>

1 0

Re: [boost] critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

> So what's your point? Another example. I had asked for a TypeTrait is_integer and also supplied code for it (https://github.com/boostorg/type_traits/issues/186) The point is that is_integer only returns integer (no character, no bool). John immediately closed my request "We are not responsible for that". Instead of admitting a mistake (of course I make some myself) and saying "we forgot/didn't think of it, we'll do it", the only answer is "we don't care". That's thinking from the wallpaper to the wall. As I said, boost used to be progressive, but now when you make a suggestion, all you get is "We're not responsible for that/we're not interested in that/we might have to change something that's not possible" And this even with such a simple TypeTrait. Single file. No dependencies. And on the other hand, libraries with the most severe buffer overflows (charchonv) are included, where obviously no tests are carried out at all.

5 5

Re: [boost] critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

> So what's your point? a) boost/math/policies/error_handling.hpp manual name_of, although it would be no problem to add a simple nameof in boost/core/demagle.hpp: template <typename Type> inline std::string nameof() { return demangle(typeid(Type).name()); } b) boost/math/policies/policity.hpp manual "variadic templates" c) boost.convert (apart from the fact that this library is unusable due to its design) - no C++23 FP types - no (unsigned)__int128 - no __float128 These are just the things that came to my mind. The whole design and supported types of boost is stuck 25 years ago. As I said, I'm grateful that boost made C++11 possible. But since then you are stuck at this level and changes are *not* welcome.

2 1