Helpful for derived class that do not store KConfig settings as children items.
Sort of a guard if one registers manually a KCoreConfigSkeleton and then deallocate it.
It is not an alternative, configChanged is a KCoreConfigSkeleton's signal that will trigger a settingsChanged.
I think that was David's point. If the object is deallocated it'll emit the destroyed signal before passing away. By connecting to that signal you could remove the pointer from the list (instead of having a list potentially containing null pointers like now). Personally I don't mind much between both approaches though. QPointer generally leads to less code, you just have to be aware of the null case like for any weak reference pointer.
Still you never clean up that list, it shouldn't grow large, but I'd remove the null pointers from time to time. Possibly at the next registerSettings call or so.
Should be const auto &skeleton now that it's not a simple raw pointer anymore.
It may be needed? Or it is mandatory to call settingsChanged() for proper behavior?
I'm wondering because I'm tempted to say this shall not be necessary and we should perhaps schedule a settingsChanged() call instead when we go back in the event loop?
Space before * not after
Careful there you should use the return value of erase(). It invalidates iterators so it's probably working just by change here (I'd suspect it might crash for instance if it happens to remove the last one in the list).
Even better yet you could spare that loop completely and use remove_if + erase, see:
Well, even though you didn't have a direct use anymore it doesn't mean this patch was useless. I think it'd be worth fixing the last issue I pointed out and merging it. I seem to remember someone else requested this feature.