April 2023 - Boost - lists.preview.boost.org

Re: [boost] Boost.Compat
by Peter Dimov 30 Apr '23

30 Apr '23

Andrey Semashev wrote: > I didn't say anything against refactoring, in fact I'm arguing that we should > maintain our existing libraries (which includes refactoring) rather than add > new libraries with duplicate components. You did create the (stillborn) Sync though, which duplicates Thread. Why?

1 1

Re: [boost] Boost.Compat
by Andrey Semashev 30 Apr '23

30 Apr '23

On 4/30/23 02:18, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> And lastly. I realize that the proposed Boost.Compat is supposed to contain >> direct equivalents of the standard components. But what if we want to >> improve on that? Would this be not allowed simply because this would deviate >> from the standard? > > No, it wouldn't be allowed. Improving upon the standard makes it impossible > to later replace the compatibility header with a using declaration. We have > such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because > of extensions we can't simply make them be <ratio> and <chrono>. > > It's fine to want to improve upon the standard, but Compat will not be the > place for that. That's what dedicated libraries are for. This would mean more code duplication, wouldn't it?

1 0

Re: [boost] Boost.Compat
by Vinnie Falco 30 Apr '23

30 Apr '23

On Sat, Apr 29, 2023 at 4:06 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > If we don't want to use the libraries we write and accept during > the review then there must be something wrong with Boost. Nonsense. Large code bases need refactoring at regular intervals, this is no different. Or do you think that Boost libraries are so perfect upon acceptance that they can never be improved? My libraries are certainly not. Thanks

2 1

Re: [boost] Boost.Compat
by Andrzej Krzemienski 30 Apr '23

30 Apr '23

niedz., 30 kwi 2023 o 02:14 Vinnie Falco via Boost <boost(a)lists.boost.org> napisał(a): > On Sat, Apr 29, 2023 at 4:06 PM Andrey Semashev via Boost > <boost(a)lists.boost.org> wrote: > > If we don't want to use the libraries we write and accept during > > the review then there must be something wrong with Boost. > > Nonsense. Large code bases need refactoring at regular intervals, this > is no different. Or do you think that Boost libraries are so perfect > upon acceptance that they can never be improved? My libraries are > certainly not. > I think what Andrey was referring to is the situation where there exists one implementation, say in Boost.Core, and then a duplicate implementation in another Boost library for the purpose of reducing dependencies. Regards, &rzej; > > Thanks > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 7:24 PM Peter Dimov wrote: > Andrey Semashev wrote: > > And lastly. I realize that the proposed Boost.Compat is supposed to > contain > > direct equivalents of the standard components. But what if we want to > > improve on that? Would this be not allowed simply because this would > deviate > > from the standard? > > No, it wouldn't be allowed. Improving upon the standard makes it impossible > to later replace the compatibility header with a using declaration. We have > such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because > of extensions we can't simply make them be <ratio> and <chrono>. > > It's fine to want to improve upon the standard, but Compat will not be the > place for that. That's what dedicated libraries are for. > I agree. If Boost.Compat exists then its components should not deviate from their standard counterparts. It's not the place to innovate, only to provide an implementation (if possible) for a standard library facility.

1 0

Re: [boost] Boost.Compat
by Peter Dimov 29 Apr '23

29 Apr '23

Andrey Semashev wrote: > And lastly. I realize that the proposed Boost.Compat is supposed to contain > direct equivalents of the standard components. But what if we want to > improve on that? Would this be not allowed simply because this would deviate > from the standard? No, it wouldn't be allowed. Improving upon the standard makes it impossible to later replace the compatibility header with a using declaration. We have such a problem today with e.g. Boost.Ratio and Boost.Chrono, where because of extensions we can't simply make them be <ratio> and <chrono>. It's fine to want to improve upon the standard, but Compat will not be the place for that. That's what dedicated libraries are for.

1 0

Re: [boost] CI Test time
by Andrey Semashev 29 Apr '23

29 Apr '23

