- Boost - lists.boost.org

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

30 Apr '23

On 4/30/23 15:18, Peter Dimov via Boost wrote: > Andrey Semashev wrote: >> 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? > > It's a tradeoff as any other. You need <latch>. Since it's trivial to implement > over C++11, you add a private implementation to your library. This duplicates > the one in Boost.Thread. But you don't want to depend on Boost.Thread, > because if you don't need C++03 support or thread interruption, it duplicates > the standard library, and adds 50 dependencies. > > https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… It doesn't really matter how many dependencies Boost.Thread adds. What matters is how expensive <boost/thread/latch.hpp> is. Personally, I would have no problem depending on it, if I really needed this component. > In addition, the code duplication in Compat will gradually disappear as its > minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming > we have it) will effectively disappear at 14. latch.hpp will disappear at 20. This will happen when? I don't imagine Boost is raising its minimum C++ version to C++14, let alone 20 any time soon. > We can't clean up Boost.Thread in this manner even if we impose a C++11 > requirement, since it has to provide its own primitives for everything > because of thread interruption. > > But you know this because that's what the Sync intro says. :-) Regarding thread interruption, we could simply deprecate it and remove over time. I think, that was one of the ideas behind Boost.Sync - e.g. boost::mutex from Boost.Thread would get deprecated in favor of boost::sync::mutex from Boost.Sync. It might not be too late to revive Boost.Sync and add a latch implementation there.

1 0

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

30 Apr '23

Andrey Semashev wrote: > 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? It's a tradeoff as any other. You need <latch>. Since it's trivial to implement over C++11, you add a private implementation to your library. This duplicates the one in Boost.Thread. But you don't want to depend on Boost.Thread, because if you don't need C++03 support or thread interruption, it duplicates the standard library, and adds 50 dependencies. https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#w… In addition, the code duplication in Compat will gradually disappear as its minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming we have it) will effectively disappear at 14. latch.hpp will disappear at 20. We can't clean up Boost.Thread in this manner even if we impose a C++11 requirement, since it has to provide its own primitives for everything because of thread interruption. But you know this because that's what the Sync intro says. :-)

1 0

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

30 Apr '23

On 4/30/23 14:58, Peter Dimov via Boost wrote: > 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? It doesn't fully duplicate Boost.Thread. It added new synchronization primitives and added support for different timing libraries besides Boost.Chrono. There was another idea that Boost.Thread became too large and difficult to maintain. So the thread synchronization primitives were supposed to be extracted to a separate library, Boost.Sync, leaving only thread launching and high-level tools like future/promise, async and thread pool in Boost.Thread.

1 0

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