March 2023 - Boost - lists.preview.boost.org

Re: [boost] Moving "sub" libraries to their own repositories
by Glen Fernandes 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 3:17 PM Andrey Semashev wrote: > On 3/8/23 23:07, Glen Fernandes via Boost wrote: > > We have (very) few cases where within a repository we have more than one > > library inside a repository. One example is boostorg/functional whose > > meta/libraries.json has: > > > > - functional > > - functional/factory > > - functional/forward > > - functional/overloaded_function > > > > See: > https://github.com/boostorg/functional/blob/master/meta/libraries.json > > > > What do we think about having separate repositories for the last three > > above? e.g. The second one would be boostorg/functional_factory > > > > Some might be better collapsed into the first library (i.e. become part > of > > just "functional"). > > > > We haven't been allowing this for newer libraries, but it would be nice > to > > remove it from these few existing cases too. > > > > Ultimately meta/libraries.json in each library repository would have just > > one library entry. > > Why not just merge them all into Functional? Their headers are already > merged, only docs and tests need to be merged. > That option is on the table too. Some of them have much fewer dependencies, so there's some appeal in them being separate. In general I favor more fine grained smaller libraries, than more coarse grained bigger ones. Glen

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Marshall Clow 08 Mar '23

08 Mar '23

On Mar 8, 2023, at 12:07 PM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > We have (very) few cases where within a repository we have more than one > library inside a repository. One example is boostorg/functional whose > meta/libraries.json has: > > - functional > - functional/factory > - functional/forward > - functional/overloaded_function > > See: https://github.com/boostorg/functional/blob/master/meta/libraries.json > > What do we think about having separate repositories for the last three > above? e.g. The second one would be boostorg/functional_factory > > Some might be better collapsed into the first library (i.e. become part of > just "functional"). > > We haven't been allowing this for newer libraries, but it would be nice to > remove it from these few existing cases too. > > Ultimately meta/libraries.json in each library repository would have just > one library entry. Boost/numeric is another such library % ls $BOOST/libs/numeric conversion index.html odeint ublas doc interval sublibs % find . -name sublibs ./spirit/sublibs ./chrono/sublibs ./gil/sublibs ./algorithm/sublibs ./numeric/sublibs ./geometry/sublibs ./functional/sublibs ./utility/sublibs — Marshall

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Andrey Semashev 08 Mar '23

08 Mar '23

On 3/8/23 23:07, Glen Fernandes via Boost wrote: > We have (very) few cases where within a repository we have more than one > library inside a repository. One example is boostorg/functional whose > meta/libraries.json has: > > - functional > - functional/factory > - functional/forward > - functional/overloaded_function > > See: https://github.com/boostorg/functional/blob/master/meta/libraries.json > > What do we think about having separate repositories for the last three > above? e.g. The second one would be boostorg/functional_factory > > Some might be better collapsed into the first library (i.e. become part of > just "functional"). > > We haven't been allowing this for newer libraries, but it would be nice to > remove it from these few existing cases too. > > Ultimately meta/libraries.json in each library repository would have just > one library entry. Why not just merge them all into Functional? Their headers are already merged, only docs and tests need to be merged.

1 0

Moving "sub" libraries to their own repositories
by Glen Fernandes 08 Mar '23

08 Mar '23

We have (very) few cases where within a repository we have more than one library inside a repository. One example is boostorg/functional whose meta/libraries.json has: - functional - functional/factory - functional/forward - functional/overloaded_function See: https://github.com/boostorg/functional/blob/master/meta/libraries.json What do we think about having separate repositories for the last three above? e.g. The second one would be boostorg/functional_factory Some might be better collapsed into the first library (i.e. become part of just "functional"). We haven't been allowing this for newer libraries, but it would be nice to remove it from these few existing cases too. Ultimately meta/libraries.json in each library repository would have just one library entry. Glen

1 0

Re: [boost] improve <boost/config.hpp>
by Jeff Garland 08 Mar '23

08 Mar '23

On Tue, Mar 7, 2023 at 11:11 AM John Maddock via Boost < boost(a)lists.boost.org> wrote: > > > Not every compiler defines these macros. Let alone, not every compiler > > properly implements what it advertises. > I think it depends on the compiler - the current crop of the latest are > pretty good at getting these right. > > Also, library-defined macros are worthless as they only allow one to > > know the feature is/isn't supported after including the header, i.e. > > after the fact. C++20 <version> fixes this, but C++20 is a too high > > minimum bar to target. > Sort of, you know that Boost.Config uses <version> wherever possible > already? It does so even in non-C++20 mode since the header is just a > bunch of #defines and is perfectly usable back to C++98 if it exists. > > > > So no, feature macros do not replace Boost.Config. In fact, I'd prefer > > to continue using Boost.Config in new libraries. > > There are still plenty of things Boost.Config is good for: particularly > where getting the configuration correct is tricky - for example if you > want to use <header> then you need to know both that it exists via > __has_include, but also that the current language standard is sufficient > to parse the header, and that it has been been fully implemented. > > On the other hand, for the suggested BOOST_NO_CXX20_CONSTEXPR, > Boost.Config would implement this trivially as (__cpp_constexpr < > 201907L) which is a less obvious win - except perhaps to save folks > having to look up the value - which now I come to think about it, might > be a win after all given that it's value is not 202002L ;) > To me, cppreference is only a click away so I'm unmoved by the 'value being unexpected'. I do appreciate that boost.config can compose for the more complex cases and is tested to ensure portability. Really my main thinking here is a minimization of inter-boost dependency (for the aforementioned stand alone capability). Config is hardly a heavy dependency in the end so if it's useful it can be pulled in by the cmake, but if there's an easy way to check without it then that I think should be the first choice. If it's really the case that the macro coverage in implementations is as spotty as some are implicating here -- then by all means use config -- I'm just thinking I won't really need it going forward. Jeff

