Boost logo

Boost :

From: Ivan Matek (libbooze_at_[hidden])
Date: 2024-04-01 15:03:34


On Sun, Mar 31, 2024 at 9:17 PM Vinnie Falco via Boost <
boost_at_[hidden]> wrote:

> That is probably true, but removing Boost.SmartPtr does nothing to solve
> it. If the maintainers of a code base are bothered by a mixture of smart
> pointer types, they must refactor the code base in question to use only one
> type instead. boost::shared_ptr and std::shared_ptr are almost identical,
> so an automated search and replace would likely suffice.
>
> Thanks
>

Well it forces people to do it. :) I have seem a lot of codebases fix
parts of their technical debt just because they had to, e.g.. they wanted
to upgrade boost or compiler and now some UB or deprecated code needed to
be fixed.
If you do not care about people who do not care about their code that is
fair, but there is one more thing...

Removing stuff has positive PR effect since as a user I have feeling that
addition to boost are always amazing, but there is no cleanup and it gives
boost a bad image. I know people have done amazing work on existing
libraries like unordered, but I really really have no idea why boost::array
has not been removed 5+ years ago.
This is nothing against boost::array, if it was not a great library it
would not be in std::, but for me natural process would be to remove it
from boost.
Or why is

#include <boost/foreach.hpp>

still available in latest boost? Literally it has been 10+ years
since I have ever seen it in prod. It was amazing for the time period
in which it arrived, now it is just makes boost look bad.

Similarly let's say that it is 2032, there is still no AGI :) , humans are
still coding C++, reflection is in C++ since 2026, why not remove
Boost.Serialization? It has worked amazingly for 20+ years, but why keep it
in boost?

This is just my opinion of 1 user and I want to say that all the libraries
mentioned above were amazing at the time they arrived.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk