Skip to content
  • 0 Votes
    9 Posts
    559 Views
    S

    @CJha said in QComboBox and smart pointer conflict?:

    But in any case I would like to make sure that it is destroyed before the application exits.

    In general this is a good approach. When you write clean code all resources should be freed by your own application (typically RAII in C++). However, when your application closes the OS will free all memory belonging to the application and removes all file handles of the application. Especially in complex applications it can take quite a while to clean up everything in order. In those cases it is a lot more userfriendly to just exit without the clean up. So, don't worry too much about clean up. Still, you should understand why this happens and how it can be avoided.

  • 0 Votes
    3 Posts
    779 Views
    Christian EhrlicherC

    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.

  • 1 Votes
    11 Posts
    6k Views
    kshegunovK

    @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. :)

  • 0 Votes
    4 Posts
    3k Views
    Joel BodenmannJ

    Awesome, thank you very much!

  • 0 Votes
    4 Posts
    3k Views
    L

    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.

  • 0 Votes
    11 Posts
    8k Views
    K

    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 !

  • 0 Votes
    3 Posts
    2k Views
    TheBadgerT

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