Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json?
Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof
Yes for marking old libraries as obsolete, as it does not convey a "might be removed" tag. No for marking as deprecated for this reason. Yes for hiding obsolete libraries by default. Strong no for ever even thinking of removing a Boost library from 1.x. Strong no for marking as obsolete libraries which are using obsolete libraries in the implementation. This one would force me to drop parts of MSM which might be used in production code and I strongly oppose the idea. Christophe
Christophe Henry wrote:
Strong no for ever even thinking of removing a Boost library from 1.x.
I agree in principle except for "Compatibility", a "library" that was already obsolete 20 years ago and whose only purpose today is to enable people to introduce mysterious compile errors into their code. I've already suggested its removal to Glen. https://github.com/boostorg/compatibility
On Tue, Oct 8, 2024 at 8:28 AM Christophe Henry via Boost < boost@lists.boost.org> wrote:
Strong no for ever even thinking of removing a Boost library from 1.x.
I looked into how these obsolete libraries are used by other Boost libraries, and they cannot be simply removed. It would be a non-trivial endeavor for related libraries to stop depending on, say, Boost.Move. Unless the library is no longer depended on, it has to stay in the release regardless of opinions for or against removal. Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non-obsolete Boost libraries which use them? Thanks
Vinnie Falco wrote:
Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non- obsolete Boost libraries which use them?
The maintainers of each library are supposed to do whatever they consider serves their users (the users of the specific library) best.
Am 08.10.2024 um 18:31 schrieb Peter Dimov via Boost:
Vinnie Falco wrote:
Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non- obsolete Boost libraries which use them? The maintainers of each library are supposed to do whatever they consider serves their users (the users of the specific library) best.
This is a fair assessment, and certainly one that's fine for many people. But it's just as fair to take a different perspective: some of the earlier Boost libraries are a huge detriment to users who want to see a larger emphasis on compiler throughput. The perceived laissez-faire stance on that is the reason why e.g. we are actively phasing Boost out of our company codebase wherever we can. Literally every one of them that got rid of Boost by replacing their libraries with modern alternatives from the language, the standard libraries, or more modern 3rd-party alternatives, saw compilation speed improvements *by factors*. This is *after* employing every other imaginable technique on the architectural and structural level, be it in C++ itself, tools, and the build environment. Just my humble position as a user. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Daniela Engert wrote:
Am 08.10.2024 um 18:31 schrieb Peter Dimov via Boost:
Vinnie Falco wrote:
Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non- obsolete Boost libraries which use them?
The maintainers of each library are supposed to do whatever they consider serves their users (the users of the specific library) best.
This is a fair assessment, and certainly one that's fine for many people.
But it's just as fair to take a different perspective: some of the earlier Boost libraries are a huge detriment to users who want to see a larger emphasis on compiler throughput. The perceived laissez-faire stance on that is the reason why e.g. we are actively phasing Boost out of our company codebase wherever we can. Literally every one of them that got rid of Boost by replacing their libraries with modern alternatives from the language, the standard libraries, or more modern 3rd-party alternatives, saw compilation speed improvements *by factors*. This is *after* employing every other imaginable technique on the architectural and structural level, be it in C++ itself, tools, and the build environment.
Compile time improvements by factors is in the users' interest, so this is not incompatible with what I said.
On Tue, Oct 8, 2024 at 10:30 AM Daniela Engert via Boost < boost@lists.boost.org> wrote:
...we are actively phasing Boost out...
What is interesting is that on the one side you have a steady trickle of reports from users who have phased out Boost or are in the process of doing so, and on the other side you have long-time contributors on the mailing list who keep insisting "This is fine." Thanks
On 8 Oct 2024, at 19:14, Vinnie Falco via Boost
wrote: Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non-obsolete Boost libraries which use them?
There are some libraries, including but not limited to the below that contain code I would be ashamed of showing in public by 2030.
Some of those headers are 2,3,5 MB large. The "Slow compilation" complaint might be related to those.
Is there nothing that can be done about this in the next six years?
Cheers,
Kostas
FUSION:
make_map(D0 const& arg0 , D1 const& arg1 , D2 const& arg2 , D3 const& arg3 , D4 const& arg4 , D5 const& arg5 , D6 const& arg6 , D7 const& arg7 , D8 const& arg8 , D9 const& arg9 , D10 const& arg10 , D11 const& arg11 , D12 const& arg12 , D13 const& arg13 , D14 const& arg14 , D15 const& arg15 , D16 const& arg16 , D17 const& arg17 , D18 const& arg18 , D19 const& arg19 , D20 const& arg20 , D21 const& arg21 , D22 const& arg22 , D23 const& arg23 , D24 const& arg24 , D25 const& arg25 , D26 const& arg26)
{
return map
On Tue, Oct 8, 2024 at 9:56 AM Kostas Savvidis
There are some libraries, including but not limited to the below that contain code I would be ashamed of showing in public by 2030. Some of those headers are 2,3,5 MB large. The "Slow compilation" complaint might be related to those. Is there nothing that can be done about this in the next six years?
Judging by the example code which you quoted, I would guess that these things have never been optimized. That is, optimized for compilation speed. Peter has done considerable work in this area for Boost.MP11 and I think Boost.Variant2 (?) which he spent time optimizing. Here is an example: https://github.com/boostorg/mp11/blob/develop/include/boost/mp11/detail/mp_a... It may be possible to breath new performance improvements into those libraries today, by adopting some of Peter's techniques, and this is orthogonal to the question of obsolete libraries ! Thanks
On 10/8/24 20:01, Vinnie Falco via Boost wrote:
On Tue, Oct 8, 2024 at 9:56 AM Kostas Savvidis
wrote: There are some libraries, including but not limited to the below that contain code I would be ashamed of showing in public by 2030. Some of those headers are 2,3,5 MB large. The "Slow compilation" complaint might be related to those. Is there nothing that can be done about this in the next six years?
Judging by the example code which you quoted, I would guess that these things have never been optimized. That is, optimized for compilation speed.
I believe, such code was actually the result of optimization. In C++03, preprocessed code like this is faster to compile than to generate it using preprocessor. Yes, in C++11 we got variadic templates, but updating to those is not always trivial, and someone has to do it. And the compilation time wins are also not guaranteed after the conversion.
Andrey Semashev wrote:
Yes, in C++11 we got variadic templates, but updating to those is not always trivial, and someone has to do it. And the compilation time wins are also not guaranteed after the conversion.
They pretty much are, although I agree with "someone has to do it." Incidentally, people were prevented from doing it, that is, contributing a PR that does it, by our insistence on C++03 support.
Kostas Savvidis wrote:
On 8 Oct 2024, at 20:08, Peter Dimov via Boost
wrote: Kostas Savvidis wrote:
TYPEOF:
typedef v_iter
Where are you seeing this code?
There is this nonsence wrtitten out with up to 200 args.
/boost/typeof vector200.hpp 2.3MB vector150.hpp 1.4MB vector100.hpp 667KB
I don't think so.
On 8 Oct 2024, at 20:23, Peter Dimov via Boost
wrote: Kostas Savvidis wrote:
On 8 Oct 2024, at 20:08, Peter Dimov via Boost
wrote: Kostas Savvidis wrote:
TYPEOF:
typedef v_iter
Where are you seeing this code?
There is this nonsence wrtitten out with up to 200 args.
/boost/typeof vector200.hpp 2.3MB vector150.hpp 1.4MB vector100.hpp 667KB
I don't think so.
Commit 19a9a7e Remove obsolete header files • develop • boost-1.86.0 • boost-1.84.0.beta1 pdimov committed on Oct 11, 2023 Showing 25 changed files with 0 additions and 3,252 deletions. CONGRATULATIONS!!! And material proof that something can be done.
On 10/8/24 19:55, Kostas Savvidis via Boost wrote:
On 8 Oct 2024, at 19:14, Vinnie Falco via Boost
wrote: Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non-obsolete Boost libraries which use them?
There are some libraries, including but not limited to the below that contain code I would be ashamed of showing in public by 2030. Some of those headers are 2,3,5 MB large. The "Slow compilation" complaint might be related to those. Is there nothing that can be done about this in the next six years?
By default, Boost.MPL and Boost.Fusion templates are generated only up to 50 elements. See here, for example: https://github.com/boostorg/mpl/tree/develop/include/boost/mpl/vector/aux_/p... https://github.com/boostorg/fusion/tree/develop/include/boost/fusion/contain... Furthermore, by default both Boost.MPL only use definitions of up to 20 elements (BOOST_MPL_LIMIT_VECTOR_SIZE) and Boost.Fusion - up to 10 (FUSION_MAX_VECTOR_SIZE), so only those headers are being included, unless the user raises that limit by redefining the limit macros. If you have headers for more than 50 elements then you (or the one who built Boost you're using) have generated those headers. Both Boost.MPL and Boost.Fusion provide tools for that in case someone needs more than 50 elements in a container. But again, even if you generate those headers, they don't get included unless you actually request it by raising the limit.
I looked into how these obsolete libraries are used by other Boost libraries, and they cannot be simply removed. It would be a non-trivial endeavor for related libraries to stop depending on, say, Boost.Move. Unless the library is no longer depended on, it has to stay in the release regardless of opinions for or against removal.
I agree,
Therefore the more important question becomes: what level of effort should be invested in removing the dependence on obsolete libraries from the non-obsolete Boost libraries which use them?
What do we gain? I added a new MSM backend. I could have reworked the old one instead. But MSM users do not like me breaking their code. And as I did accidently added a bug while fixing the new backend, it would have been a serious bug for 2 Boost releases. Forcing me to remove usage of MPL would force me to remove the old backend and hope for the best. Sorry, no. I will remove the rest of the MPL in new backends but disagree with getting all of MSM declared obsolete for trying to keep part of it backwards compatible.
On Tue, Oct 8, 2024, at 9:03 PM, Christophe Henry via Boost wrote:
It would be a non-trivial endeavor for related libraries to stop depending on, say, Boost.Move.
Wouldn't it be akin to defining trivial definitions for the macros and preprocessing them? I think this can even be automated with most IDEs (vim will do it for me) or a little libclang script. Other libraries, agreed that it can be non-trivial My $0.02, Seth
On Tue, Oct 8, 2024 at 1:53 PM Seth via Boost
Wouldn't it be akin to defining trivial definitions for the macros and preprocessing them? I think this can even be automated with most IDEs (vim will do it for me) or a little libclang script.
Search for the text "boost/move" in libs/ and get back to me on that :) Thanks
participants (7)
-
Andrey Semashev
-
Christophe Henry
-
Daniela Engert
-
Kostas Savvidis
-
Peter Dimov
-
Seth
-
Vinnie Falco