- Boost - lists.boost.org

Re: [boost] The standard library is better documented
by Niilo Huovila 05 Dec '23

05 Dec '23

On 12/5/23 1:43 AM, boost-request(a)lists.boost.org wrote: > Date: Mon, 4 Dec 2023 12:36:27 > -0800 From: Marshall Clow <mclow.lists(a)gmail.com> To: > boost(a)lists.boost.org Subject: Re: [boost] The standard library is > better documented Message-ID: > <B135B251-3578-40CA-A9D8-34E165EE6C14(a)gmail.com> Content-Type: > text/plain; charset=utf-8 On Dec 4, 2023, at 12:21 PM, Mateusz Loskot > via Boost <boost(a)lists.boost.org> wrote: >> On Mon, 4 Dec 2023 at 21:05, Niilo Huovila via Boost >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >>> On 12/4/23 4:36 PM, Hans Dembinski wrote: >>>>> On 2. Dec 2023, at 16:57, Ren? Ferdinand Rivera Morell via Boost<boost(a)lists.boost.org> wrote: >>>>> >>>>> It would be useful if you could point to instances of Boost libraries >>>>> that could use better documentation. >>>> Can we organise a user poll that ranks all Boost libraries on how well documented they are? >>>> >>>> Might be a fun way to approach this and it provides an opportunity to create some publicity for Boost when we advertise this. I can see the news headline: "Boost devs finally respond to user cries for better docs" >>> The secret of cppreference seems to be that it is a wiki. How about >>> that? Users could put their energy to improving the docs instead of >>> complaining. :) >> Users can already do that by submitting pull requests on GitHub. > Or, if they don?t grok Quickbook, they can open a GitHub issue and suggest better wording. They seem relatively heavy-handed ways to add a link or correct spelling. > Date: Tue, 5 Dec 2023 00:12:17 +0300 > From: Andrey Semashev<andrey.semashev(a)gmail.com> > To:boost@lists.boost.org > Subject: Re: [boost] The standard library is better documented > Message-ID:<9e217656-9b05-4e82-a5a3-67c55d949b4f(a)gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 12/4/23 20:53, Niilo Huovila via Boost wrote: >> On 12/4/23 4:36 PM, Hans Dembinski wrote: >>>> On 2. Dec 2023, at 16:57, Ren? Ferdinand Rivera Morell via Boost >>>> <boost(a)lists.boost.org> wrote: >>>> >>>> It would be useful if you could point to instances of Boost libraries >>>> that could use better documentation. >>> Can we organise a user poll that ranks all Boost libraries on how well >>> documented they are? >>> >>> Might be a fun way to approach this and it provides an opportunity to >>> create some publicity for Boost when we advertise this. I can see the >>> news headline: "Boost devs finally respond to user cries for better docs" >> The secret of cppreference seems to be that it is a wiki. How about >> that? Users could put their energy to improving the docs instead of >> complaining. :) > Wiki is prone to vandalism and edit wars. > > Also, aside from stylistic and wording edits, the documentation is > supposed to be written by people who are very knowledgeable in the > subject. Those people are likely very few, often maintainers only. > > Wiki is good for "public knowledge" kind of documentation. The official > library documentation is very different from that. In fact, it is the > ground truth upon which that public knowledge is built. Would separating the reference from other documentation also separate it from those concerns? Then it could be a wiki and editing the other stuff can be restricted to maintainers.

1 0

[scope] some more thoughts
by Andrzej Krzemienski 04 Dec '23

04 Dec '23