On 4/29/23 23:45, Robert Ramey via Boost wrote: > Looks like the CI for the serialization library takes about 200 minutes > to run (on a good day). When I run it on my local desktop for one > compiler/configuration it takes 1-2 minutes. It seems to me that the > way that CI works, it entails a huge waste resources and time. Has > anyone thought about this? If you know where most overhead is coming from, you can work towards reducing that overhead. For example, you can save time wasted on environment setup and git checkout if you run tests for different configurations in one CI job. If you want more specific comments then you probably have to provide more details on your problem.

1 0

Re: [boost] Boost.Compat
by Andrey Semashev 29 Apr '23

29 Apr '23

On 4/27/23 18:16, Peter Dimov via Boost wrote: > Newer C++ standards (20) have been adding useful things to the > standard library (<bit>, <latch>, etc) and most of us would like to > use them, both in Boost and outside of it, while still supporting > C++11, or 14, or 17. > > Many of these components are straightforward to implement > using the C++11 standard library, consist of not much than one > relatively small header, don't need many Boost dependencies > beyond the required ones (Assert, ThrowException, Config), and > since their interface is already fixed by the standard, don't need > a design review. > > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > So my suggestion is to create a separate library/repo, Boost.Compat > (boostorg/compat, namespace boost::compat) for them. > > Thoughts? (Be sure to read the discussion in the PR as well.) My main concern in the aforementioned PR was increased code duplication, and it isn't fixed by having Boost.Compat. I really don't like us having multiple copies of the same components for the sole purpose of reducing dependencies (in the case of latch - reducing tests dependencies, not even library dependencies). If we don't want to use the libraries we write and accept during the review then there must be something wrong with Boost. This isn't good for Boost (more maintenance required, less overall quality because some parts are left unmaintained) and this isn't good for users (more confusion, more compatibility issues). Secondly, I'm not sure I like the idea of another kitchen sink kind of library a-la Boost.Core and Boost.Utility, as such libraries tend to become bloated over time. Such libraries are also inconvenient for users' consumption, as it is more difficult to find a component in one of such libraries compared to in one of the specialized ones. I would prefer us to keep evolving our existing libraries, where appropriate, and accept new ones, where their functionality is not covered by the existing ones. And lastly. I realize that the proposed Boost.Compat is supposed to contain direct equivalents of the standard components. But what if we want to improve on that? Would this be not allowed simply because this would deviate from the standard? If allowed, would this still not require a review? I think, the "no review required" policy might be a bit too permissive.

1 0

Re: [boost] library usage statistics
by René Ferdinand Rivera Morell 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 3:42 PM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > > Looking at the discussion regarding multi-array, I'm thinking I'd like > to know how many people/projects are using the current version. Define "using", as precisely as you can. Then, maybe, we can figure out how to measure. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] CI Test time
by Vinnie Falco 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 1:54 PM Robert Ramey via Boost <boost(a)lists.boost.org> wrote: > Has anyone thought about this? Yes.

1 0

CI Test time
by Robert Ramey 29 Apr '23

29 Apr '23

Looks like the CI for the serialization library takes about 200 minutes to run (on a good day). When I run it on my local desktop for one compiler/configuration it takes 1-2 minutes. It seems to me that the way that CI works, it entails a huge waste resources and time. Has anyone thought about this? Robert Ramey

1 0

library usage statistics
by Robert Ramey 29 Apr '23

29 Apr '23

Looking at the discussion regarding multi-array, I'm thinking I'd like to know how many people/projects are using the current version. It's been there for ever and hardly ever gets an update. This indicates to me that the current usage is very small - or that the library is currently close to perfect! I don't have a specific need for this, but I find myself wanting this information all the time and I don't see a way to get it. If anyone has any ideas about how to do this, I'd be curious to hear them. Robert Ramey

1 0

Re: [boost] proposal Multi multidimensional array library
by Vinnie Falco 29 Apr '23

29 Apr '23

