QObject "thread" reassignment

JonB

In the mess of code I have inherited to work on, I come across effectively the following (Python, but principle applies to C++):

class EprPage(QWidget):
    def something(self):
        self.worker = QObject()
        self.thread = QThread()
        self.worker.moveToThread(self.thread)
        ...
        self.thread.start()
        ....
        self.thread.quit()

This code is in a section which is not called, but I want to understand if it is "correct" as I refactor.

My question is about the choice of self.thread as the name of the attribute being used.

Before this code is executed, self.thread is QWidget.thread() (i.e. QObject.thread(), http://doc.qt.io/qt-5/qobject.html#thread), which is a method. Once self.thread = QThread() is executed it is no longer that method, it is a QThread instead, and remains like that.

The code if executed seems to actually work, but is the choice of attribute named thread here simply an unfortunate choice (aided by Python's care-free attitude to everything) by a previous programmer unaware of the existence of the already-existing method? Can and should I at least rename it to my_thread, or is there some deep significance to actually deliberately make it replace the existing thread() method?

Yours Perplexed...

sierdzio

I have no definite answer here, just an opinion: I'd vote for renaming the member to something else, like my_thread you've suggested.

JonB

@sierdzio
OK, so there is no "deep reason" why code is deliberately trying to re-assign the inherited QObject::thread() method here, just coincidence in choice of name?

sierdzio

@JonB said in QObject "thread" reassignment:

@sierdzio
OK, so there is no "deep reason" why code is deliberately trying to re-assign the inherited QObject::thread() method here, just coincidence in choice of name?

My guess is that this is a mistake, yes.

kshegunov

@JonB said in QObject "thread" reassignment:

The code if executed seems to actually work, but is the choice of attribute named thread here simply an unfortunate choice (aided by Python's care-free attitude to everything) by a previous programmer unaware of the existence of the already-existing method?

It's going to work in C++ as well. Shadowing applies here, as EprPage derives from QWidget. Example:

#include <QObject>
#include <QThread>

class MyObject : public QObject
{
public:
    QThread thread;
};

Will compile fine, and thread is going to shadow the method. Whenever this happens and access to the original method is needed, then (at least in C++) a call through the fully qualified name is warranted:

MyObject object;
object.QObject::thread();   // Calls the method

Can and should I at least rename it to my_thread, or is there some deep significance to actually deliberately make it replace the existing thread() method?

Yes, probably, at least for the sake of clarity.

JonB

@kshegunov
Hi there, scientist person! Yes, I realise about shadowing. And I could doubtless access the base class method from Python through super().thread().

However, the question remained whether the original coder had any intention of his choice of thread variable having anything at all to do with base class's thread() method. (In Python both of these are simply "attributes" of the classes.) Which originally I thought was the case. I now agree with you all and it was simply coincidence --- put there to confuse me! So I have changed the derived class's variable's name, and am much happier. Thank you.

Purely, purely OOI, would C++ allow the following (excuse the non-exact syntax, you'll get the drift):

class BaseClass:
    public virtual void thing() { ... }
    public int addrOfThing() { return (int)&this.thing; }

class DerivedClass : BaseClass
    public int thing;
    // public int addrOfDerivedThing() { return (int)&this.thing; }

If it does, I know what BaseClass b; b.addrOfThing() returns, what does DerivedClass d; d.addrOfThing() return? Normally base class will allow derived class to provide its own definition of virtual function, and will access that, I guess in this case (if even allowed) the definition of thing in derived class has nothing to do with the virtual in base, so simply won't be seen at all in base class?

kshegunov

@JonB said in QObject "thread" reassignment:

would C++ allow the following

It would, and it happens as an error when dealing with virtual functions - changing the prototype slightly means instead of overriding a function you're overloading it, that is you making a completely different function. That's why they introduced override in c++11 so when such a thing happens and you said you're overriding it'd give you a compile error.

If it does, I know what BaseClass b; b.addrOfThing() returns, what does DerivedClass d; d.addrOfThing() return?

The same thing. C++ is a "static" language, which means there's decoupling between code and data. Basically classes' function are not carried along with objects, but are sitting in the static section of the binary. The objects boil down to just regular C structs (with a vpointer field if you have virtuals). Classes' methods are little more than C functions that has a special this pointer "injected" by the compiler.

the definition of thing in derived class has nothing to do with the virtual in base, so simply won't be seen at all in base class?

Indeed, it just shadows the virtual function.