Hi Everyone, I want to share some thoughts regarding the review of Boost.Scope. The fact that it wants to implement 1-to-1 a feature from a TS -- not from the standard -- impedes the review process. The reviewer says, "this feature is bad". The author responds, "but this is how the TS requires it to be". And now what? Should we accept a bad feature because the TS requires so? Being TS-conformant is very constraining for the author. Maybe this is not a worthy goal. Also, my observation from recent years is that putting stuff into a TS may be a polite way of saying, "we respect you, but we do not want this." Also, the goal of having an implementation for a proposed feature is to check if the interface has been battle-tested to be sound. The Boost Review process is such a test. When the feedback is, this feature is wrong, then this feedback should affect the STD proposal. But Boost shouldn't be compromised by an STD proposal that was submitted without a battle-tested implementation. The move assignment operator in scope_exit and friends. It looks like its existence is against the goal of the feature. You define a guard and then you use it. Why would you assign a different guard to it? Why do we have scope_success? An alternative to using scope success is to just put your instructions at the end of the function. Do you have multiple return statements in your function and at the same time you need the same sequence of operations to be performed at each end? This is a good motivation to restructure your function to have a single return. Multiple returns are generally OK, but needing the same sequence warrants a single return. scope_success seems like a solution that is looking for a problem. "But the TS has scope_success" -- this is not a good argument for me. In Boost Review we should be evaluating a library based on its own merit, not based on a similarity with some other design, which can have its own flaws. Mixing unique_resource with scope guards is not a good idea. The STD tends to use big aggregate headers. Boost does not. The solution from the TS should not be ported 1-to-1 to Boost. Boost.Scope offers at least three ways to do the same thing. For instance, to execute some code only upon some inconvenient condition, I can use scope_fail with my condition, or scope_exit with my condition, or I can add set_active on top of either. I consider this to be a bad design. Source code is not only for the flexibility of writing, but also for the ease of reading and learning. Having multiple ways to do the same thing impedes the understanding of the code. While I understand the existence of the triplet `scope_exit`, `scope_fail` and `scope_success` (D uses an analogous triplet), it takes a while to understand the difference between scope_exit and scope_final. And the choice of name doesn't help there. The Standard library chose to use term guard (std::lock_guard) to indicate something small and cheap. Maybe use this name instead. Not perfect either, but at least consistent with what we have in STD. Also, my experience is that one uses scope guards only in rare situations where you need to satisfy complex guarantees, like maintaining the same size of two vectors. And in those situations one is already very cautious, and tries to structure the code for the minimum surprises. One does not use multiple returns or complex control flows. The justification I heard for so many features in Boost.Scope is that there may be complex situations that require it. I think that in these situations restructuring the code is better than adding more features to Boost.Scope. This looks like a lot of harsh words, but I find a subset of the library very useful: * the unconditional execution of the function * the execution based on manual deactivation (active being the initial state) * execution based on the uncaught exception count, with the caveat that it sometimes doesn't work, and it is not cheap. Regards, &rzej;

2 5

[scope] unique_resource vs unique_ptr
by Bruno Martínez 04 Dec '23

04 Dec '23

Hi, unique_ptr can emulate unique_resource: template<auto nullvalue, auto delete_> class unique { using T = decltype(nullvalue); struct generic_delete { class pointer { T t; public: pointer(T t) : t(t) {} pointer(std::nullptr_t = nullptr) : t(nullvalue) { } explicit operator bool() { return t != nullvalue; } friend bool operator ==(pointer lhs, pointer rhs) { return lhs.t == rhs.t; } friend bool operator !=(pointer lhs, pointer rhs) { return lhs.t != rhs.t; } operator T() { return t; } }; void operator()(T p) { delete_(p); } }; public: using type = std::unique_ptr<struct not_used, generic_delete>; }; int main() { using unique_fd = unique<-1, close>::type; static_assert(sizeof(unique_fd) == sizeof(int), "bloated unique_fd"); unique_fd fd1(open("fd.txt", O_WRONLY | O_CREAT | O_TRUNC)); write(fd1.get(), "hello\n", 6); } The std papers say While std::unique_ptr can be tweaked by using a custom deleter type to almost a perfect handler for resources, it is awkward to use for handle types that are not pointers. But what's the awkwardness? Kind regards, Bruno

3 2

Re: [boost] The standard library is better documented
by Niilo Huovila 03 Dec '23

03 Dec '23

