- Boost - lists.preview.boost.org

Re: [boost] [scope] Proposing Boost.Scope
by Darrell Wright 22 Mar '23

22 Mar '23

One thing I learned in my own replacement is that exit_success is heavily penalized on MSVC, even when there is no possible exception, because of the call to uncaught_exceptions that isn’t optimized. It’s a good thing to document, if not already, as it is surprising. Darrell > On Mar 21, 2023, at 21:41, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > I'm proposing a Boost.Scope library for review and potential inclusion > into Boost. > > Boost.Scope is a small library implementing utilities defined in > <experimental/scope> from C++ Extensions for Library Fundamentals v3 > with a few extensions. Namely, the library contains: > > * A number of scope guards for various use cases. > * A unique resource wrapper that automatically frees the resource on > destruction. > * Utilities for wrapping POSIX-like file descriptors in the unique > resource wrapper. > > Compared to <experimental/scope>, some notable extensions are: > > * A new scope_final scope guard, which is a more lightweight alternative > to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that > allows to simplify scope guard declaration syntax. > * Scope guards can be activated/deactivated multiple times. > * Scope guards can be created inactive initially. > * Scope guard factory functions, for compatibility with C++11. > * Support for optional resource traits in unique_resource wrapper, which > improves usage with resources having unallocated values. > * unique_resource supports swapping. > * unique_resource supports dereferencing for any resource types that > support dereferencing, not only pointers. > * More flexible constructors for unique_resource. > > The library requires C++11 at the minimum and will significantly benefit > from C++17. > > Source: > > https://github.com/Lastique/scope > > Docs: > > https://lastique.github.io/scope/libs/scope/doc/html/index.html > > Current state: Feature complete, tested in the CI. > > I'm asking for a review manager and endorsements. > > I'm also looking forward for any pre-review comments. In particular, I'm > interested in community opinion on the following: > > * Is there interest in this library at all? > * Should it be merged with Boost.ScopeExit, which is currently > unmaintained? More on this below. > * Should some/all of the library components be lifted to namespace > boost? Such is the practice with most vocabulary types in Boost, e.g. > boost::atomic, boost::shared_ptr, boost::any, boost::string_view, etc. > Currently, the library defines its names in namespace boost::scope. > * Comments on the resource traits feature are especially welcome. > > Re. Boost.ScopeExit. There is significant functionality overlap with it > in the scope guards department. The docs contain comparison with it. I > believe there is room for both libraries because Boost.ScopeExit > supports C++03 and Boost.Scope provides better syntax and more features, > and both can be useful in their own regards, although I expect > Boost.Scope to be more appealing in newer code bases. However, if the > community decides there's too much overlap, I'm not opposed to merging > the two libraries, although Boost.ScopeExit currently depends on > Boost.Function, Boost.Preprocessor and Boost.TypeOf, which are > unnecessary for Boost.Scope. > > Thank you. > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 22 Mar '23

22 Mar '23

On Mar 21, 2023, at 6:34 PM, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > I would like to ask permission to merge this minor fix: > https://github.com/boostorg/beast/pull/2659 <https://github.com/boostorg/beast/pull/2659> > If the tests have cycled, and you’re happy with the results, then go ahead. — Marshall

1 0

[scope] Proposing Boost.Scope
by Andrey Semashev 22 Mar '23

22 Mar '23

Hi, I'm proposing a Boost.Scope library for review and potential inclusion into Boost. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. Compared to <experimental/scope>, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource. The library requires C++11 at the minimum and will significantly benefit from C++17. Source: https://github.com/Lastique/scope Docs: https://lastique.github.io/scope/libs/scope/doc/html/index.html Current state: Feature complete, tested in the CI. I'm asking for a review manager and endorsements. I'm also looking forward for any pre-review comments. In particular, I'm interested in community opinion on the following: * Is there interest in this library at all? * Should it be merged with Boost.ScopeExit, which is currently unmaintained? More on this below. * Should some/all of the library components be lifted to namespace boost? Such is the practice with most vocabulary types in Boost, e.g. boost::atomic, boost::shared_ptr, boost::any, boost::string_view, etc. Currently, the library defines its names in namespace boost::scope. * Comments on the resource traits feature are especially welcome. Re. Boost.ScopeExit. There is significant functionality overlap with it in the scope guards department. The docs contain comparison with it. I believe there is room for both libraries because Boost.ScopeExit supports C++03 and Boost.Scope provides better syntax and more features, and both can be useful in their own regards, although I expect Boost.Scope to be more appealing in newer code bases. However, if the community decides there's too much overlap, I'm not opposed to merging the two libraries, although Boost.ScopeExit currently depends on Boost.Function, Boost.Preprocessor and Boost.TypeOf, which are unnecessary for Boost.Scope. Thank you.

