- Boost - lists.preview.boost.org

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

Re: [boost] boost.asem seeking endorsement
by Peter Dimov 07 Mar '23

07 Mar '23

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?

1 0

Re: [boost] boost.asem seeking endorsement
by Marcelo Zimbres Silva 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 06:05, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > 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. I would also like to endorse this library (although I don't know whether I qualify for endorsing libs or not). Marcelo

1 0