|
|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-04-01 16:37:16
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk