Thanks! Will have to play around with smart pointers a while before I feel firm enough to make the switch. It’s a sweeping change that adds a lot of verbosity! Interestingly, doing it right often looks more convoluted in C++ than doing it wrong
Juce however seems just not yet prepared to deal with smart pointers:
TopLevelWindow has no obvious owner, so there’s no destination for a unique__ptr to go if I just want TopLevelWindowManager to take control.
The juce::Component API expects raw pointers across the board.
I still need WeakReference for non-pointer objects (e.g. tree & list models).
So the best place to use smart pointers for now is with structures you fully control yourself, which is still very useful, of course.
It begins to dawn on me that I vastly underestimated the effort of making this workable (kudos to Jules and ROLI for their achievements). It’s a time consuming black hole. I spend 80% of my time thinking about how to technically store and represent objects (I’m used to 2%).
The shallow level of abstraction achievable with C++ is also disappointing. For instance, lacking reflection, there’s no way for UIEditor to present to the user a model’s member functions that technically (by method signature) match a particular component and purpose (combo box, or auto-complete).
I mean it’s still fun, but at this time I have a hard time imagining how this could eventually meet the productivity requirements of large projects.