On 12/3/23 3:37 AM, boost-request(a)lists.boost.org wrote: > Date: Sat, 2 Dec 2023 17:44:05 +0100 > From: Andrzej Krzemienski <akrzemi1(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] The standard library is better documented > Message-ID: > <CAOenAXhr9fu6jo7PoFC6JTKBhD7Kdw6yxWJUEFxtcPgYkujHwQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > sob., 2 gru 2023 o 17:21 Andrey Semashev via Boost <boost(a)lists.boost.org> > napisa?(a): > >> On 12/2/23 03:35, Niilo Huovila via Boost wrote: >>> By better I mean cppreference.com. There's a page for pretty much >>> everything in the standard library. Related pages are linked. The >>> preconditions and behavior of functions are specified. Consequentially I >>> come to Boost only when the standard library doesn't do enough. If you >>> are going to compete with the standard library instead of just >>> supplementing it, you need outstanding documentation. >> >> To be fair, as useful as cppreference.com is, it is not quite the same >> kind of documentation as Boost documentation is. It is mostly similar to >> the reference section that you can find in most libraries' docs, as it >> basically translates the standard wording to human language and gives a >> single usage example in the end. There is no rationale, discussion, or >> usage recommendations. It's a feature: there's a time for discussion and rationale, but not when I just want to look up something quickly. >> The unquestionable advantage of cppreference.com is that it has lots of >> cross-links, which makes it very easy to navigate and find what you're >> looking for. Cross-linking is definitely something that Boost docs could >> use more. ^ This. The easy to navigate reference is what I miss the most. Cppreference can be explored like a retailer's magazine. Items are usually sorted to categories. It makes them more discoverable. > True, but for that we would have to have a uniform documentation experience > for all the libraries. And I do not think we are ever going to get there. I agree that it's a daunting task. Actually I thought that the first reaction to my message would be pondering whether competing with the standard library is worth the effort or even feasible. I were surprised when the first reaction was asking which docs need improvement, because cppreference sets the bar so high.

1 0

Re: [boost] [scope] Scope review starts on November 26th
by Janko Dedic 02 Dec '23

02 Dec '23

Thanks for proposing this library. Scope guards are a natural and much needed addition to Boost. The following is my review of the proposed Boost.Scope. The first thing I looked for in this library was a convenience SCOPE_EXIT { ... }; macro that would provide the functionality in the form of a control flow construct. I've managed to quickly find it, but it wasn't exactly what I was expecting. BOOST_SCOPE_FINAL [] { std::cout << "Hello world!" << std::endl; }; I found it rather odd that the capture list is not included in the macro. I looked a bit further into the documentation to find this: BOOST_SCOPE_FINAL std::ref(cleanup_func); Is this use case the reason why the capture list is required? It seems like a very rare one that shouldn't pessimize the interface for 99% of use cases. Performance shouldn't be a concern because the compiler sees all this code and inlines it anyway. In my view, this just makes the interface worse and less pleasant to use. scope_success doesn't seem terribly useful. I have yet to see a legitimate use case of this type. I haven't found a motivating example in the documentation. There should either be one, or this type should be removed from the library. There is no BOOST_SCOPE_FAIL macro. Why is it missing? I found the scope_fail example pretty bad: class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }, false}; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { // Activate rollback guard rollback_guard.set_active(true); } obj->on_added_to_collection(*this); } }; It could be simply rewritten to not use set_active (which should be discouraged, because it makes code less declarative and harder to follow): class collection { std::set< std::shared_ptr< object > > objects; public: void add_object(std::shared_ptr< object > const& obj) { // Create a deactivated scope guard initially std::set< std::shared_ptr< object > >::iterator it; bool inserted; std::tie(it, inserted) = objects.insert(obj); if (inserted) { boost::scope::scope_fail rollback_guard{[&, this] { objects.erase(it); }}; obj->on_added_to_collection(*this); } } }; Could be made even cleaner by using an early return: if (!inserted) return; All destructor declarations in the documentation lack noexcept specification, which by default means that they're noexcept, but they're actually not if you look at the Throws section, or the implementation. Also, the question presents itself: why are these destructors allowed to throw? I feel like it is common knowledge today that destructors should not throw, and this is heavily frowned upon. I can see the want to "be generic" here, but I don't see why a library should entertain broken code. I also noticed that certain scope guards are move constructible. Why? I cannot imagine myself ever approving of someone moving a scope guard on code review. Scope guards are to be used exclusively as local variables and don't need to be moved. This just opens up room for misuse. I don't see any compelling use cases for scope_exit::set_active in the documentation. The only example I find motivating is this one: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); // Commit vec1 modification rollback_guard.set_active(false); } This could as well have used rollback_guard.release();. This matches my personal experience: only dismiss/release/cancel is necessary for real use cases ("commiting" something and thus disabling the "rollback" action). absl::Cleanup for example, supports only Cancel(). There is value in preventing users from shooting themselves in the foot. I don't like the name scope_exit::release personally. I feel like "dismiss" or "cancel" would be much better. I know that std::experimental::scope_exit calls it "release", but we shouldn't appeal to false authority. I did not like the locked_write_string example. Reading this code locally: // Lock the file while (flock(fd, LOCK_EX) < 0) { err = errno; if (err != EINTR) return; } it's hard to get what's happening, why we're setting err and how big of an impact that has on function behavior. A better way to write this code would be to simply extract this piece into its own function: err = errno; if (err != EINTR) return; together with the ec = std::error_code(err, std::generic_category()), which doesn't require a scope guard. fd_deleter and unique_fd provide some nice handling for EINTR, which wasn't required but I think it's nice to have and it's good that it's a part of this library! I think make_unique_resource_checked approaches the problem from the wrong direction. This code: // Create a unique resource for a file auto file = boost::scope::make_unique_resource_checked( open(filename.c_str(), O_CREAT | O_WRONLY) -1, fd_deleter()); if (!file.allocated()) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } could be this: // Create a unique resource for a file int file = open(filename.c_str(), O_CREAT | O_WRONLY); boost::scope::scope_final close_file(fd_deleter{}); if (file != -1) { int err = errno; throw std::system_error(err, std::generic_category(), "Failed to open file " + filename); } This has the advantage of being able to use `file` directly for the rest of the code instead of `file.get()`. I think a similar utility would be more useful in form of a class template, for example: resource<HANDLE, INVALID_HANDLE_VALUE, ::CloseHandle> windows_handle; resource<SDL_Window*, nullptr, ::SDL_DestroyWindow> sdl_window_handle; This would be very useful for concisely implementing RAII wrappers over C handles (you don't have to manually write destructors, move constructors and move assignment operators). For local use (within a function), I feel like a local handle + scope guard is just more ergonomic than the whole make_unique_resource_checked thing. My overall impression is that this library is trying to be too generic when it's not really necessary. There's definitely useful stuff here that I want to see included, but also a lot of stuff that is too much. I don't personally see the need for any scope guard beyond scope_exit with a release. That covers all the use cases I've ran into very nicely. scope_fail can be more error-prone since the "commit" is not explicit, so you may end up doing rollback even when it's unnecessary. Using the modified example from the documentation: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_fail rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); do_something_else(); // if this throws, rollback_guard runs } If you use scope_exit with an explicit release, it's clearer IMO: void push_back(int x, std::vector<int>& vec1, std::vector<int>& vec2) { vec1.push_back(x); // Revert vec1 modification on failure boost::scope::scope_exit rollback_guard{[&] { vec1.pop_back(); }}; vec2.push_back(x); rollback_guard.release(); // commit do_something_else(); // if this throws, rollback_guard won't run } The documentation states that "exception_checker is incompatible with C++20 coroutines", which is true in general, but it doesn't have to be (depending on the coroutine library implementation). However, I bring this up because using scope_exit+release is an entirely viable alternative for coroutines. scope_exit+release will work whether you use exceptions, error codes, std::expected, coroutines or all of them combined. This is the beauty of it, which makes me feel like scope_fail is unnecessary. I vote to ACCEPT this library with the following CONDITIONS: - BOOST_SCOPE_FINAL includes the lambda capture list OR another macro that does is provided; - noexcept specification on destructors is properly documented; - move constructors on all scope guard types are deleted; - a motivating example for scope_success is provided, or the type is removed. These are my conditions, but I'm hoping the full review is taken as a recommendation in improving the library and the documentation. Best regards, Janko Dedic

3 18

[scope] The comparison with Boost.ScopeExit is unfair
by Andrzej Krzemienski 02 Dec '23

02 Dec '23

Hi All, This is not a review yet. I am just looking at the front page of the docs, and I think the comparison with Boost.ScopeGuard is unfair. You are comparing C++03 Boost.ScopeGuard with C++11 Boost.Scope. Try comparing it with C++03 Boost.Scope. Otherwise compare C++11 to C++11, and there Boost.ScopeGuard has a nicer syntax: int compute() { // Reset variables on return BOOST_SCOPE_EXIT(this_) { this_->x = 0; this_->y = 0; }; return x + y; } Regarding the example with exceptions, nobody would use Boost.ScopeGuard like this. A robust usage is in Boost.ScopeGuard's docs: void world::add_person(person const& a_person) { bool commit = false; persons_.push_back(a_person); // (1) direct action // Following block is executed when the enclosing scope exits. BOOST_SCOPE_EXIT(&commit, &persons_) { if(!commit) persons_.pop_back(); // (2) rollback action }; // ... // (3) other operations commit = true; // (4) disable rollback actions } Which is longer, but usable in coroutines. Whereas Boost.Scope's solution is not usable in coroutines. Only after these changes are applied, I think is the comparison fair. Regards, &rzej;

2 5

Boost Culture
by Vinnie Falco 02 Dec '23

02 Dec '23

It occurs to me that newcomers to the mailing list will not have any understanding of Boost culture or its development process. For example there is a recurring theme where a new person will ask about "what documentation toolchain does Boost use." The answer of course is that every library has considerable autonomy to define how it wants to generate its documents. The only requirement is that the final result is rendered as HTML. Another example is the idea that there is a "CEO of Boost." Or rather that there are particular individuals who have some sort of decision-making authority for the entire libraries. Or another example, why we use mailing lists over dedicated forum software. We might consider putting together a document which centralizes all of the collected wisdom and knowledge about Boost culture including the history of its evolution and why some things are the way that they are. This would facilitate the entry of newcomers to places like the mailing list which assume that participants already know a lot about Boost culture. This could become a chapter in the new Contributor Guide: https://www.preview.boost.org/doc/contributor-guide/index.html Thanks

4 3

Dead Link
by Brian Salehi 01 Dec '23

01 Dec '23

There is a dead link on page [Machine Learning](https://www.preview.boost.org/doc/user-guide/task-machine-learnin… refering to Boost.uBLAS library. I guess the typo is an extra s letter after /doc which seems to point to the correct page when removed. Regards, Brian

1 0

[scope] Scope review starts on November 26th
by Claudio DeSouza 28 Nov '23

28 Nov '23

It would be helpful if the cmake build was fixed to not require some specific custom setup that was used by the author during development. The cmake list file seems to check for the existence of a cmake test file, to decide whether or not to build the tests. These files seem to have been moved outside reach of the setup in place, under test/test_cmake. Also, it would be better to get rid of this: add_subdirectory(../../../.. "${CMAKE_CURRENT_BINARY_DIR}/boost_superproject") Ideally, these cmake tests should assume scope is a submodule, or a subfolder, of the boost super project. Claudio.

4 3

[release] Boost 1.84.0 beta 1 released
by Marshall Clow 24 Nov '23

24 Nov '23

Boost release 1.84.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.84.0.beta1/source/ The SHA256 checksums are: 224d595cc666c19b91214c5e9cced3988d08063146dfad9f616c481d52626f27 boost_1_84_0_b1.zip de9b35e232e4b1769f4d800ec01255a9c2546639be43e45b16ce6d109c088e99 boost_1_84_0_b1.tar.gz f8a9f21580961536a95fb7fcf9deebde45d7e0e94ddd81402f1e37ae2c590410 boost_1_84_0_b1.tar.bz2 3e4765c41974c763b7d4a67a432569bf75d3367d7a6b72c4ac9458e5004c59dc boost_1_84_0_b1.7z Release notes (still need updates): https://www.boost.org/users/history/version_1_84_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 3