Important: Please read the Qt Code of Conduct -

Should ui components use smart pointers?

  • Should ui components use smart pointers?

    like for example, instead of declaring QPushButton *button;

    do QSharePointer<QPushButton> button;?

    is weak pointer better in this case?

    I remember if QObject has a parent, the parent with manage the object with a smart pointer, therefore if we declare a QPushButton with smart pointer, we will see error when assigning it to a parent window. Because we created two reference counters for the same object.

    I seem to never see Qt examples use QSharepointer for UI.

    I really want to replace all my pointers to smart pointers, I want to know the limitation.

  • As you described already UIs do not use smart pointers since there is no need to. Use the internal mechanism and you should be fine. IMHO you should not mess around and mix that part with smart pointer and think that you are doing better.

    The smart pointers I am using are boost shared pointers and I never changed to QSharedPointer. My simple decision criteria is using for UIs the internal mechanism and all other I am typically using shared pointers.

    Hope that helps.

  • Thank you.

    I'd like certain consistency. If I want to use smartpointers, I'd like everything smartpointers.

    but I guess you are right, don't mix the ui part with smart pointers.

  • Consistency is always a good point. Especially when it comes to programming.

    However, see it this way. When using smart pointers you have a smart pointer object which takes a local normal pointer you had it over to the object. The same thing you are doing a lot when programming UI. As you have mentioned already the smart pointer functionality is part of all those classes.
    The normal pointer you start off with is something you are not getting away. So all is consistent.

  • Moderators

    There is this doctrine spreading that pointers are evil. It's not to the "goto" point yet but these days it's usually a good time to think again whenever you see *. On the other hand it's not a good thing to just splat smart pointer wherever you see a star. They can be cheap but never are free.

    For me it was a hard thing to move to this new mantra, especially considering that Qt is basically designed around pointers. When you use a library like Qt it's often more consistent to abide to its way of doing things, even if they're not the latest bling, than to try to forcibly bend it to whatever shape you have in mind.
    C++11 helps here a lot, because now you can often hide those pointers from the eye and still keep the Qt way of doing things. For example:
    auto someAction = someMenu->addAction("Whatever");
    You don't even have to think about types, pointers (or even smartpointers!). It just does the right thing.

  • If you feel that you need smart pointers to ensure proper object destruction, you should re-examine your design first.
    I am of the school that the developer should understand when object are created and when they are destroyed. It's part of the code design.
    Smart pointers suddenly suggest that you no longer need to do that. But that's wrong: A pointer might be called "smart", but it still can't know what you intend to do. The results might be dangling objects, and erratic program behavior.

    Design your object lifetime. There will be situations where you just cannot know the proper time to destroy an object - in such a case it might be a good design decision to use a smart pointer. Before you use it, however, understand exactly how it behaves, and use the right smart pointer for the job at hand.

Log in to reply