Unsolved Should I declare my custom class object or pointer?
-
@Alice
Can you post the implementation of the constructor ofMyClass
?
I think there is the problem to search. The difference between both approaches is just the order when the constructor ofMyClass
is called so maybe there are some dependencies that are not (yet) fullfilled in approach 1? -
I used to have the same problem , which i solved by declaring a pointer .
But , unlike you , i didn't insist on knowing the answer .This very topic shall be taken seriously , because the mistake isn't in the body of his class .
Proof : u can try to create 2 mainWindow classes using Qt Designer , then try to declare one in the body of the other . U'll get the same result if you don't use pointer.
-
To actually answer the question stated in the topic title: In case of your class
MyClass
inherits fromQObject
you are advised to work with pointers anyway as the Qt documentation states. Of course it's possible to still put it on the stack but as the documentation states you will run into problems later on. This is a design decision (or consequence) imposed by Qt and you should follow it unless you like pain. -
@micland
The wholeMyClass
belowclass MyClass { MyClass() {} ~MyClass() {} void test() { qDebug() << "This is just a test"; } }
-
@Joel-Bodenmann said:
Of course it's possible to still put it on the stack but as the documentation states you will run into problems later on.
And where does the documentation actually state that?
@Alice said:
Sure, I create a pointer to MyClass.
Do you create an object of the type? A pointer is nothing, it just contains an address from the memory. If you don't "attach" an object to it (or give it a value) then it points to some undefined location.
I get error shows The program unexpected funished and the program crash. But I declare below
Something is wrong in your code, but it's not immediately visible from the snippets you posted. Paste your code exactly as is and/or provide a stack trace.
-
@kshegunov said:
@Joel-Bodenmann said:
Of course it's possible to still put it on the stack but as the documentation states you will run into problems later on.
And where does the documentation actually state that?
For example, without a copy constructor, you can't use a subclass of QObject as the value to be stored in one of the container classes. You must store pointers.
Yes I agree with you, it doesn't say that you will run into problems. I'm sorry for being inaccurate.
And yes I agree that you can still create a container holding pointers to those objects being located on the stack. I'm sorry :p -
So ... if we create a copy contructor , we can use stack instead ?
-
@Walux
The copy constructors (and the assignment operators) of the base class (QObject
and anything that inherits from that) are declared as private. If you implement a copy constructor for your custom class that inherits fromQObject
you still can't call/use the copy constructor of the base class and therefore you can't create a "full copy" of your object. That is why it's recommended to use the Q_DISABLE_COPY macro in your own class as well. For example:class MyClass : public QObject { Q_OBJECT private: Q_DISABLE_COPY(MyClass) };
which expands to:
class MyClass : public QObject { Q_OBJECT private: MyClass(const MyClass &); MyClass &operator=(const MyClass &); };
So it just saves you some writing. It doesn't introduce or apply any magic.
-
-
@Walux said:
So ... if we create a copy contructor , we can use stack instead ?
No, you can use the stack without creating a copy constructor. And you should not add a copy constructor for
QObject
subclasses. The only special thing aboutQObject
instances is that they're non-copyable, if you keep that in mind, the allocation type is of no real consequence.By the way, you should already be using the stack in your
main()
:int main(int argc, char ** argv) { QApplication app(argc, argv); //< QApplication derives from QObject and can't be copied too return QApplication::exec(); }