While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
Yes, learn to use one and point it to a C++ Github project full of shared pointers.
While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
embarrassing