Agree in the main. Even before smart_ptr's were integrated into the standard, bespoke versions that appeared to some to remove scoping confusion had a tendency to propagate like weeds. In the majority of cases, const correctness, mutability if needed and good scoping concepts removed redundant reference counting run time garbage.
On one project I worked on as a contractor, and quite a large one at that, I removed every single one of them and rescoped the code base. It took a while but performance alone improved by about 400%
Didn't need to say it at all. I probably wasn't being clear enough but I was referring to early versions that were called smart precisely because they removed the need for the programmer to count because they counted themselves. Hence 'smart'. Before boost and others cleaned it all up.
As others are pointing out they have advantages and disadvantages. It all depends on the situation. But they're certainly not free because they have a scope cost. Code size and simplifying compiler optimisation are important too. I think it's worth that pointing out.
the lesson there was not that every programmer needs to painstakingly thing through every detail of scope management, it's that the problem needed to be solved comprehensively and integrated into the standard library.
That was one lesson. There were others as well, and they're related. It was a temptation to believe that they were a kind of magic bullet that acted as a scoped resource scavenger. Mostly vtable jump resource cleanups through dtors in the usual way.
Unfortunately it was slow, and as others have mentioned, sometimes difficult to debug and heap errors can propagate out of order, depending on other conditions.
I'm in no doubt about the value of the auto_ptr variants. However I'm often brought in to speed up projects that don't meet performance requirements, and it often entails rethinking structure, simplification, replacing generalised ctor dtor lists, and rediscovering where const references, independently of move semantics, lead to algorithmic questions that need reexamining. This leads back to encompassing scope, and from there it's often the right thing to institute a better model.
The benefit can be a lot less instructions and resultant speedups.
Perhaps I've had too many of these jobs, but hey, it's a living.
On one project I worked on as a contractor, and quite a large one at that, I removed every single one of them and rescoped the code base. It took a while but performance alone improved by about 400%