1 0

Re: [boost] improve <boost/config.hpp>
by Jeff Garland 08 Mar '23

08 Mar '23

On Tue, Mar 7, 2023 at 11:14 AM John Maddock via Boost < boost(a)lists.boost.org> wrote: > > > Please see: https://en.cppreference.com/w/cpp/feature_test for language > > level macros -- look for _cpp_constexpr. I believe you'll discover that > > every combination you're looking for going back to cxx 2011 is > represented > > -- basically making a boost config macro extraneous. The standard copied > > this idea from boost.config btw and it's quite powerful for portable > > libraries. Note that I regret using the boost.config macro for date-time > > constexpr stuff, because at this point I'd like to make the library > > available in a stand-alone fashion like boost.math. Not depending on > > boost.config would be helpful in that endeavor. > > I think that would be fairly trivial Jeff: I see nothing in date_time > that requires something beyond C++11, so you could probably just check > for Boost.Config's presence with __has_include and only include it when > available. Otherwise assume a conforming C++11 compiler in standalone > mode. > > Thanks John. date-time is currently compatible back to 1998 currently. The constexpr macros from config allow that to happen by removing constexpr when less than c++14 (the limitations of c++11 constexpr were too much to practically support it). But yeah, I agree requiring 14 (and maybe 17 for from_chars support) or above should make standalone date-time relatively easy. I'd actually just like to remove as much of the macro hackery once and for all. Jeff

1 0

Re: [boost] boost.asem seeking endorsement
by Christopher Kohlhoff 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023, at 2:28 AM, Klemens Morgenstern via Boost wrote: > Channels - which are Experimental. Channels do indeed cover the use cases represented by an asynchronous "condition variable" and "semaphore", and much more besides. A "condition variable" is an unbuffered channel, a "semaphore" is a channel with buffer size N, and a "mutex' is a channel with buffer size 1. IMHO "experimental" is not a reason to avoid using channels if you have these use cases. "Experimental" is just an in-your-face warning that I don't guarantee the same level of API and behavioural stability as other parts of the library. Even so, I don't make breaking changes to their interface lightly. Eventually they will migrate into the main asio namespace. Where channels *have* been limited is that they have required C++17 or later. However, from boost 1.82 they will work with C++11 and up (albeit with some limitations on functionality, but enough to cover the aforementioned use cases). I may also consider in the future adding some algorithms over channels, to encapsulate some common usage patterns that are identified (e.g. using an RAII approach to pair sends and receives). > He also said he's thinking about adding something akin to my mutex. Yes, and my current view is that an asynchronous "mutex" does not add sufficient value over just using a channel either. On the other hand, an asynchronous readers/writers lock (aka rwlock), is something I do see a lot of additional value in, due to the complexity involved in implementing it and particularly if it is upgradeable. I have been considering adding something along those lines in a future release. Cheers, Chris

1 0

Re: [boost] improve <boost/config.hpp>
by Daniela Engert 07 Mar '23

07 Mar '23

Am 07.03.2023 um 19:43 schrieb Peter Dimov via Boost: > Daniela Engert wrote: >> Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: >>> On 3/7/23 21:11, John Maddock via Boost wrote: >>>>> Not every compiler defines these macros. Let alone, not every >>>>> compiler properly implements what it advertises. >>>> I think it depends on the compiler - the current crop of the latest >>>> are pretty good at getting these right. >>> Have MSVC started defining these macros yet? >> I see them in VS2017, but I don't know how complete they are. > This complete: > > https://www.boost.org/development/tests/develop/developer/output/teeks99-09… > Cool, thanks Peter! BTW, this is the reason why we build (and use) Boost with our own build flags to enforce and announce maximum possible language conformance in msvc. The list reveals that the tests are done with non-conformance compiler settings that cater to old customers. -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

2 1

Re: [boost] improve <boost/config.hpp>
by Peter Dimov 07 Mar '23

07 Mar '23

Daniela Engert wrote: > Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: > > On 3/7/23 21:11, John Maddock via Boost wrote: > >>> Not every compiler defines these macros. Let alone, not every > >>> compiler properly implements what it advertises. > >> I think it depends on the compiler - the current crop of the latest > >> are pretty good at getting these right. > > Have MSVC started defining these macros yet? > > I see them in VS2017, but I don't know how complete they are. This complete: https://www.boost.org/development/tests/develop/developer/output/teeks99-09…

1 0

Re: [boost] improve <boost/config.hpp>
by Daniela Engert 07 Mar '23

07 Mar '23

Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: > On 3/7/23 21:11, John Maddock via Boost wrote: >>> Not every compiler defines these macros. Let alone, not every compiler >>> properly implements what it advertises. >> I think it depends on the compiler - the current crop of the latest are >> pretty good at getting these right. > Have MSVC started defining these macros yet? I see them in VS2017, but I don't know how complete they are. With C++20, the existence of feature test macros and header <version> became mandatory, so both the compiler and the library related macros are there in VS2019 and VS2022. Thanks Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

1 0