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 <boost@lists.boost.org> 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<fusion::pair< K0 , typename detail::as_fusion_element<D0>::type> , fusion::pair< K1 , typename detail::as_fusion_element<D1>::type> , fusion::pair< K2 , typename detail::as_fusion_element<D2>::type> , fusion::pair< K3 , typename detail::as_fusion_element<D3>::type> , fusion::pair< K4 , typename detail::as_fusion_element<D4>::type> , fusion::pair< K5 , typename detail::as_fusion_element<D5>::type> , fusion::pair< K6 , typename detail::as_fusion_element<D6>::type> , fusion::pair< K7 , typename detail::as_fusion_element<D7>::type> , fusion::pair< K8 , typename detail::as_fusion_element<D8>::type> , fusion::pair< K9 , typename detail::as_fusion_element<D9>::type> , fusion::pair< K10 , typename detail::as_fusion_element<D10>::type> , fusion::pair< K11 , typename detail::as_fusion_element<D11>::type> , fusion::pair< K12 , typename detail::as_fusion_element<D12>::type> , fusion::pair< K13 , typename detail::as_fusion_element<D13>::type> , fusion::pair< K14 , typename detail::as_fusion_element<D14>::type> , fusion::pair< K15 , typename detail::as_fusion_element<D15>::type> , fusion::pair< K16 , typename detail::as_fusion_element<D16>::type> , fusion::pair< K17 , typename detail::as_fusion_element<D17>::type> , fusion::pair< K18 , typename detail::as_fusion_element<D18>::type> , fusion::pair< K19 , typename detail::as_fusion_element<D19>::type> , fusion::pair< K20 , typename detail::as_fusion_element<D20>::type> , fusion::pair< K21 , typename detail::as_fusion_element<D21>::type> , fusion::pair< K22 , typename detail::as_fusion_element<D22>::type> , fusion::pair< K23 , typename detail::as_fusion_element<D23>::type> , fusion::pair< K24 , typename detail::as_fusion_element<D24>::type> , fusion::pair< K25 , typename detail::as_fusion_element<D25>::type> , fusion::pair< K26 , typename detail::as_fusion_element<D26>::type> >( fusion::make_pair<K0>(arg0) , fusion::make_pair<K1>(arg1) , fusion::make_pair<K2>(arg2) , fusion::make_pair<K3>(arg3) , fusion::make_pair<K4>(arg4) , fusion::make_pair<K5>(arg5) , fusion::make_pair<K6>(arg6) , fusion::make_pair<K7>(arg7) , fusion::make_pair<K8>(arg8) , fusion::make_pair<K9>(arg9) , fusion::make_pair<K10>(arg10) , fusion::make_pair<K11>(arg11) , fusion::make_pair<K12>(arg12) , fusion::make_pair<K13>(arg13) , fusion::make_pair<K14>(arg14) , fusion::make_pair<K15>(arg15) , fusion::make_pair<K16>(arg16) , fusion::make_pair<K17>(arg17) , fusion::make_pair<K18>(arg18) , fusion::make_pair<K19>(arg19) , fusion::make_pair<K20>(arg20) , fusion::make_pair<K21>(arg21) , fusion::make_pair<K22>(arg22) , fusion::make_pair<K23>(arg23) , fusion::make_pair<K24>(arg24) , fusion::make_pair<K25>(arg25) , fusion::make_pair<K26>(arg26)); GEOMETRY: 3130 lines skipped... BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_MID() (srs::spar::proj_tmerc(),srs::spar::lat_0<>(0),srs::spar::lon_0<>(23),srs::spar::k<>(1),srs::spar::x_0<>(500000),srs::spar::y_0<>(0)) BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_END() BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_BEG(epsg, 3131) srs::spar::parameters<srs::spar::proj_tmerc,srs::spar::lat_0<>,srs::spar::lon_0<>,srs::spar::k<>,srs::spar::x_0<>,srs::spar::y_0<>,srs::spar::ellps_grs80,srs::spar::units_m,srs::spar::no_defs> BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_MID() (srs::spar::proj_tmerc(),srs::spar::lat_0<>(0),srs::spar::lon_0<>(24),srs::spar::k<>(1),srs::spar::x_0<>(500000),srs::spar::y_0<>(0)) BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_END() BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_BEG(epsg, 3132) srs::spar::parameters<srs::spar::proj_tmerc,srs::spar::lat_0<>,srs::spar::lon_0<>,srs::spar::k<>,srs::spar::x_0<>,srs::spar::y_0<>,srs::spar::ellps_grs80,srs::spar::units_m,srs::spar::no_defs> BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_MID() (srs::spar::proj_tmerc(),srs::spar::lat_0<>(0),srs::spar::lon_0<>(25),srs::spar::k<>(1),srs::spar::x_0<>(500000),srs::spar::y_0<>(0)) BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_END() BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_BEG(epsg, 3133) srs::spar::parameters<srs::spar::proj_tmerc,srs::spar::lat_0<>,srs::spar::lon_0<>,srs::spar::k<>,srs::spar::x_0<>,srs::spar::y_0<>,srs::spar::ellps_grs80,srs::spar::units_m,srs::spar::no_defs> BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_MID() (srs::spar::proj_tmerc(),srs::spar::lat_0<>(0),srs::spar::lon_0<>(26),srs::spar::k<>(1),srs::spar::x_0<>(500000),srs::spar::y_0<>(0)) BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_END() BOOST_GEOMETRY_PROJECTIONS_DETAIL_SRID_TRAITS_BEG(epsg, 3134) PHOENIX : template <typename Context, typename Cond, typename Cases> result_type evaluate( Context const & ctx , Cond const & cond , Cases const & cases , mpl::int_<29> , mpl::true_ ) const { typedef typename proto::result_of::flatten<Cases const&>::type flat_view_type; typedef typename fusion::result_of::begin<flat_view_type>::type flat_view_begin; flat_view_type flat_view(proto::flatten(cases)); typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 0 >::type >::type case0; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case0 , 0 >::type >::type >::type case_label0; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 1 >::type >::type case1; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case1 , 0 >::type >::type >::type case_label1; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 2 >::type >::type case2; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case2 , 0 >::type >::type >::type case_label2; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 3 >::type >::type case3; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case3 , 0 >::type >::type >::type case_label3; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 4 >::type >::type case4; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case4 , 0 >::type >::type >::type case_label4; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 5 >::type >::type case5; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case5 , 0 >::type >::type >::type case_label5; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 6 >::type >::type case6; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case6 , 0 >::type >::type >::type case_label6; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 7 >::type >::type case7; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case7 , 0 >::type >::type >::type case_label7; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 8 >::type >::type case8; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case8 , 0 >::type >::type >::type case_label8; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 9 >::type >::type case9; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case9 , 0 >::type >::type >::type case_label9; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 10 >::type >::type case10; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case10 , 0 >::type >::type >::type case_label10; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 11 >::type >::type case11; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case11 , 0 >::type >::type >::type case_label11; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 12 >::type >::type case12; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case12 , 0 >::type >::type >::type case_label12; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 13 >::type >::type case13; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case13 , 0 >::type >::type >::type case_label13; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 14 >::type >::type case14; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case14 , 0 >::type >::type >::type case_label14; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 15 >::type >::type case15; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case15 , 0 >::type >::type >::type case_label15; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 16 >::type >::type case16; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case16 , 0 >::type >::type >::type case_label16; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 17 >::type >::type case17; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case17 , 0 >::type >::type >::type case_label17; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 18 >::type >::type case18; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case18 , 0 >::type >::type >::type case_label18; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 19 >::type >::type case19; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case19 , 0 >::type >::type >::type case_label19; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 20 >::type >::type case20; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case20 , 0 >::type >::type >::type case_label20; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 21 >::type >::type case21; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case21 , 0 >::type >::type >::type case_label21; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 22 >::type >::type case22; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case22 , 0 >::type >::type >::type case_label22; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 23 >::type >::type case23; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case23 , 0 >::type >::type >::type case_label23; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 24 >::type >::type case24; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case24 , 0 >::type >::type >::type case_label24; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 25 >::type >::type case25; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case25 , 0 >::type >::type >::type case_label25; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 26 >::type >::type case26; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case26 , 0 >::type >::type >::type case_label26; typedef typename fusion::result_of::deref< typename fusion::result_of::advance_c< flat_view_begin , 27 >::type >::type case27; typedef typename proto::detail::uncvref< typename proto::result_of::value< typename proto::result_of::child_c< case27 , 0 >::type >::type >::type case_label27; switch(boost::phoenix::eval(cond, ctx)) TYPEOF: typedef v_iter<vector91< P0 , P1 , P2 , P3 , P4 , P5 , P6 , P7 , P8 , P9 , P10 , P11 , P12 , P13 , P14 , P15 , P16 , P17 , P18 , P19 , P20 , P21 , P22 , P23 , P24 , P25 , P26 , P27 , P28 , P29 , P30 , P31 , P32 , P33 , P34 , P35 , P36 , P37 , P38 , P39 , P40 , P41 , P42 , P43 , P44 , P45 , P46 , P47 , P48 , P49 , P50 , P51 , P52 , P53 , P54 , P55 , P56 , P57 , P58 , P59 , P60 , P61 , P62 , P63 , P64 , P65 , P66 , P67 , P68 , P69 , P70 , P71 , P72 , P73 , P74 , P75 , P76 , P77 , P78 , P79 , P80 , P81 , P82 , P83 , P84 , P85 , P86 , P87 , P88 , P89 , P90>, boost::type_of::constant<int,0> > begin; typedef P0 item0; typedef P1 item1; typedef P2 item2; typedef P3 item3; typedef P4 item4; typedef P5 item5; typedef P6 item6; typedef P7 item7; typedef P8 item8; typedef P9 item9; typedef P10 item10; typedef P11 item11; typedef P12 item12; typedef P13 item13; typedef P14 item14; typedef P15 item15; typedef P16 item16; typedef P17 item17; typedef P18 item18; typedef P19 item19; typedef P20 item20; typedef P21 item21; typedef P22 item22; typedef P23 item23; typedef P24 item24; typedef P25 item25; typedef P26 item26; typedef P27 item27; typedef P28 item28; typedef P29 item29; typedef P30 item30; typedef P31 item31; typedef P32 item32; typedef P33 item33; typedef P34 item34; typedef P35 item35; typedef P36 item36; typedef P37 item37; typedef P38 item38; typedef P39 item39; typedef P40 item40; typedef P41 item41; typedef P42 item42; typedef P43 item43; typedef P44 item44; typedef P45 item45; typedef P46 item46; typedef P47 item47; typedef P48 item48; typedef P49 item49; typedef P50 item50; typedef P51 item51; typedef P52 item52; typedef P53 item53; typedef P54 item54; typedef P55 item55; typedef P56 item56; typedef P57 item57; typedef P58 item58; typedef P59 item59; typedef P60 item60; typedef P61 item61; typedef P62 item62; typedef P63 item63; typedef P64 item64; typedef P65 item65; typedef P66 item66; typedef P67 item67; typedef P68 item68; typedef P69 item69; typedef P70 item70; typedef P71 item71; typedef P72 item72; typedef P73 item73; typedef P74 item74; typedef P75 item75; typedef P76 item76; typedef P77 item77; typedef P78 item78; typedef P79 item79; typedef P80 item80; typedef P81 item81; typedef P82 item82; typedef P83 item83; typedef P84 item84; typedef P85 item85; typedef P86 item86; typedef P87 item87; typedef P88 item88; typedef P89 item89; typedef P90 item90; typedef constant<int,1> item91; typedef constant<int,1> item92; typedef constant<int,1> item93; typedef constant<int,1> item94; typedef constant<int,1> item95; typedef constant<int,1> item96; typedef constant<int,1> item97; typedef constant<int,1> item98; typedef constant<int,1> item99; typedef constant<int,1> item100; typedef constant<int,1> item101; typedef constant<int,1> item102; typedef constant<int,1> item103; typedef constant<int,1> item104; typedef constant<int,1> item105; typedef constant<int,1> item106; typedef constant<int,1> item107; typedef constant<int,1> item108; typedef constant<int,1> item109; typedef constant<int,1> item110; typedef constant<int,1> item111; typedef constant<int,1> item112; typedef constant<int,1> item113; typedef constant<int,1> item114; typedef constant<int,1> item115; typedef constant<int,1> item116; typedef constant<int,1> item117; typedef constant<int,1> item118; MPL: template< typename T1, typename T2, typename T3, typename T4, typename T5 , typename T6, typename T7, typename T8, typename T9, typename T10 , typename T11, typename T12, typename T13, typename T14, typename T15 , typename T16, typename T17, typename T18, typename T19, typename T20 > struct deque_count_args { BOOST_STATIC_CONSTANT(int, value = is_deque_arg<T1>::value + is_deque_arg<T2>::value + is_deque_arg<T3>::value + is_deque_arg<T4>::value + is_deque_arg<T5>::value + is_deque_arg<T6>::value + is_deque_arg<T7>::value + is_deque_arg<T8>::value + is_deque_arg<T9>::value + is_deque_arg<T10>::value + is_deque_arg<T11>::value + is_deque_arg<T12>::value + is_deque_arg<T13>::value + is_deque_arg<T14>::value + is_deque_arg<T15>::value + is_deque_arg<T16>::value + is_deque_arg<T17>::value + is_deque_arg<T18>::value + is_deque_arg<T19>::value + is_deque_arg<T20>::value ); };
On Tue, Oct 8, 2024 at 9:56 AM Kostas Savvidis <kotika98@yahoo.com> 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. 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 <kotika98@yahoo.com> 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:
TYPEOF:
typedef v_iter<vector91< P0 , P1 , P2 , P3 , P4 , P5 , P6 , P7 , P8 , P9 , P10 , P11 , P12 , P13 , P14 , P15 , P16 , P17 , P18 , P19 , P20 , P21 , P22 , P23 , P24 , P25 , P26 , P27 , P28 , P29 , P30 , P31 , P32 , P33 , P34 , P35 , P36 , P37 , P38 , P39 , P40 , P41 , P42 , P43 , P44 , P45 , P46 , P47 , P48 , P49 , P50 , P51 , P52 , P53 , P54 , P55 , P56 , P57 , P58 , P59 , P60 , P61 , P62 , P63 , P64 , P65 , P66 , P67 , P68 , P69 , P70 , P71 , P72 , P73 , P74 , P75 , P76 , P77 , P78 , P79 , P80 , P81 , P82 , P83 , P84 , P85 , P86 , P87 , P88 , P89 , P90>, ...
Where are you seeing this code?
On 8 Oct 2024, at 20:08, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Kostas Savvidis wrote:
TYPEOF:
typedef v_iter<vector91< P0 , P1 , P2 , P3 , P4 , P5 , P6 , P7 , P8 , P9 , P10 , P11 , P12 , P13 , P14 , P15 , P16 , P17 , P18 , P19 , P20 , P21 , P22 , P23 , P24 ,
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
Kostas Savvidis wrote:
On 8 Oct 2024, at 20:08, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Kostas Savvidis wrote:
TYPEOF:
typedef v_iter<vector91< P0 , P1 , P2 , P3 , P4 , P5 , P6 , P7 , P8 , P9 , P10 , P11 , P12 , P13 , P14 , P15 , P16 , P17 , P18 , P19 , P20 , P21 , P22 , P23 , P24 ,
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 <boost@lists.boost.org> wrote:
Kostas Savvidis wrote:
On 8 Oct 2024, at 20:08, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Kostas Savvidis wrote:
TYPEOF:
typedef v_iter<vector91< P0 , P1 , P2 , P3 , P4 , P5 , P6 , P7 , P8 , P9 , P10 , P11 , P12 , P13 , P14 , P15 , P16 , P17 , P18 , P19 , P20 , P21 , P22 , P23 , P24 ,
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 <boost@lists.boost.org> 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 <boost@lists.boost.org> wrote:
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