On Sat, Apr 29, 2023 at 9:58 AM John Maddock via Boost <boost(a)lists.boost.org> wrote: > That seems to me like the sort of thing that could/should be thrashed > out at review time, and either back-ported to C++14 or not. I'd like people to know where I stand, so I will say that if I thought the library review verdict should be ACCEPTED I would leave it up to the author to decide if and when they want to refactor it to support earlier C++ versions. And if they decide never to support earlier C++ versions that would be perfectly OK with me. I don't have any hard data but I have a hunch that the audience for this library is much more likely to adopt or have already adopted C++17 or later. So there might not be much to gain from supporting earlier versions. Compare and contrast this with a staple such as, Boost.JSON - I think you lose a LOT of users if you require C++17 on that. Thanks

1 0

Re: [boost] proposal Multi multidimensional array library
by John Maddock 29 Apr '23

29 Apr '23

On 29/04/2023 17:51, Vinnie Falco via Boost wrote: > On Wed, Apr 26, 2023 at 2:30 PM Alfredo Correa via Boost > <boost(a)lists.boost.org> wrote: >> https://gitlab.com/correaa/boost-multi. > I've had a look at this repository, and these are my thoughts. It > looks like the author has invested considerable effort to polish > everything about the library up to be Boost quality. The README.md is > comprehensive, well written, and sounds like the kind of things we > care about. I don't know a whole lot about the particular needs of > robust multi-dimensional array users but this has got to be worth > reviewing. > > It seems the library requires C++17 or greater, which is unfortunate. > But especially unfortunate considering that there are no features > which actually require it other than using std::pmr::memory_resource. > But this could have been conditionally enabled on the C++ version. That seems to me like the sort of thing that could/should be thrashed out at review time, and either back-ported to C++14 or not. John.

1 0

Re: [boost] proposal Multi multidimensional array library
by Vinnie Falco 29 Apr '23

29 Apr '23

On Wed, Apr 26, 2023 at 2:30 PM Alfredo Correa via Boost <boost(a)lists.boost.org> wrote: > https://gitlab.com/correaa/boost-multi. I've had a look at this repository, and these are my thoughts. It looks like the author has invested considerable effort to polish everything about the library up to be Boost quality. The README.md is comprehensive, well written, and sounds like the kind of things we care about. I don't know a whole lot about the particular needs of robust multi-dimensional array users but this has got to be worth reviewing. It seems the library requires C++17 or greater, which is unfortunate. But especially unfortunate considering that there are no features which actually require it other than using std::pmr::memory_resource. But this could have been conditionally enabled on the C++ version. That said, there's no rule which says you have to support old versions of C++, and the contents of the repository demonstrate that Alfredo's is likely to be an engineer who reflects the qualities of a good Boost library author. Therefore I endorse this library for review. Thanks

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Robert Ramey 28 Apr '23

28 Apr '23

On 4/28/23 4:34 AM, John Maddock via Boost wrote: > On 27/04/2023 23:19, Robert Ramey via Boost wrote: >> in boost/config/detail/suffix.hpp What's the specific issue this is causing? Mostly I think it's just confusing me and perhaps someone else fixing a bug. Here is the PR with the chain of discussion. https://github.com/boostorg/serialization/pull/224 Happy to hear anything you have to say. Robert Ramey > > John. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Replacing the ML with a forum
by Kenneth Porter 28 Apr '23

28 Apr '23

I use two threaded mailers: Thunderbird and Mulberry. But the main value of threading here is being able to skip to the end of a subthread to see the latest answer. I can do that quickly in a forum without threading. But I do like the threading of Reddit and Slashdot, so a forum that supports that would be nice. My biggest gripe with the mailing list is really with my ISP's mailing system (Xfinity), which doesn't retry a submission to the listserv when the listserv's greylisting bounces the initial submission with a temporary failure. I have to wait a couple minutes for the bounce email and then re-send from my Sent folder. As I'll certainly have to do with this message. So I don't participate as much on this list as I do on others without the greylisting. A forum wouldn't be subject to this problem. It does seem that forums get better search engine spidering than mailing list archives do. So it would be easier to search for answers using a forum. I'd hope to see a forum with a monthly or weekly mailing of a summary of active threads. I get that with a few forums, notably Rocky Linux and Visual Tool Kit. That's a feature of mailing lists: I don't forget to look to see new messages. But I do filter mailing list messages to separate folders (using the List-ID header) so they don't clutter my Inbox. I just glance at the Boost folder to see what new activity is available as part of my regular email regimen.

