QMainWindow and std::shared_ptr (segfault at exit)

jsulm

It is even a worse idea to have public static variables! If you have to use them across several cpp files why not just provide a get() method which returns a pointer (no need though to create them via new, just do "return &variable").

SGaist

Hi,

To add to @jsulm, why exactly to you need them in several cpp files ? That smells light a huge tight coupling.

bsomervi

@SGaist Indeed, I was going to ask why signals and slots were not an option for inter class communication rather than holding pointers or references.

Pippin

Thanks everyone for your replies, I'm still a bit confused as to what's best for my project. I wasn't aware of the existence of std::scoped_ptr, so I'll definitely use it if I can't use anything else.

These 7 windows have member functions that show or hide the other windows. For example, WS::Window1 can show WS::Window2 and WS::Window5 if that's what the user wants (they would both appear on top of WS::Window1). So WS::Window1 needs a pointer to WS::Window2 and another pointer to WS::Window5 in its .cpp file.

Same for the other windows, which all show other windows when the user requires it. The user spends his time browsing the 7 windows back and forth. This is why it's much simpler to make all 7 windows global. I'm not sure it's possible/easy to use references (and thus put these windows on the stack rather than on the heap) instead.

What would you guys do?

SGaist

Then you should rather have a dedicated object that handles showing the right window at the right moment.

Pippin

@SGaist Could you elaborate a bit please? How can I do that without causing any memory deletion issues?

bsomervi

@Pippin std::shared_ptr<T> serves two specific purposes, (1) it can be used to extend the lifetime of the heap object instance of T for the owner of the shared_ptr and (2) it does that in a thread safe way so that heap object instances of T can be shared between threads. Note that using std::shared_ptr<T> does not implicitly make the T thread safe, it just makes the sharing mechanism thread safe i.e. the reference count.

There are other subtleties for sharing non-heap objects that involve a custom deletion function but none of the shared_ptr attributes are appropriate for your requirement.

Sorry I have mislead a little, there is no std::scoped_ptr<T>, I used boost::scoped_ptr<T> for so long that I forget it has another name in Standard C++ which is std::unique_ptr<T>. is a much simpler and lightweight class, it simply makes the lifetime of a heap object the same as its own with the exception that you can create the unique_ptr<T> before the T instance if you really want to, also you can explicitly release or change the managed object instance. The other big advantage of std::unique_ptr<T> is that it can be put into a Standard Library container.

SGaist

If you take QTabbedWidget, it's a set of widget that you can switch to by clicking on tab.

What allows your user to switch from one window to another ?

Pippin

@bsomervi Okay thanks again.

@SGaist Basically a QPushButton that shows another window.

bsomervi

@Pippin said:

Same for the other windows, which all show other windows when the user requires it. The user spends his time browsing the 7 windows back and forth. This is why it's much simpler to make all 7 windows global. I'm not sure it's possible/easy to use references (and thus put these windows on the stack rather than on the heap) instead.

Look again at my example, it uses a pointer to a stack object. You are conflating pointer to objects and heap based objects which is wrong, pointers and the heap are different and basically unrelated concepts.

Anyway, listen to what @SGaist is saying as decoupling the relationships between your abstractions (classes) is most important. A good rule of design is to have maximum coupling within an abstraction and minimum coupling between abstractions. That means having classes knowing about each other is usually a bad thing.