- Boost - lists.boost.org

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

Re: [boost] GSOC director stepping down and replacement
by Niall Douglas 07 Mar '23

07 Mar '23

On 07/03/2023 01:06, Glen Fernandes via Boost wrote: > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. > > If anyone wants to step forward and become the new GSOC administrator, > Boost can keep the program running. > > David has generously agreed to help mentor his replacement until the > transition is complete. Also my thanks to David. You kept at it far longer than I thought you would when you graciously took over the role from me! It's a lot of work, and thanks for continuing its success. Niall

1 0

Re: [boost] GSOC director stepping down and replacement
by Mateusz Loskot 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 02:05, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. Thank you David for the years of your service It's been pleasure collaborate with you over several rounds of GSoC. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] boost.asem seeking endorsement
by Vinnie Falco 07 Mar '23

07 Mar '23

On Mon, Mar 6, 2023 at 11:43 PM Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Asio is already too large anyway and would be better as a few separate libraries Thanks

1 0

Re: [boost] boost.asem seeking endorsement
by Ruben Perez 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. Endorsed. We need this library to do things like pipelining and request throttling in a sane way. I still think the best place for this would be Asio, but if there's not chance to get it in, Boost.Asem is good for me, too. I hereby volunteer as review manager in case you need it. Regards, Ruben.

1 0

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

07 Mar '23

Hi, On Tue, 7 Mar 2023 at 08:43, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Can you give more details, he did not express interest by being silent or has he raised design, useability etc. concerns? Or perhaps he is planning to implement them in asio in the future? Regards, Marcelo

1 0