Редактирование: Academic Solutions to Academic Problems

{{menu_Qt_Издания}}

by Volker Hilsheimer
<blockquote>'''The moc tool and QObject add flexibility and power to the C++language. They add, among other things, the signals and slots paradigmand QObject's memory management mechanism. Both are very powerful andsometimes we wish we could use them in template classes and inconjunction with multiple inheritance.'''
__TOC__
</blockquote>

In this article, we will look closer at why <tt>moc</tt> does not supportthese use cases and how to work around these restrictions inpractice.

<div id="connectingtotemplates"></div>
== Connecting to Templates ==
The meta-object compiler, <tt>moc</tt>, requires a class's API to becompletely defined by its definition; <tt>moc</tt> can then parse thedefinition and create a "meta-object" that stores informationabout all the properties, signals, and slots of that class.

A template class is not defined only by definition but also byinstantiation. The template class itself is just a blueprint that theC++ compiler uses to generate the actual C++ classes later on.There can be an arbitrary number of instantiations with differenttemplate parameters, and each of these instantiations would require adifferent meta-object.

While it is theoretically possible for <tt>moc</tt> to handle templates, itwould be extremely complex to implement, and would be highly impracticalto use: For each template instantiation, <tt>moc</tt> would have to generatethe appropriate meta-object code, and the generated code would have tobe included once per link unit---which becomes a nightmare to maintainonce a template class is used with the same template parameter indifferent compilation units.

Therefore, running <tt>moc</tt> on a file declaring a template class likethe one below prints a friendly error message ("Sorry, Qt does notsupport templates that contain signals, slots or <tt>Q_OBJECT</tt>"):
<code>// WON'T WORKtemplate <typename T>class ATemplateClass : public QObject{ Q_OBJECTpublic: ATemplateClass(QObject *parent = 0);public slots: void setValue(const T &amp;value);signals: void valueChanged(const T &amp;value); ...private: T myValue;};</code>
If the signals and slots don't require the template parameter to be part ofthe prototype, the workaround is to make a template class inherit a[[Qt:Документация_4.3.2/qobject  | QObject]] subclass that provides the required signals and slots:
<source lang="cpp-qt">
class AQObjectSubclass : public QObject
{
    Q_OBJECT

public:
    AQObjectSubclass(QObject *parent = 0);

public slots:
    void setValue(const QString &amp;value);

signals:
    void valueChanged(const QString &amp;value);
    ...
};

template <typename T>
class ATemplateClass : public AQObjectSubclass
{
public:
    ATemplateClass(QObject *parent = 0);

    void someOtherFunction(const T &amp;value);
    ...
};
</source> 
If signals and slots need to use the template parameters, theObserver pattern is an alternative.

<div id="theobserverpattern"></div>
== The Observer Pattern ==
The Observer pattern is a mechanism for notifying changes of state inone object to one or more other objects. In Qt programming, it isseldom used, because signals and slots fulfill that role very well.

Instead of emitting signals, an observable class calls virtual functionson a list of "observers" (or "listeners"). The observers are objectsthat implement a particular interface and respond to it. For example:
<source lang="cpp-qt">
template <typename T>
class AnObserver
{
public:
    void valueChanged(const T &amp;value) = 0;
};

template <typename T>
class ATemplateClass
{
public:
    void installObserver(AnObserver *observer)
        { myObservers.append(observer); }
    void removeObserver(AnObserver *observer)
        { myObservers.removeAll(observer); }

    void setValue(const T &amp;value) {
        if (myValue != value) {
            myValue = value;
            foreach (AnObserver *observer, myObservers)
                observer->valueChanged(myValue);
        }
    }

private:
    T myValue;
    QList<AnObserver *> myObservers;
};
</source> 
Compared to signals and slots, the Observer pattern is quiteheavyweight: It requires us to manually keep a list of observers, toprovide functions for installing and removing observers, and to iteratethrough that list whenever we want to notify the observers (theequivalent of emitting a signal). It also requires us to subclass theobserver class whenever we want to be notified of a change in theobservable class (the "subject" class).

Although Qt is mostly signal--slot based, it uses the Observerpattern for event filters. Event filters are installed by calling[[Qt:Документация_4.3.2/qobject  | QObject]]::installEventFilter(); afterwards, events are deliveredto the observers through the [[Qt:Документация_4.3.2/qobject  | QObject]]::eventFilter() virtualfunction. In this case, the observer class and the subject class bothinherit the same class ([[Qt:Документация_4.3.2/qobject  | QObject]]).