1 0

Re: [boost] Replacing the ML with a forum
by Robert Ramey 28 Apr '23

28 Apr '23

On 4/27/23 8:11 AM, Vinnie Falco via Boost wrote: > On Thu, Apr 27, 2023 at 7:56 AM Robert Ramey via Boost > <boost(a)lists.boost.org> wrote: >> I fail to see what is to be gained by replacing the current system. > > The current system is not being "replaced" it is being enhanced, with > the OPTION (but not the requirement) to interact with the mailing > lists using a modern, forum-based interface. Just as there are folks > who have expressed that they would not participate in Boost > discussions outside of the mailing list interface, there are as many > (or more) people who have expressed that they will not interact with > Boost through the mailing list at all. You don't hear from them > because well, they don't post to the list (the dog that didn't bark). > > You ask, what is to be gained? > Well, the largest existential threat to > Boost is that we do not refresh the foundations of our social > technology and our membership. I don't believe this. > Library membership in Boost no longer > carries the cachet that it used to. Perhaps - > Authors of new libraries > increasingly prefer to go directly to the C++ standard instead of > being thoroughly vetted in a Boost review. True - Because its much easier to get something into the standard than it is to get it into boost. For one thing Boost requires a working implementation, test suite, and user level documentation. For the standard, all one needs is to convince a small group of one's buddies that the world needs the authors proposal. This is especially effective when the proposal is too opaque for any normal person to understand - thus guarenteeing that there were be no real objections. That is until its features get added into the standard and real people have difficulties implementing and/or using them. If we want to continue to > maintain Boost's extraordinary relevance, we must do the following: > 1. Make the mailing list more appealing to younger generations > (millenials and the TikTok youths) I don't think this is a real problem. I'm trying not to sound like a curmudgeonly old person, but really - are millenias and TikTok youths our target audience? > 2. Increase participation in the Boost Formal Review process To do this we need to attract better libraries and work harder to promote the review. Also the 1-2 week window for reviews is a big problem. I might want to do a review but I can't right now. One of the features of my "Blincubator" project was to permit one to post reviews long in advance of the official review period. In fact. We might delay the formal review period until there are some magic number of reviews already in the queue. > 3. Spark the imagination of the new generations of library authors > - to write new libraries > - to submit their libraries to Boost for review > - to become active maintainers upon acceptanc > > 4. Inspire people to contribute to Boost > - by using the libraries, and providing feedback > - by contributing to individual projects > - by helping with documentation > - by helping other users with questions or problems I think the best way to do this is for boost to create better software. This would mean less bugs/design flaws, better documentation, less quirky tools. Why can't we apply the standards we use for user libraries to boost infrastructure? This would mean: boost tools like the following: a) documentation chain b) build system - Bjam c) build system - CMake integration c) CI d) GitHub integration e) website development and testing f) probably some others I forgot would be subject to similar requirements as boost user libraries. That is, Test suite, documentation, Formal review. None of the boost tools have been subjected to these requirements - and anyone who tries to use them notices. This is probably the single greatest obstacle to continued progress of boost. > The mailing lists must never go away, for as long as there are even a > few people who prefer them. But this cannot be the sole method to > participate in the Boost social space. To stay current we must provide > additional choices. The need for a forum interface is obvious. Don't the #boost and #boost-user forums on Slack currently fulfill this requirement? Robert Ramey

1 0

Re: [boost] Boost.Compat
by Peter Dimov 28 Apr '23

28 Apr '23

Glen Fernandes wrote: > On Friday, April 28, 2023, Dominique Devienne wrote: > > > Of course, Boost.Compat (or Boost.Polyfill) would need to turn on/off > > its std:: alternatives depending on the standard level in use. > > > > > If everyone agrees, this can be one of the tenets of Boost.Compat from the > very beginning. > > The "depending on the standard level in use" might be further clarified to > mean "provides a fully functional std:: version". An implementation in terms of `using std::something` will be allowed, but not required.

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 28 Apr '23

