Boost - Dev mailing list wrote
Glen Fernandes wrote:
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
And, since we managed to not get the array form of make_shared into C++17, boost::make_shared will remain relevant a few more years.
This reminds me of the saying "looking for the lost keys under the street light." We have a problem, what can we do? I know, let's deprecate and remove boost::shared_ptr!
I did not intend to imply that boost::shared_ptr was a problematic part of boost. I just expect that for most of us, we should prefer std::shared_ptr. Thus, a note should be put in the documentation that there is also a standard shared_ptr. I just took a few minutes to look at the documentation and see that this information is already present, so shared_ptr has no problems in that regard. I just would prefer if this documentation was put at a more prominent position. For shared_ptr, there is another problem, however. I went to the track list and found a number of open bugs. Not, I guess, because shared_ptr is buggy, but because the bugs are not maintained. As an example, the newest bug #12604 is still marked as open: I guess it should not be. The same is the case for the second bug I examined (8485). Also bugs such as 6829 (slow in MSVC) should not be marked as such. If a function is slower than it could be it should be marked as an enhancement/feature request, not as a bug. Except, of course, if the function is so slow that it is absolutely useless. /Peter -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.