1 0

Re: [boost] Master branch is now open for bug fixes
by Klemens Morgenstern 22 Mar '23

22 Mar '23

I would like to ask permission to merge this minor fix: https://github.com/boostorg/beast/pull/2659 On Wed, Mar 22, 2023 at 7:44 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > > > > On Mar 21, 2023, at 10:48 AM, Antony Polukhin via Boost < > boost(a)lists.boost.org> wrote: > > > > On Thu, Mar 16, 2023, 18:38 Marshall Clow via Boost < > boost(a)lists.boost.org> > > wrote: > > > >> The master branch is now open for bug fixes and documentation changes. > >> Other changes by release manager permission, as described in > >> > >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy < > >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > >> > > > > Sorry, I've misread the message and applied a "bug fix" without reading > the > > wiki, where "Code changes and fixes" should be merged only after release > > manager permission. > > > > May I keep the bugfix > > > https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… > > for the stacktrace merged to master branch? > > > > Thanks for letting us know. > The commit looks fine to me. > > — Marshall > > > > > The fix was in develop for two months and it switches > > backtrace_create_state into thread safe mode if platform supports > > multithreading. > > > >> > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 21 Mar '23

21 Mar '23

> On Mar 21, 2023, at 10:48 AM, Antony Polukhin via Boost <boost(a)lists.boost.org> wrote: > > On Thu, Mar 16, 2023, 18:38 Marshall Clow via Boost <boost(a)lists.boost.org> > wrote: > >> The master branch is now open for bug fixes and documentation changes. >> Other changes by release manager permission, as described in >> >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy < >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> >> > > Sorry, I've misread the message and applied a "bug fix" without reading the > wiki, where "Code changes and fixes" should be merged only after release > manager permission. > > May I keep the bugfix > https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… > for the stacktrace merged to master branch? > Thanks for letting us know. The commit looks fine to me. — Marshall > The fix was in develop for two months and it switches > backtrace_create_state into thread safe mode if platform supports > multithreading. > >> > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Antony Polukhin 21 Mar '23

21 Mar '23

On Thu, Mar 16, 2023, 18:38 Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy < > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > Sorry, I've misread the message and applied a "bug fix" without reading the wiki, where "Code changes and fixes" should be merged only after release manager permission. May I keep the bugfix https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… for the stacktrace merged to master branch? The fix was in develop for two months and it switches backtrace_create_state into thread safe mode if platform supports multithreading. >

1 0

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 21 Mar '23

21 Mar '23

On Mar 21, 2023, at 8:59 AM, Samuel DEBIONNE via Boost <boost(a)lists.boost.org> wrote: > > Hello, > I would like to merge a "missing include" fix from Boost.GIL to master: > > https://github.com/boostorg/gil/pull/729 Go ahead — Marshall > > Thank you, > Samuel > On 16/03/2023 16:43, Marshall Clow via Boost wrote: >> The master branch is now open for bug fixes and documentation changes. >> Other changes by release manager permission, as described in >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> >> The next deadline: On April 5th, master closes for all changes. >> As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> >> — Marshall >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Samuel DEBIONNE 21 Mar '23

21 Mar '23

Hello, I would like to merge a "missing include" fix from Boost.GIL to master: https://github.com/boostorg/gil/pull/729 Thank you, Samuel On 16/03/2023 16:43, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > > The next deadline: On April 5th, master closes for all changes. > > As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> > > — Marshall > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Need Volunteers for Docs!
by Ruben Perez 19 Mar '23

19 Mar '23

On Sat, 18 Mar 2023, 01:55 Vinnie Falco via Boost, <boost(a)lists.boost.org> wrote: > > Documentation has been a long-running complaint of users and authors. > The look of it, the content of it, and the way that people find it. We > are looking to resolve all of that and we've made quite a lot of > progress but we need help. There's a ton of work going into the > infrastructure and website right now so if you want to be a part of it > please speak up! > You know my obsession with docs, so I volunteer. Please let me know how can I help. Ruben. > >

2 1

Re: [boost] Need Volunteers for Docs!
by Vinnie Falco 18 Mar '23

18 Mar '23

On Fri, Mar 17, 2023 at 6:07 PM Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > I've been writing the occasional post on cppalliance.org, should that go to > boost instead? Or should boost operate like an aggregator? There's no facility for blogging yet but there will be on the new Boost website (and it will use Asciidoc). This will take a while though since it is not a planned feature for the initial release. This will also come with a way to post off-site links (like an aggregator) but since https://cpp.al is not receiving heavy traffic it would make more sense to migrate the blog content from there to the new boost.org. Thanks

1 0

Re: [boost] Need Volunteers for Docs!
by Klemens Morgenstern 18 Mar '23

18 Mar '23

I've been writing the occasional post on cppalliance.org, should that go to boost instead? Or should boost operate like an aggregator? On Sat, Mar 18, 2023 at 8:55 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > All: > > We are working on the User's Guide which is for people who want to use > Boost, and we are working on the Contributor's guide which is for > people who want to contribute to Boost. This includes authors, > maintainers, reviewers, review managers, review wizards, release > managers, contributors, testers, basically everyone who is changing > the state of our repositories somehow. > > These manuals are written in Asciidoc, but we need volunteers who can > jump in and start producing results right away. Most of the existing > site content has been ported to markdown and it needs editing and > sorting into a table of contents. The Getting Started instructions > which go into the release are in pretty rough shape and need editing. > > Documentation has been a long-running complaint of users and authors. > The look of it, the content of it, and the way that people find it. We > are looking to resolve all of that and we've made quite a lot of > progress but we need help. There's a ton of work going into the > infrastructure and website right now so if you want to be a part of it > please speak up! > > This is a sample of where we are going with it (the stylesheets have > not been worked on yet): > > https://antora.cppalliance.org/doc/html/mp11/mp11/list.html > > https://antora.cppalliance.org/doc/html/contributor-manual/intro.html > > Thank you for considering it ! > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Need Volunteers for Docs!
by Vinnie Falco 18 Mar '23

18 Mar '23

All: We are working on the User's Guide which is for people who want to use Boost, and we are working on the Contributor's guide which is for people who want to contribute to Boost. This includes authors, maintainers, reviewers, review managers, review wizards, release managers, contributors, testers, basically everyone who is changing the state of our repositories somehow. These manuals are written in Asciidoc, but we need volunteers who can jump in and start producing results right away. Most of the existing site content has been ported to markdown and it needs editing and sorting into a table of contents. The Getting Started instructions which go into the release are in pretty rough shape and need editing. Documentation has been a long-running complaint of users and authors. The look of it, the content of it, and the way that people find it. We are looking to resolve all of that and we've made quite a lot of progress but we need help. There's a ton of work going into the infrastructure and website right now so if you want to be a part of it please speak up! This is a sample of where we are going with it (the stylesheets have not been worked on yet): https://antora.cppalliance.org/doc/html/mp11/mp11/list.html https://antora.cppalliance.org/doc/html/contributor-manual/intro.html Thank you for considering it !

1 0

Re: [boost] announcing boost.async
by Richard Hodges 17 Mar '23

17 Mar '23

On Fri, 17 Mar 2023 at 16:22, Klemens Morgenstern via Boost < boost(a)lists.boost.org> wrote: > Hi, > > I've been working on a C++20 coroutine library, called `async`, > which is meant to be for C++ what asyncio is for python or generic > async/await is for javascript. > It's meant to be a framework for single threaded coroutine applications. > You are doing the Lord's work. > > It provides coroutine types, such as promises, tasks and generators to > model async operations, > channels for inter-coroutine communication and functions > like select, gather & join to wait or combine multiple awaitables. > > It's asio-based, i.e. uses asio::io_context as its event-loop and can > co_await any asio operation. > > As this is a very complex domain, I really would be happy to have some > users. > This will help me to improve documentation & come up with more > example ideas. > > Docs: https://klemens.dev/async > Repo: https://github.com/klemens-morgenstern/async > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

announcing boost.async
by Klemens Morgenstern 17 Mar '23

17 Mar '23

Hi, I've been working on a C++20 coroutine library, called `async`, which is meant to be for C++ what asyncio is for python or generic async/await is for javascript. It's meant to be a framework for single threaded coroutine applications. It provides coroutine types, such as promises, tasks and generators to model async operations, channels for inter-coroutine communication and functions like select, gather & join to wait or combine multiple awaitables. It's asio-based, i.e. uses asio::io_context as its event-loop and can co_await any asio operation. As this is a very complex domain, I really would be happy to have some users. This will help me to improve documentation & come up with more example ideas. Docs: https://klemens.dev/async Repo: https://github.com/klemens-morgenstern/async

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

I forgot my test case int main() { std::cout << std::setprecision(100); std::cout << "boost pi" << std::endl; { const auto pi = boost::math::constants::pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } std::cout << "my pi" << std::endl; { constexpr auto pi = boost::math::constants::my_pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::my_pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } return EXIT_SUCCESS; } boost pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068 my pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

Am 11.03.23 um 11:44 schrieb John Maddock via Boost: > On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: - The support for XX_v is omitted. - Additional macros BOOST_FLOATxx_C_OR_ZERO are needed. - boost::multiprecision::float128 is now constexpr if possible. > Off the top of my head I see two main correctness issues: > * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me> I am not sure if this is actually true. When testing with pi the results were identical. If this should be generally so (testing) we can save the helper macros BOOST_FLOATxx_C_OR_ZERO and use the general version. In the code the general version is available, but commented out. > * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). Instead of lexical_cast, the constructor(sting) is now used - had overlooked that. Is the accuracy sufficient? > * It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. As said boost::multiprecision::float128 works now. Are there any other cases? Exactly with boost::multiprecision::float128 it is noticed negatively that there are 3 code paths: - gcc (BOOST_MP_USE_FLOAT128) - intel (BOOST_MP_USE_QUAD) - in general This was also the reason for my other posting - quadmath as a standalone library. Then there would be only 2 code paths and the quadmath lib could be implemented more understandable. Eg there is in cstdfloat_iostream.hpp AND cstdfloat_cmath.hpp the stream operator<<. This is completely unnecessary effort. You have expressed concerns that with these measures the code would have to be adapted - which nobody likes to do. But in the train with C++23-FP types this must be done anyway - then please correctly. Gero

1 0

Re: [boost] Master branch is now open for bug fixes
by Glen Fernandes 16 Mar '23

16 Mar '23

On Thursday, March 16, 2023, John Maddock via Boost <boost(a)lists.boost.org> wrote: > > I'd like to merge two bug fixes from Multiprecision into master if > possible: > > * This one is a flat out correctness-bug that really should go in: > https://github.com/boostorg/multiprecision/pull/542 > > * This one is a more nice to have fix to the conversion operators: > https://github.com/boostorg/multiprecision/pull/543 > > > Go ahead Glen

1 0

Re: [boost] Master branch is now open for bug fixes
by John Maddock 16 Mar '23

16 Mar '23

On 16/03/2023 15:38, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I'd like to merge two bug fixes from Multiprecision into master if possible: * This one is a flat out correctness-bug that really should go in: https://github.com/boostorg/multiprecision/pull/542 * This one is a more nice to have fix to the conversion operators: https://github.com/boostorg/multiprecision/pull/543 In both cases the one CI failure, is a network timeout on the drone runner pulling Boost down. Thanks, John.

1 0

Master branch is now open for bug fixes
by Marshall Clow 16 Mar '23

16 Mar '23

The master branch is now open for bug fixes and documentation changes. Other changes by release manager permission, as described in https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> The next deadline: On April 5th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

1 0

Re: [boost] [Release] Master branch is closed for beta
by Andrey Semashev 16 Mar '23

16 Mar '23

On 3/9/23 17:19, Marshall Clow via Boost wrote: > Master is closed for all changes. > > See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> Is the master branch open now?

1 0

[release] Boost 1.82.0 beta 1 released
by Marshall Clow 15 Mar '23

15 Mar '23

Boost release 1.82.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ The SHA256 checksums are: efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 Release notes (still need updates): https://www.boost.org/users/history/version_1_82_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 15 Mar '23

15 Mar '23

Robert Ramey via Boost <boost(a)lists.boost.org> writes: > On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote: > > > This implicit "if you don't include the header then you don't need to > > link the dependency" approach doesn't scale well to cases where Boost is > > split into individual packages which are managed by a package manager. > > Right. This is a built-in deficiency of the package manager approach. > Dependencies are dependent upon the actual end user application and cannot > be logically discerned a priori by any package manager. They cannot be "magically" discerned but there can be a mechanism for specifying them explicitly. I don't believe we are disagreeing about the fundamental issues, which is that there needs to be support for optional dependencies. The difference is that you seem to advocate implicit discovery (and ongoing maintenance) of optional dependencies by the end-user (based on linker errors, by carefully studying the documentation, etc) while I advocate having an explicit mechanism in the package manager for the library author to specify which functionality is optional (and that requires optional dependencies) and for the library user to request this optional functionality (and automatically get the required dependencies). We have such a mechanism in build2, in our experience it works well, and we have applied it to the Boost libraries. > Contrary to what one would hope, the package manager is not a panacia > and trying to make it into one is a hopeless quest which leads to > pointless efforts to "eliminate dependencias" and create "standalone" > libraries. That's quite a bizarre perspective, seeing that the main functionality of a package manager is to make management of dependencies easier. It also doesn't match empirical evidence. For example, in Rust it's hard to find a package that doesn't have at least a few dozens dependencies (and more often a few hundreds). If anything, the problem is actually the opposite.

1 0

Re: [boost] v1.81.0 web page: operators library links to utility
by Andrey Semashev 15 Mar '23

15 Mar '23

On 3/15/23 07:04, Gavin Lambert via Boost wrote: > On 15/03/2023 16:33, Brook Milligan wrote: >> I’m not sure who to report this to, but it seems to me that on the >> web page for Boost v1.81.0 docs, the Operators library link is to >> Utility not Operators. > Boost.Operators isn't actually a real library; it's part of > Boost.Utility. But it does have the wrong link. > > For reference: > > - Page: https://www.boost.org/doc/libs/1_81_0/ > - Link target: > https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm > - Actual page: > https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… > > It looks like this broke as of Boost 1.78. libs/utility/operators.htm exists and redirects to doc/html/utility/utilities/operators.html.

1 1

Re: [boost] v1.81.0 web page: operators library links to utility
by Gavin Lambert 15 Mar '23

15 Mar '23

On 15/03/2023 16:33, Brook Milligan wrote: > I’m not sure who to report this to, but it seems to me that on the > web page for Boost v1.81.0 docs, the Operators library link is to > Utility not Operators. Boost.Operators isn't actually a real library; it's part of Boost.Utility. But it does have the wrong link. For reference: - Page: https://www.boost.org/doc/libs/1_81_0/ - Link target: https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm - Actual page: https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… It looks like this broke as of Boost 1.78.

1 0

v1.81.0 web page: operators library links to utility
by Brook Milligan 15 Mar '23

15 Mar '23

I’m not sure who to report this to, but it seems to me that on the web page for Boost v1.81.0 docs, the Operators library link is to Utility not Operators. Cheers, Brook

1 0