- Boost - lists.boost.org

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