c++ has a little bit of a learning curve, I think.

Used smart pointers everywhere in my code because I heard that's what we gotta do nowadays.

When learning about shared vs unique vs weak, I disregarded weak pointers because I didn't really understand them.

"That sounds like something for liberal pansies", I said to myself, then continued on with my STRONG shared and unique pointers.

Now my app leaks memory like a MOTHERFUCKER, if you can believe that.

So now I need to go back and manage my object lifetime with more intent instead of just making everything a shared pointer. Fuckin circular references. Fuckin reaping what I fuckin sow. God damn.

C++ is very hands on with object lifetime. Smart pointers help some.

IIRC smart pointers don't null themselves if the object is deleted. That is one thing I love about QPointer from Qt. They get notified if the object is deleted and nulls the pointer.

Do you delete?

@Demolishun The smart pointers should be the only things actually doing the actual deleting. Smart pointers should never actually be in an invalid state.

@electrineer never!

@AlgoRythm yeah, QPointer has a different design.

I think I am a Qt dev rather than a C++ dev sometimes.

Getting lifetimes right in C++ in an application where you have all sorts of different states and components being brought up and shut down (i.e. entire windows) is very tricky.

And weak_ptr doesn't solve it imo. It can prevent leaks but it might also extend your lifetime of your object in some other thread, which can directly change your behavior...

@LotsOfCaffeine Can you give me a pointer to read more on this? this is the first time I hear about weak pointers influencing lifetimes (except the hopefully unobservable lifetime of the counters themselves) and as an avid user of cross-thread refcounts I feel it's relevant to me.

@aviophille everything you said is completely true and you are NOT safe

@lorentz can't say I read about it but it has happened to me.

Once got a bug report of our system crashing during its shutdown (which should be clean, with exit code 0 and all). After broot forcing a whole bunch I added a check during the shutdown to see if the shared_ptr we're resetting is actually at refcount 1 when we do. Turns out, in some very rare cases, another thread had a weak_ptr locked to a shared_ptr and kept one particular component alive (and then destroyed it, in the worker thread).

Of course this shouldn't crash the application. In fact it shouldn't have happened to begin with, the thread really should be joined properly. But that particular project's software structure is a mess and that's just what I gotta deal with.

We now use this refcount check to see if we're joining all threads and everything correctly. Oh also we have circular dependencies between components :)