<div id="multipleinheritance"></div>
== Multiple Inheritance ==
Inheriting from multiple [[Qt:Документация_4.3.2/qobject  | QObject]] superclasses not only makes themeta-object difficult to generate, it also complicates the concept ofobject ownership. Indeed, inheriting multiple times from[[Qt:Документация_4.3.2/qobject  | QObject]] will generate a compile error when using the <tt>Q_OBJECT</tt>macro, or later on when compiling the meta-object code. All thoseerrors point at ambiguities in how to cast to [[Qt:Документация_4.3.2/qobject  | QObject]] or how touse [[Qt:Документация_4.3.2/qobject  | QObject]]'s API.

The most common usage pattern for using multiple inheritance in C++is for implementing interfaces. Interfaces are abstract classes,where each function is declared as pure virtual. These functions arethen implementated in a separate class that is usually a subclass of oneor more interface classes. This pattern enforces a strict separation ofa well-defined public API from the internal implementation details. Qt4's plugin system is based on interfaces.

For example:
<source lang="cpp-qt">
class ClipboardInterface
{
public:
    virtual void cut() = 0;
    virtual void copy() const = 0;
    virtual void paste() = 0;
};
</source> 
The class implementing the above interface can be a [[Qt:Документация_4.3.2/qobject  | QObject]]subclass, and even implement the pure virtual functions as slots:
<source lang="cpp-qt">
class CustomWidget : public QWidget,
                     public ClipboardInterface
{
    Q_OBJECT

public:
    CustomWidget(QWidget *parent = 0);

public slots:
    void cut();
    void copy() const;
    void paste();
};
</source> 
However, it would be nicer if the interface class itself were ableto declare the functions as slots---this would make implementing theinterface less error-prone and would also allow the interface tosupport introspection.

But making the interface class a [[Qt:Документация_4.3.2/qobject  | QObject]] introduces the problemof multiple inheritance from [[Qt:Документация_4.3.2/qobject  | QObject]] as soon as the interface isimplemented by a [[Qt:Документация_4.3.2/qobject  | QObject]], as would be the situation in the<tt>CustomWidget</tt> case.

To avoid the multiple inheritance, we can use a "has a" relationship:
<source lang="cpp-qt">
class CustomWidget : public QWidget,
                     public ClipboardInterface
{
    Q_OBJECT

public:
    CustomWidget(QWidget *parent = 0);

    void cut();
    void copy() const;
    void paste();

private:
    ClipboardWrapper *wrapper;
};
</source> 
The <tt>CustomWidget</tt> class "has a" <tt>ClipboardWrapper</tt> object.Here's the <tt>ClipboardWrapper</tt> class definition:
<source lang="cpp-qt">
class ClipboardWrapper : public QObject,
                         public ClipboardInterface
{
    Q_OBJECT

public:
    ClipboardWrapper(QObject *parent)
        : QObject(parent)
    {
        Q_ASSERT(parent);
        wrappedObject =
            qobject_cast<ClipboardInterface *>(parent);
        Q_ASSERT(wrappedObject);
    }

public slots:
    void cut() { wrappedObject->cut(); }
    void copy() const { wrappedObject->copy(); }
    void paste() { wrappedObject->paste(); }

private:
    ClipboardInterface *wrappedObject;
};
</source> 
Code that would usually connect to the <tt>CustomWidget</tt> object caninstead connect to the <tt>CustomWidget</tt>'s wrapper object. The wrapperobject can communicate with the wrapped object through a well-definedinterface, and changes to the interfaces will trigger compile-timeerrors that help the software developer implement the interfacescorrectly in the different places it is used.

Adding signals follows a similar pattern:
<source lang="cpp-qt">
class ClipboardEvents
{
public:
	virtual void copyAvailableChange(bool available) = 0;
	virtual void pasteAvailableChange(bool available) = 0;
};

class ClipboardWrapper : public QObject,
                         public ClipboardInterface§,
                         public ClipboardEvents
{
	Q_OBJECT

public:
	ClipboardWrapper( QObject *parent);

public slots:
	void cut() { wrappedObject->cut(); }
	void copy() const { wrappedObject->copy(); }
	void paste() { wrappedObject->paste(); }

signals:
	void copyAvailableChange(bool available);
	void pasteAvailableChange(bool available);

private:
	ClipboardInterface *wrappedObject;
};
</source> 
Since the <tt>CustomWidget</tt> class must emit the signals from its owncode, and since signals are protected functions, we must use a castto call the signals through the interface declaration (which declaredthe functions as public):
<source lang="cpp-qt">
    void CustomWidget::paste()
    {
        bool wasAvailable = isCopyAvailable();
        ...
        if (wasAvailable != isCopyAvailable())
            emit static_cast<ClipboardEvents *>(wrapper)->
                       copyAvailableChange(isCopyAvailable());
    }
</source> 
At first sight, this pattern might appear to be over-engineered, but itscales very well as soon as many classes use the sameinterface/wrapper pair, and as soon as application code can useidentical APIs for many different objects.