- Boost - lists.preview.boost.org

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