[SOLVED] Do qt's classes own objects passed by arguments?

[T3STY]

Most classes documentation will put a note when an object passed by argument is going to be owned by the calling class. But many others don't. For example, if have the next code:
@
QWidget theWidget;
QPalette * colors = new QPalette;
// ...
myWidget.setPalette(*colors);
@
Does now "theWidget" own the "colors" instance of QPalette? Or does setPalette() create a copy of the palette passed by argument?
More in general, how does Qt behave with objects passed in arguments when not specified in the docs ?

[SGaist]

Hi,

Don't allocate your QPalette on the heap, there's no need for that. In fact if you want to play with QPalette you should do something like:

@
QPalette colors = myWidget.palette();
// modify colors
myWidget.setPalette(colors);
@

[T3STY]

The problem is that I have a class that needs to store internally a QPalette. If I don't do that I should make public some internal widgets or I should create get/set methods.

Anyway, that's not why I posted. I'm actually interested in the ownership behavior of Qt. C++'s behavior is to copy arguments; that is, anything passed in argument is copied before a function/method is called, including pointers and references. In the case of pointers and references though there is no way to predict whether a call will bind the pointed object to the calling function/method, or not. So I often find myself wondering what will happen after a call...

[norisezp]

I would also like an answer to this.

[JKSH]

When you pass by value, a new copy is created and passed to the function (this applies to all C++, not just Qt). So, the function cannot possibly take ownership of original.

It doesn't make sense to take ownership of a reference, since the original is often stack-allocated. (You must not manually destroy a stack-allocated object)

Qt methods usually take ownership of QObjects passed into them (and this is always passed by pointer), unless the documentation states otherwise.

See also: "Identity vs. Value":http://doc.qt.io/qt-5/object.html#qt-objects-identity-vs-value. In Qt, value objects are always passed by value; identity objects are always passed by pointer and the function usually takes ownership of them unless the documentation states otherwise.

[quote author="T3STY" date="1424990719"]The problem is that I have a class that needs to store internally a QPalette.[/quote]Then store a QPalette, not a QPalette*.

[T3STY]

That was an awesome explanation, thanks!

[norisezp]

So, I never want to pass a pointer to stack-allocated object? That does make sense, since the stack object only exists during execution of the current function, and will be deleted when it returns. But, this is an error that I could commit, and Qt does not detect it, right?

[T3STY]

It's C++ that does not detect the "error". Actually, to C++ it only looks like you passed a pointer to some object in memory - whether it's heap or stack it doesn't matter. Passing pointers or references to stack allocated objects is allowed, even if not desirable in most cases. Please also note that with stack allocated objects you usually pass references (&) instead of pointers (*).
However, you deciding to pass a pointer to a stack allocated object is your decision only. When accessing an object removed from stack it can cause all sorts of problems (your program could crash with no apparent reason and unexplainable error messages). But it is up to you to turn it into an error or a flawless execution.

bottom line of the story: if an object is stack allocated, try not to use any pointers to it.

[norisezp]

Thanks, I'll consider myself answered and not try to probe further if Qt catches a stack pointer or not.