Should I declare my custom class object or pointer?

[Alice]

@raven-worx
I'm sure that I just change my declaration manners.
I've test MyClass indepently and get no errors.

[raven-worx]

@Alice
what i meant was that, when you change the declaration type you also need to change every line of code which is accessing this variable (using "->" for pointer type, and "." for stack-type)

You should do a rebuild maybe?

[micland]

@Alice
I guess the crash will be caused by your implementation of MyClass. Usually both approaches should not lead to a crash but the behaviour could be different if MyClass depends on SomeWidget because the creation order of both approaches differs. But that's just guessing without knowing the internals of MyClass.
In the 2nd approach: Do you just declare the pointer or do you also create and assign an instance of MyClass anywhere (myobject = new MyClass();)?

[jsulm]

If you use a pointer do you create an instance via new MyClass();?
Can you show the MyClass constructor? Or even better the whole class?

[Alice]

@micland
Sure, I create a pointer to MyClass.
I get a crash in 1st approach without calling the function defined in MyClass, I don't know why.
@jsulm
I just do a test, there's only one function defined below,

void test()
{
    qDebug() << "This is just a test";
}

[micland]

@Alice
Can you post the implementation of the constructor of MyClass?
I think there is the problem to search. The difference between both approaches is just the order when the constructor of MyClass is called so maybe there are some dependencies that are not (yet) fullfilled in approach 1?

[Walux]

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.

[Joel Bodenmann]

To actually answer the question stated in the topic title: In case of your class MyClass inherits from QObject 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.

[Alice]

@micland
The whole MyClass below

class MyClass
{
    MyClass() {}
    ~MyClass() {}
    void test()
    {
        qDebug() << "This is just a test";
    }
}

[kshegunov]

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

[Joel Bodenmann]

@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

[Walux]

@Joel-Bodenmann

So ... if we create a copy contructor , we can use stack instead ?

[Joel Bodenmann]

@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 from QObject 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]

@Joel-Bodenmann

Amazing :o

Thanks for the infomation ;)

[kshegunov]

@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 about QObject 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();
}