| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
I have an abstract base class "DataSource". Different subclasses derived
from DataSource should import data from different external sources. Some of
the subclasses should be threaded, while others should not. The base class
DataSource itself does some Signal/Slot handling to connect to the GUI.
My problem now is that I have the following declarations:
class DataSource : public QObject{...}; // need QObject for Signal/Slot
handling
class DataSourceK2 : public DataSource, public QThread{...};
MOC won't accept this because DataSourceK2 is derived from two classes,
which in turn both are derived from QObject. It does not evem help to use
virtual inheritance in the DataSource class.
How can I circumvent this? By already deriving DataSource from QThread?
Would that be a problem for subclasses of DataSource which should not be
threaded?
--
[ signature omitted ]
Harald Grossauer wrote: >How can I circumvent this? By making sure that QObject appears only once in the inheritance tree, in a direct line, through the primary bases. Multiply-inheriting from QObject is not supported. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Hi,
I already use multiple inheritance with different QObjects - and it works,
the moc only has problems with amiguous methods of the QObject classes -
because all QObject public methods now exist twice, e.g. "property()".
To solve this you just have to reimplement these ambiguous methods
as wrappers which call the corresponding QObject methods, e.g.:
class MyClass : public MyQObject, public QThread
{
public:
QVariant property(const char *name) { return QObject::property(name); }
...
};
That's all - hope that helps.
ciao,
Chris
In my case, I get the following result:
1>MOC DataSource.h
1>DataSource.h(34): Warning: Class DataSource inherits from two QObject subclasses QThread and QObject. This is not supported!
"Christian Dähn" <daehn@xxxxxxxxxx> schrieb im Newsbeitrag news:59219.11205857560985.OPEN-XCHANGE.WebMail.tomcat@xxxxxxxxxxxxxxxxxxxxx
Hi,
I already use multiple inheritance with different QObjects - and it works,
the moc only has problems with amiguous methods of the QObject classes -
because all QObject public methods now exist twice, e.g. "property()".
To solve this you just have to reimplement these ambiguous methods
as wrappers which call the corresponding QObject methods, e.g.:
class MyClass : public MyQObject, public QThread
{
public:
QVariant property(const char *name) { return QObject::property(name); }
...
};
That's all - hope that helps.
ciao,
Chris
Hi,
since it's working for me for 2 years now, I looked deeper into the code and found
out that I'm using namespaces for my own QObject derived base classes and
the classes MyQObject and MyThread are in separate libs - maybe this is the
only way to omit moc errors.
Example:
===MyQObject.h===
namespace Tools {
/// Abstract interface class
class MyInterface {
...
};
/// Base class for objects
class MyQObject : public QObject , public MyInterface
{
Q_OBJECT
...
};
} // End of namespace
===EOF===
===MyThread.h===
namespace Tools {
class MyThread : public MyQObject, public QThread
{
Q_OBJECT
public:
...
};
} // End of namespace
===EOF===
This really works, even if this form of multiple inheritance isn't officially
supported and it's an endless controversy in discussions about design.
ciao,
Chris
"Harald Grossauer" <harald.grossauer@xxxxxxxxxx> wrote in message
news:froo1e$f4p$1@xxxxxxxxxxxxxxxx
> I have an abstract base class "DataSource". Different subclasses derived
> from DataSource should import data from different external sources. Some
> of the subclasses should be threaded, while others should not. The base
> class DataSource itself does some Signal/Slot handling to connect to the
> GUI.
> My problem now is that I have the following declarations:
>
> class DataSource : public QObject{...}; // need QObject for Signal/Slot
> handling
> class DataSourceK2 : public DataSource, public QThread{...};
>
> MOC won't accept this because DataSourceK2 is derived from two classes,
> which in turn both are derived from QObject. It does not evem help to use
> virtual inheritance in the DataSource class.
>
> How can I circumvent this? By already deriving DataSource from QThread?
> Would that be a problem for subclasses of DataSource which should not be
> threaded?
The best way is probably to use encapsulation instead of inheritance here.
Instead of making your object inherit QThread, you can make it *have* a
QThread object instead, and use that to do the work behind the scenes. A
downside is that you may need to re-implement a part of your interface in
your encapsulated QThread subclass. As you are not telling us how much code
these datasources actually share, that is hard to judge here.
In general, it is always usefull to think hard if the relation between your
classes really needs a be "is-a" relation, and can not be a "has-a" relation
instead.
André
--
[ signature omitted ]
"André Somers" <andre@xxxxxxxxxxxxxxxx> schrieb im Newsbeitrag news:froufa$6b3$1@xxxxxxxxxxxxxxxx ... > The best way is probably to use encapsulation instead of inheritance here. > Instead of making your object inherit QThread, you can make it *have* a > QThread object instead, and use that to do the work behind the scenes. A > downside is that you may need to re-implement a part of your interface in > your encapsulated QThread subclass. As you are not telling us how much > code these datasources actually share, that is hard to judge here. That could be a solution, but it would further increase the number of classes in the project, since I would have to implement several QThread derived classes (one for each DataSource derived threaded class). In the meantime I solved it by deriving already the abstract base class from QThread instead of QObject. Therefore some subclasses now have QThread functionality that I just don't use. I think (I hope!) this does not give any problems. -- [ signature omitted ]
On Tuesday 18 March 2008 16:44:46 Harald Grossauer wrote:
> I have an abstract base class "DataSource". Different subclasses derived
> from DataSource should import data from different external sources. Some of
> the subclasses should be threaded, while others should not. The base class
> DataSource itself does some Signal/Slot handling to connect to the GUI.
> My problem now is that I have the following declarations:
>
> class DataSource : public QObject{...}; // need QObject for Signal/Slot
> handling
> class DataSourceK2 : public DataSource, public QThread{...};
>
> MOC won't accept this because DataSourceK2 is derived from two classes,
> which in turn both are derived from QObject. It does not evem help to use
> virtual inheritance in the DataSource class.
>
> How can I circumvent this? By already deriving DataSource from QThread?
> Would that be a problem for subclasses of DataSource which should not be
> threaded?
>
In older Qt version (3.x) I've encountered a similar problem with inheritance
where I had:
class A: public B, public QLineEdit {...}
which gave me problems with moc in the end, but that could be solved by
changing the order of inhereritance to inherit from QObject first:
class A: public QLineEdit, public B {...}
It's worth a shot.
Happy coding,
Eric
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
"Eric Methorst" <arnalon@xxxxxxxxx> schrieb im Newsbeitrag
news:200803182351.24557.arnalon@xxxxxxxxxxxx
...
> In older Qt version (3.x) I've encountered a similar problem with
> inheritance
> where I had:
> class A: public B, public QLineEdit {...}
> which gave me problems with moc in the end, but that could be solved by
> changing the order of inhereritance to inherit from QObject first:
> class A: public QLineEdit, public B {...}
Tried that, but didn't make any difference :-(
--
[ signature omitted ]
On Tuesday 18 March 2008 16:44:46 Harald Grossauer wrote:
> I have an abstract base class "DataSource". Different subclasses derived
> from DataSource should import data from different external sources. Some of
> the subclasses should be threaded, while others should not. The base class
> DataSource itself does some Signal/Slot handling to connect to the GUI.
> My problem now is that I have the following declarations:
>
> class DataSource : public QObject{...}; // need QObject for Signal/Slot
> handling
> class DataSourceK2 : public DataSource, public QThread{...};
>
> MOC won't accept this because DataSourceK2 is derived from two classes,
> which in turn both are derived from QObject. It does not evem help to use
> virtual inheritance in the DataSource class.
>
> How can I circumvent this? By already deriving DataSource from QThread?
> Would that be a problem for subclasses of DataSource which should not be
> threaded?
>
PS: I wasn't using multiple inheritance, so that might still not apply to you.
Happy coding,
Eric
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]