March 2023 - Boost - lists.boost.org

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

09 Mar '23

On Wed, Mar 8, 2023 at 2:54 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > I suppose, they should be reviewed bottom-to-top. I think you're saying to review them in this order: 1. buffers 2. http_proto 3. http_io ? Thanks

2 1

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

08 Mar '23

On 3/9/23 00:33, Vinnie Falco via Boost wrote: > On Wed, Mar 8, 2023 at 12:55 PM Glen Fernandes <glen.fernandes(a)gmail.com> wrote: >> If they're separate libraries, they should be reviewed individually >> (and serially, since we never have reviews in parallel). I don't see >> why our review process can't handle that. > > http_proto depends on buffers > http_io depends on http_proto > > What if buffers and http_io get accepted but http_proto does not? lol... I suppose, they should be reviewed bottom-to-top.

1 0

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

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

Re: [boost] boost.asem seeking endorsement
by Alan de Freitas 07 Mar '23

07 Mar '23

I'd like to endorse boost.asem. Em ter., 7 de mar. de 2023 às 02:05, Klemens Morgenstern via Boost < boost(a)lists.boost.org> escreveu: > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. > > It provides the following asio-based synchronization primitives: > > - barrier > - condition_variable > - mutex > - semaphore > > Asio currently has timers & (experimental) channels that can help. > However, I think there is a need for more purpose-made utilities to help > more complex asio-based libraries (requests, redis, mysql et al.) > > Code: https://github.com/klemens-morgenstern/asem > Docs: https://klemens.dev/asem/ > > I'm also not too happy with the name, but so far I only came up with an > acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>

1 0

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

07 Mar '23

John Maddock 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. Or just require C++11 and do nothing at all.

1 0

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

07 Mar '23

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? >> 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. Using <version> inside Boost.Config is fine, as long as Boost.Config knows when it can be used and trusted. That's just an implementation detail of Boost.Config. >> 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 ;) BOOST_NO_CXX20_CONSTEXPR would be useful in case of compiler bugs.

1 0

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

07 Mar '23

> 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. John.

1 0

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

07 Mar '23

> 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 ;) John.

1 0

Reminder: Master branch is closing for the beta release TOMORROW
by Marshall Clow 07 Mar '23

07 Mar '23

Calendar is here: https://www.boost.org/development/ <https://www.boost.org/development/> — Your friendly release managers

1 0

Re: [boost] boost.asem seeking endorsement
by Vinícius dos Santos Oliveira 07 Mar '23

07 Mar '23

Em ter., 7 de mar. de 2023 às 02:05, Klemens Morgenstern via Boost < boost(a)lists.boost.org> escreveu: > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. > > It provides the following asio-based synchronization primitives: > > - barrier > - condition_variable > - mutex > - semaphore > I implemented this in the past: https://vinipsmaker.github.io/iofiber/ Point is: I don't care *who* implements it (I wasn't the first and you aren't going to be the last). Boost.Asio *does* need these primitives. You have my endorsement. However don't expect me to go easy on the review. I do want a high quality design. Do you have fiber-local-storage and Boost.Context integration already (this is fiber vocabulary after all, so it would be weird to not offer the fiber as well)? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

1 0

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

07 Mar '23

On 3/7/23 18:22, Jeff Garland via Boost wrote: > On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost < > boost(a)lists.boost.org> wrote: > >> >>> But I don't understand why you are against it. After all, there is >>> BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - >>> but I already offered that). So we have an expressive scheme >>> BOOST_CXXnn_CONSTEXPR that is unambiguous and readable. >> >> C++14 lifted some major constraints on what can be in a constexpr >> function compared to C++11. Most notably support for more than just a >> return statement. Being able to differentiate that is useful in practice. >> >> > For example, std::round in C++23 is constexpr >> >> The CXXyy part in the Boost.Config macros refers to the language level >> support. While std::round is at library level. So a compiler supporting >> C++14 constexpr syntax might not have a std library where std::round is >> constexpr even if it claims C++23 support. So the better way here would >> be a more focused macro combining the language level of the constexpr >> feature and the library support of what that specific function is using. >> >> Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer >> to the language level anymore. And if you bind that to availability of >> constexpr std::round the next user may want to use it with another std:: >> function which is supposed to be constexpr in C++23 but due to a std >> library defect is not yet. Hence the distinction between library level >> and language level feature macros. >> > > 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. Not every compiler defines these macros. Let alone, not every compiler properly implements what it advertises. 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. So no, feature macros do not replace Boost.Config. In fact, I'd prefer to continue using Boost.Config in new libraries.

1 0

Re: [boost] boost.asem seeking endorsement
by Klemens Morgenstern 07 Mar '23

07 Mar '23

Channels - which are Experimental. He also said he's thinking about adding something akin to my mutex. Furthermore you can use a timer like a condition_variable with a bit of wrapper code (cancel becomes notify). None of this seems great to me. On Tue, Mar 7, 2023, 23:21 Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Klemens Morgenstern wrote: > > I would like them to be in asio, > > but I am not the asio author. > > > > Chris did not seem interested in the idea. > > What did Chris suggest people need to use instead > of this library when they have the problems it solves? > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

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

07 Mar '23

On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost < boost(a)lists.boost.org> wrote: > > > But I don't understand why you are against it. After all, there is > > BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - > > but I already offered that). So we have an expressive scheme > > BOOST_CXXnn_CONSTEXPR that is unambiguous and readable. > > C++14 lifted some major constraints on what can be in a constexpr > function compared to C++11. Most notably support for more than just a > return statement. Being able to differentiate that is useful in practice. > > > For example, std::round in C++23 is constexpr > > The CXXyy part in the Boost.Config macros refers to the language level > support. While std::round is at library level. So a compiler supporting > C++14 constexpr syntax might not have a std library where std::round is > constexpr even if it claims C++23 support. So the better way here would > be a more focused macro combining the language level of the constexpr > feature and the library support of what that specific function is using. > > Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer > to the language level anymore. And if you bind that to availability of > constexpr std::round the next user may want to use it with another std:: > function which is supposed to be constexpr in C++23 but due to a std > library defect is not yet. Hence the distinction between library level > and language level feature macros. > 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. > However IIRC some C++ standard added support of (temporary) allocations > in constexpr functions. That would be worth a dedicated feature macro as > that change fits the idea described above. > w.r.t. non-standard allocation support, sure that would be an extension perhaps worthy of a boost macro, but also maybe just check the compiler locally in the library that wants to use that extension. Jeff

1 0