- Boost - lists.boost.org

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

08 Mar '23

On Wed, Mar 8, 2023 at 12:21 PM Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > In general I favor more fine grained smaller libraries, > than more coarse grained bigger ones. I prefer this as well and I have three libraries in development now which form a logical whole: buffers http_io http_proto These would each have to pass individual review and I suspect that our review process has not been vetted for the model where a larger work is proposed as several individual libraries. Thanks

2 2

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

08 Mar '23

On Wed, Mar 8, 2023 at 12:17 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > Why not just merge them all into Functional? Their headers are already > merged, only docs and tests need to be merged. If we do that, then these four libraries will appear as just one library on the various libraries pages: https://www.boost.org/doc/libs/ https://www.boost.org/doc/libs/1_81_0/libs/libraries.htm Each library has slightly different metadata such as the first release date and the author. We would lose these distinctions. Thanks

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by René Ferdinand Rivera Morell 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 2:18 PM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > 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 AFAIK, except for numerics, all those sublibs are only there to appease the result matrix to show tests in subpaths. For numerics.. The work I'm doing to get modular arrangement will require that we have a flat structure in libs anyway :-) -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

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