Back when we still used boost::*_ptr, we just hacked boost to do this. It required about a half dozen or so mods to the boost headers, and we could turn it on and off for different types, as needed.
Now that we use std::*_ptr it's not quite so trivial to do since we do not vendor the C++ stdlib, but for those of using open source, this is still possible.
I think it offers more flexibility than the approach described in TFA.
Just take a look at the heap, and see what's there. If an object is leaking then the heap will be full of that kind of object. If it's a problematic leak, then the excess pointers will be easy to spot.
operator->, operator= and the copy constructor(s) are in the hot path for std::*_ptr ... you do not want them cluttered with debugging code ... until you do.
I'm talking about having to change existing code to use the library, to enable the analysis. I don't want to do that. I don't care much how they make it happen... Ideally, it could be done with `LD_PRELOAD` tricks but that won't work because of the templated nature of smart pointers.
when we hacked boost::*_ptr to do this, we used an environment variable to turn on the types we wanted traced. there would have no point in tracing every type that was managed with smart pointers, so there has to be at least 1 line of code modification just to identify what you wanted traced.
Back when we still used boost::*_ptr, we just hacked boost to do this. It required about a half dozen or so mods to the boost headers, and we could turn it on and off for different types, as needed.
Now that we use std::*_ptr it's not quite so trivial to do since we do not vendor the C++ stdlib, but for those of using open source, this is still possible.
I think it offers more flexibility than the approach described in TFA.
> for those of using open source
That should be just about everybody. MSVC STL was open sourced several years ago, so you'd have to be working on something pretty obscure/old.
My advice is don't ever give anyone the idea you know how to debug reference counting memory issues (or really any kind of memory management issues).
You'll stay employed, but you won't like it.
But I also happen to like CBT, so I think this qill be fun!
Hire me! I can debug shared_ptr cycles and other leaks. I will bring my own build of valgrind, clamps, and a car battery!
Just take a look at the heap, and see what's there. If an object is leaking then the heap will be full of that kind of object. If it's a problematic leak, then the excess pointers will be easy to spot.
It really sucks to have to change code so much to do the analysis. I guess it's a simple change that can be automated but ugh...
operator->, operator= and the copy constructor(s) are in the hot path for std::*_ptr ... you do not want them cluttered with debugging code ... until you do.
I'm talking about having to change existing code to use the library, to enable the analysis. I don't want to do that. I don't care much how they make it happen... Ideally, it could be done with `LD_PRELOAD` tricks but that won't work because of the templated nature of smart pointers.
when we hacked boost::*_ptr to do this, we used an environment variable to turn on the types we wanted traced. there would have no point in tracing every type that was managed with smart pointers, so there has to be at least 1 line of code modification just to identify what you wanted traced.