2

I use Qt designer to design the UI. When implementing the design into the code, I use the multiple inheritance approach. There's no real reason why I use this method, I just found it to be easier.

Anyway, when I looked into the generated header file I noticed in the setupUi() function that everything is allocated in heap. I don't really need the objects to outlive it's parent and according to this, in my case, it shouldn't be allocated in heap.

In situations where the parent object is just a small modal dialog allocated in stack, wouldn't it be a waste that it's UI objects are allocated in heap?

Is there a work-around for this? Should I just stop worrying? I haven't found a situation where this has become a problem but I'm still curious about it. In fact, it's not a problem at all. I just want to know.

Community
  • 1
  • 1
Subaru Tashiro
  • 2,166
  • 1
  • 14
  • 29

2 Answers2

2

Stop worrying ... While the design of QT doesn't preclude assembling a set of widgets on the stack. There is an ownership hierarchy between parent and child widgets. A parent widget owns all its children. Stack allocation could break that causing double deletes if the allocations where not done in the correct order (children first), see the QT documentation on this subject (@Subaru dug this up), personally to me an caveat like this usually means it's not really a good idea. Iirc 'QObject' and 'QWidget' can't be copied for that reason.

Harald Scheirich
  • 9,676
  • 29
  • 53
  • But could those heap allocations be avoided by coding the interface yourself, instead of using the designer? I'm asking out of curiosity... – Adri C.S. Jan 25 '13 at 11:22
  • I've already tried allocating declared children in stack, and that doesn't seem to cause any problems. Am I missing something? – Subaru Tashiro Jan 25 '13 at 11:44
  • And according to [THIS](http://doc.qt.digia.com/qt/objecttrees.html), the mechanism prevents double deletes because as soon as a child is deleted through unstacking or calling 'delete' on it, it is also removed as a child, and if it is not a child anymore, the previous parent will have nothing to do with it. Therefore not causing double deletes. – Subaru Tashiro Jan 25 '13 at 12:03
  • @Subaru order dependent code will cause you neverending pain and suffering ;), I would really stick with the heap allocs and make your life a lot easier – Harald Scheirich Jan 25 '13 at 12:28
  • It won't double delete, it will just outright explode because you'd have to pass the address of a var on the stack for parent/child widgets, then the parent will attempt to call operator delete on the stack allocated var. – paulm Jan 25 '13 at 12:32
  • @HaraldScheirich alright. One final thing, does that mean I should 'always' allocate QObjects in heap and declare it as a child no matter what? Just include it in your above answer and i'm gonna approve it. I apologize for my inexperience and thank you very much. – Subaru Tashiro Jan 25 '13 at 12:35
2

General Qt practice is to use heap allocation for any QObject unless it's lifetime is limited to the current scope. This may seem wasteful, but in the context of building a UI any performance impact will be negligible.

Also note that due to Qt's extensive use of the pimpl idiom, every created QObject has an internal QObjectPrivate which is always heap allocated, so it's simply not possible to keep everything on the stack.

So I would suggest that you stop worrying. :)

Dan Milburn
  • 5,600
  • 1
  • 25
  • 18
  • "unless it's lifetime is limited to the current scope" Can you please expand on this? – Subaru Tashiro Jan 25 '13 at 12:48
  • I meant as in your case, there's rarely any need to heap-allocate a modal dialog since it should be destroyed shortly after execution. As I see it, it's mostly a matter of lifetime management: if an object should be destroyed with its parent, it's usually easiest to put it on the heap and let Qt handle deletion. If not, use some other means (stack allocation, smart pointers) to control its lifetime. – Dan Milburn Jan 25 '13 at 13:27