From a short look at the code without understanding the whole stuff I would guess that internally there is only a QObject pointer is stored. So it must be a QObject to track the lifetime.

@alex_malyu The original post is some 2 months old. So I wrote a whole lot of a post in reply to the original question ... well didn't my ears burn, when I noticed the post time ... I felt like a complete idiot. :)

Awesome, thank you very much!

Hello, Both inputs are highly appreciated. I understand better how, when and why should I choose pointers over refs. I'm still reading some stuff here and there on how to produce some good code. Memory management has always been a doozy matter in C++ and i just can't get this Stroustrup quote out of my head : "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off. ". Thanks again for replying so quickly, I will apply everything i've learned here on my work asap. Best regards.

You don't actually need to subclass QAbstractItemModel with your current approach. Your QList<SoundObject*> already acts as the model. In fact, I want to use a QSortFilterProxyModel in C++ to filter what I want to display, and a TableView in QML to enable multiple selection, which is not available in ListView :( So I had to subclass QAbstractItemModel, and add a custom role that I named "data", which returns the QObject*. Thank you for everything, I'm going to implement this right away. If I find something useful, I will share it here. And if someone has another idea/vision of how to solve the problem, don't hesitate to share too !

Thanks I was expecting as much. Also thanks for the code, I will probably replace my foreach with something similar.