28 Apr '23

On Friday, April 28, 2023, Dominique Devienne wrote: > Of course, Boost.Compat (or Boost.Polyfill) would need to turn > on/off > its std:: alternatives depending on the standard level in use. > > If everyone agrees, this can be one of the tenets of Boost.Compat from the very beginning. The "depending on the standard level in use" might be further clarified to mean "provides a fully functional std:: version". Glen

1 0

Re: [boost] Boost.Compat
by Dominique Devienne 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 5:16 PM Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Newer C++ standards (20) have been adding useful things to the > standard library (<bit>, <latch>, etc) and most of us would like to > use them, both in Boost and outside of it, while still supporting > C++11, or 14, or 17. > > Many of these components are straightforward to implement > using the C++11 standard library, consist of not much than one > relatively small header, don't need many Boost dependencies > beyond the required ones (Assert, ThrowException, Config), and > since their interface is already fixed by the standard, don't need > a design review. > > It would be nice if we had a dedicated place in Boost where to > put these, to avoid the need for everyone reimplementing a > private copy. > > At the moment, some of these have gone into Core, for lack of > anywhere else, and we now have a <latch> contribution (which I > encouraged): > > https://github.com/boostorg/core/pull/144 > > However, Core is not quite the right place for these components. > > So my suggestion is to create a separate library/repo, Boost.Compat > (boostorg/compat, namespace boost::compat) for them. > > Thoughts? (Be sure to read the discussion in the PR as well.) > +1. I'm on C++17, and have adopted std::span and others from C++20/23, from various places on GitHub. I'd welcome Boost-provided "polyfills" [1] instead. Of course, Boost.Compat (or Boost.Polyfill) would need to turn on/off its std:: alternatives depending on the standard level in use. --DD PS: Since we update our Boost dependency rarely, I sometimes drop newer Boost libs (e.g. Boost.Describe) in our code-base, and hope for backward-compatibility with our old Boost install. So if Boost.Compat could be similarly backward-compatible, that would increase the likelyhood we could use it sooner rather than later. [1] https://en.wikipedia.org/wiki/Polyfill_(programming)

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by John Maddock 28 Apr '23

28 Apr '23

On 27/04/2023 23:19, Robert Ramey via Boost wrote: > in boost/config/detail/suffix.hpp > > I find this bit of code: > > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? As already mentioned, the original logic (and this dates back to C++98 or maybe even earlier!) was that there was a direct dependency between the "new" iostream operators and std::locale. I'm sure that for 99% of platforms this is redundant now anyway given that everyone supports wchar_t. What's the specific issue this is causing? John.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Gavin Lambert 28 Apr '23

28 Apr '23

On 28/04/2023 13:07, Glen Fernandes wrote: >> in boost/config/detail/suffix.hpp >> I find this bit of code: >> // >> // We can't have a working std::wstreambuf if there is no std::locale: >> // >> # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) >> # define BOOST_NO_STD_WSTREAMBUF >> # endif >> >> and believe it or not. this is now causing me some issues. Is the >> statement above true? Do we know that wide char streams cannot exist >> without std::locale being present? Can anyone shed light on this? > > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf > depends on std::locale. But does it really? I could imagine that in some embedded platform std::locale could be omitted (since it's huge, rarely used, insufficient for purpose, and everyone hates it anyway), and in that implementation it could be presumed that no such dependency exists either, so long as you don't try to actually call the omitted methods.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Glen Fernandes 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 6:13 PM Robert Ramey via Boost < boost(a)lists.boost.org> wrote: > in boost/config/detail/suffix.hpp > I find this bit of code: > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf depends on std::locale. Glen

1 0

BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Robert Ramey 27 Apr '23

27 Apr '23

in boost/config/detail/suffix.hpp I find this bit of code: // // We can't have a working std::wstreambuf if there is no std::locale: // # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) # define BOOST_NO_STD_WSTREAMBUF # endif and believe it or not. this is now causing me some issues. Is the statement above true? Do we know that wide char streams cannot exist without std::locale being present? Can anyone shed light on this? Robert Ramey

1 0