On 4/1/24 19:01, Ivan Matek via Boost wrote:
Also I mentioned bigger issue is that this policy makes boost suffer from same bad image that C++ has. Nothing ever gets removed, even if it is totally obsolete. auto_ptr still compiles with --std=c++23 in gcc(although it emits a warning). Like why would you enable this kind of terrible code in 2024?
I have first-hand experience with the above. We have a C++03 library that isn't going to be upgraded any time soon, if ever, which uses auto_ptr all over the place, including public interfaces. Our code base is C++17, and we're also using other libraries that require C++17, and it's not unrealistic that we move beyond that in not too distant future (more likely, by being forced by one of our dependencies). So yeah, like it or not, auto_ptr and lots of other deprecated and frowned upon code still exist in 2024, and will likely exist for many years to come. Which is why I think removing stuff from the standard library is wrong.
If some companies do not want to invest into upgrading that is their problem, not a problem for entire community.
For the life of me, I don't get why "the entire community" has an issue with auto_ptr, or boost::shared_ptr or whatever. Is there someone forcing you to use these components when you can use the more "modern" alternatives? You argue that everyone using auto_ptr must up and rewrite their code at once, and yet you have a problem with converting your code from boost::shared_ptr to std::shared_ptr. I wonder why. This "let's destroy C++03 and live in the C++Latest wonderland" really sounds like a religious mantra sometimes, while the pragmatic truth is that you often use what you must, and for that to be even possible the damn components must exist in the first place.