De QObject aux méta-objets, une plongée au cœur des fondations de Qt

Comme vous le savez déjà, Qt est orienté objet et qui dit POO (Programmation Orientée Objet) dit forcément héritage. Le principe de l'héritage est plus ou moins le même que celui d'un arbre généalogique comportant des classes, qui héritent elles-mêmes d'autres classes : nous en arrivons forcément à une classe de base située à la racine de cet arbre, que l'on appelle aussi classe mère ou classe parente. Dans le cas de Qt, il s'agit de QObject.

Cette classe a pour avantage de ne correspondre à rien de « graphique ». Cela permet à Qt de gagner en puissance car elle fournit au final nombre d'utilitaires, comme le système de méta-objets dont nous allons longuement parler dans cet article sans pour autant être exhaustif, comme dit dans l'introduction. Ces utilitaires sont pour la plupart très ciblés sur le concept d'objet. QObject a donc indéniablement plus sa place que les autres classes actuellement existantes comme pilier central du framework Qt.

QObject, même si c'est la classe mère, n'est pas la classe parente de toutes les autres : certaines d'entre elles, comme QString, n'ont pas besoin des outils qu'elle propose.

À la différence du C++, de nature plutôt statique, Qt fournit une efficacité d'exécution nécessaire à la réalisation d'une interface utilisateur, à un niveau de flexibilité relativement élevé.

Le modèle objet de Qt, axé sur QObject et sur le Moc, qui sera détaillé plus tard dans l'article, offre de nombreux avantages et utilités dont les principaux sont les suivants :

• une gestion de la communication entre les objets par le biais d'un système le plus souvent appelé mécanisme de signaux et de slots (partie IV) ;
• une hiérarchie logique aux utilités multiples entre les objets, telles que les conversions de type (partie III) ;
• un système événementiel relativement utile lors du développement d'interfaces utilisateur (Qt est parfois considéré comme événementiel) ;
• une gestion de la mémoire aisée pour les développeurs, notamment par une destruction de la totalité des objets enfants lorsque l'objet parent est détruit ;
• l'introspection et les propriétés (partie V).

La documentation insiste sur le fait que les objets de Qt doivent être considérés comme des éléments possédant une identité, non comme des valeurs. Malgré les apparences, il faut noter que le modèle objet de Qt se base comme n'importe quelle application codée en C et/ou en C++ sur le C++, ce qui explique en partie la portabilité du framework.

À titre de rappel, une conversion de type avec Qt retourne, en cas de réussite, un objet de type particulier d'un objet subissant l'opération. Par rapport aux conversions de type du C++, celles de Qt sont légèrement différentes car elles ne nécessitent pas le support RTTI (Run Time Type Information).

Dans cette sous-partie, nous allons considérer deux exemples de conversions de type assez similaires :

• qobject_cast ;
• qvariant_cast.

Quel est le but de ces deux présentations ? Tout simplement de vous montrer l'utilité de Q_OBJECT pour pouvoir aborder le concept de méta-objet sans pour autant que vous vous heurtiez à l'inconnu.

III-A-1. La conversion de type qobject_cast▲

 

Sélectionnez

A objet = qobject_cast<A>(B) ;

Cette conversion de type est un cast de pointeur qui fonctionne à travers les branches de l'héritage : elle retourne un objet de type A à partir d'un objet de type B, mais sous certaines conditions. Tout d'abord, le type A doit être un type dérivé du type B. Par exemple, le code suivant n'est pas correct :

 

Sélectionnez

QTextEdit *textEdit = new QTextEdit;
QTextBrowser *browser = qobject_cast<QTextBrowser *>(textEdit);

Dans ce cas, la conversion de type retournera 0 car la condition énoncée ci-dessus n'est pas respectée : QTextEdit n'est pas une classe dérivée de QTextBrowser, c'est l'inverse, donc une incompatibilité est présente.

Toutefois, une conversion de type est réversible, elle permet de repasser d'un type à l'autre, à condition que la conversion précédente n'ait pas retourné 0. La seule nécessité est donc qu'il y ait un rapport d'héritage entre les deux types.

 

Sélectionnez

QTextEdit *textEdit = new QTextEdit;
QObject *cast_textEdit = qobject_cast<QObject *>(textEdit);
QTextEdit *recast_textEdit = qobject_cast<QTextEdit *>(casted_textEdit);

Ce qu'il faut tout de même savoir est que qobject_cast ne fait pas de distinction entre les types personnalisés et les types inclus par défaut avec Qt (exemple : QTextEdit).

Il peut être intéressant de présenter ici la fonction QObject::inherits() qui retourne un booléen dont la valeur dépend de l'héritage d'une classe ou non.

 

Sélectionnez

QTextEdit *textEdit = new QTextEdit;
bool a = textEdit->inherits("QWidget"); // a == true
bool b = textEdit->inherits("QTextBrowser"); // b == false

La seconde condition est que la classe A soit déclarée avec la macro Q_OBJECT. Dans le cas inverse, la valeur de retour serait indéfinie, si le compilateur ne signalait pas une erreur. En effet, qobject_cast requiert les méta-informations fournies par le système de méta-objets pour fonctionner correctement.

D'un point de vue pratique, qobject_cast est très utile lors de l'utilisation de sender(). Placé dans un slot, cette fonction renvoie un QObject de l'objet ayant envoyé le signal l'appelant et la conversion de type qobject_cast permet d'en récupérer un widget du type d'un QPushButton. Nous verrons plus amplement cela dans la partie sur les signaux et les slots.

III-A-2. La conversion de type qvariant_cast▲

QVariant color = QColor(0, 0, 0, 0);
qDebug() << qvariant_cast<QColor>(color); // QColor(ARGB 0, 0, 0, 0)
qDebug() << qvariant_cast<QString>(color); // #000000
qDebug() << qvariant_cast<quint32>(color); // 0

Depuis sa création, Qt propose un mécanisme ingénieux couramment appelé système de signaux et de slots. Ce système est relativement pratique quand il est présent dans des applications graphiques car il permet la communication entre plusieurs objets. Comme la documentation recommande de parler d'eux comme des identités, non comme des valeurs, nous pouvons considérer l'exemple d'un bouton sur lequel l'utilisateur cliquerait. Si l'intérêt de la présence de ce bouton était de quitter l'application lors d'un clic dessus, l'interaction entre ce bouton et l'objet de l'application, qApp, serait d'appeler une fonction de fermeture, quit(). Dans ce cas de figure, l'objet émetteur serait le bouton et l'objet receveur serait qApp. Pour créer une interaction entre ces deux objets, il faudrait créer une connexion entre eux. Par chance, Qt fournit la méthode statique et thread-safe connect() qui permet de mettre en place ce type de connexion.

connect(émetteur, signal, receveur, slot) ;

Comme vous pouvez le constater, connect() prend quatre arguments dont nous connaissons l'émetteur et le receveur, mais il accepte aussi un cinquième, le type de connexion, dont nous ne parlerons pas dans cette partie. L'argument signal correspondrait dans l'exemple du bouton à un clic, donc au signal clicked() de QPushButton. Un signal peut être considéré comme une condition à l'appel de son slot. Quant à lui, le slot correspondrait à l'action produite lors d'une interaction entre l'émetteur et le receveur, soit ici à la fermeture de l'application, donc à l'appel de la fonction quit(). Plus simplement dit, c'est une fonction appelée lors de l'interaction.

QPushButton *bouton = new QPushButton("Quitter");
connect(bouton, SIGNAL(clicked()), qApp, SLOT(quit())) ;

Une connexion entre deux objets requiert le système de méta-objets, donc la présence de la macro Q_OBJECT dans la section privée de la classe où est faite la connexion. Toutefois, le slot quit() est un slot implémenté par défaut avec Qt et non un slot créé par l'utilisateur. Le système de méta-objets n'est donc pas nécessaire pour ce cas de figure. Sans le système de méta-objets, connecter deux objets par le biais d'un signal personnalisé et/ou un slot personnalisé n'aura aucun effet. Notez que le nombre de connexions d'un objet avec un autre n'est pas limité.

De la même manière que l'on peut connecter entre eux deux objets, il est possible de les déconnecter. Cette fois-ci, c'est la fonction disconnect() qui entre en jeu, et avec les mêmes arguments que ceux entrés dans la fonction connect().

disconnect(bouton, SIGNAL(clicked()), qApp, SLOT(quit())) ;

Comme vous pouvez le constater dans les codes présentés, il n'est pas nécessaire que l'émetteur reçoive des informations de la part du receveur et vice versa : les deux objets restent indépendants l'un de l'autre lors d'une connexion. Il est d'ailleurs possible d'émettre une communication de valeurs lors d'une connexion/déconnexion. Un exemple qui illustrerait assez bien le principe serait une connexion entre un slider et une barre de progression : quand la valeur du slider changera, la barre de progression prendra la même valeur que celle du slider :

QSlider *slider = new QSlider(Qt::Horizontal);
QProgressBar *progressBar = new QProgressBar;
connect(slider, SIGNAL(valueChanged(int)), progressBar, SLOT(setValue(int)));

Il faut garder en tête que le mécanisme de signaux et de slots est extrêmement flexible. Selon la documentation, il est possible d'émettre environ deux millions de signaux par seconde, quand ils sont connectés à un même receveur, sous un i586-500 (la 5° génération de Pentium).

Jusqu'alors, nous n'avons vu que des signaux et des slots présents par défaut avec Qt. Ces signaux, même s'ils sont utiles, ne sont pas suffisants pour combler tous les besoins des programmeurs. C'est pour cela qu'il est possible de créer et de gérer ses propres signaux et slots. Comme dit dans la sous-partie précédente, l'utilisation de signaux et/ou de slots personnalisés nécessite la présence de la macro Q_OBJECT dans la section privée de la classe où ils sont gérés.

IV-B-1. Les signaux personnalisés▲

class Label : public QLabel
{
	Q_OBJECT
	signals:
	void released();
	// Reste de la déclaration
};

void Label::mouseReleaseEvent(QMouseEvent *event)
{
	Q_UNUSED(event);
	emit released();
}

connect(this, SIGNAL(released()), qApp, SLOT(quit()));

emit released(event->pos());

connect(this, SIGNAL(released(QPoint(12, 12))), qApp, SLOT(quit())); // Incorrect

connect(this, SIGNAL(released(QPoint point)), qApp, SLOT(quit())); // Incorrect

connect(this, SIGNAL(released(QPoint)), this, SIGNAL(released()));
connect(this, SIGNAL(released()), qApp, SLOT(quit()));

IV-B-2. Et les slots personnalisés▲

public slots:
void about();

void MainWindow::about()
{
	QMessageBox::information(this, "Boîte de dialogue", "Cette boîte de dialogue "
			"correspond à une implémentation basique d'un slot personnalisé.");
}

void on_[Nom de l'objet]_[Nom du signal]([Arguments]);

void MainWindow::verif()
{
	QLineEdit *lineEdit = qobject_cast<QLineEdit *>(sender());
	if(lineEdit && QFileInfo(lineEdit->text()).exists())
	QMessageBox::information(this, "Vérification", "Le chemin est valide.");
}

Il arrive parfois qu'un développeur utilisant Qt ait besoin d'effectuer de multiples connexions sur le même slot. L'alternative à effectuer des connexions fastidieuses vers des slots ayant le même effet ou bien à passer par la méthode sender() serait de passer par QSignalMapper, qui permet assez facilement de réaliser ce type de connexions, en renvoyant en même temps un identifiant de l'émetteur, tel un QString, un int, un QWidget ou encore un QObject. Retourner un QWidget ou un QObject peut être très pratique une fois combiné avec une conversion de type telle que qobject_cast.

Pour réaliser des connexions multiples sur le même slot avec QSignalMapper, la connexion de deux signaux peut être très intéressante à mettre en œuvre. Je pense que l'heure est venue de vous montrer un court exemple d'utilisation :

MainWindow::MainWindow()
{
	setCentralWidget(new QWidget);
	QVBoxLayout *layout = new QVBoxLayout;
	centralWidget()->setLayout(layout);

	QSignalMapper *mapper = new QSignalMapper(this);
	connect(mapper, SIGNAL(mapped(int)), this, SIGNAL(textChanged(int)));
	connect(this, SIGNAL(textChanged(int)), this, SLOT(verif(int)));

	for(int i = 0; i < 10; i++)
	{
		lineEdit.append(new QLineEdit(QString::number(i + 1)));
		mapper->setMapping(lineEdit[i], i);
		connect(lineEdit[i], SIGNAL(textChanged(QString)), mapper, SLOT(map()));
		layout->addWidget(lineEdit[i]);
	}
}

void MainWindow::verif(int index)
{
	QString text = lineEdit[index]->text();
	if(QFileInfo(text).exists())
	QMessageBox::information(this, "Vérification", "Le chemin du champ "
			+ QString::number(index + 1) + " est valide.");
}

Ce code fonctionne avec trois éléments préalablement déclarés dans l'en-tête :

• le signal textChanged(int) ;
• le slot verif(int) ;
• la liste QList <QLineEdit *> lineEdit.

Dans mon code, je déclare un QSignalMapper qui permettra les multiples connexions grâce à sa capacité de constituer une interface entre plusieurs signaux et un slot possédant un seul paramètre. Grâce à la connexion présente dans la boucle for, lorsque le texte d'un des QLineEdit de la liste change, le slot map() est appelé. Le fait d'utiliser la fonction setMapping() avec comme second argument un int permet de faire en sorte que le signal mapped(int) soit émis lorsque map() est appelé. Pour finir, je connecte ensuite ce signal au slot verif(int).

Si on regarde le principe globalement, les choses se font comme sur le schéma suivant :

Dès lors, nous pouvons passer à la partie sans doute la plus importante de l'article, celle sur le système de méta-objets.

Une grande question peut se poser : pourquoi utiliser un tel système ? En réalité, la principale raison de sa présence est le besoin d'instaurer un mode de communication entre les objets, qu'ils aient ou non un lien entre eux (nous verrons d'ailleurs, dans la partie suivante, que les conséquences de la présence d'un tel système sont les critiques dont il est l'objet). D'après ce que nous avons vu et ce que nous allons voir, le système de méta-objets est nécessaire aux dispositifs suivants :

• le système de signaux et de slots ;
• les informations de type disponibles lors de l'exécution, donc l'introspection ;
• le système de propriétés.

Le fait que Qt utilise un outil additionnel, le Moc (traité à la suite) et qu'il utilise une implémentation basée sur des macros fait l'objet de critiques, car il rend toute programmation avec Qt différente d'une programmation pure C++. Il s'avère que les développeurs de Qt voyaient cette utilisation comme une nécessité pour pouvoir fournir le mécanisme de signaux et de slots ainsi que les dispositifs introspectifs, non comme un moyen de se démarquer du C++.

Toutefois, certaines personnes pensent que les templates, déjà largement utilisés dans Qt, seraient plus appropriés pour gérer cela. Dans cette page, la documentation explique en détail pourquoi l'utilisation d'outils additionnels est préférable à l'utilisation des templates.

Vous pouvez aussi retrouver un débat complet sur la question ici. Ce débat a pour base une opposition de GTK et de Qt et s'oriente progressivement vers le sujet des méta-objets, en passant et en repassant par le sujet des signaux et des slots. La principale critique émise est notamment le fait énoncé plus haut, précisant que toute programmation avec Qt est différente d'une programmation pure C++ (fait contesté : il est possible d'éviter de diverger d'une programmation pure C++). L'intérêt du Moc est remis en cause à plusieurs reprises.

Le Moc est le compilateur de méta-objets. Make se sert du Moc lorsqu'il est appelé, mais celui-ci peut aussi être appelé manuellement. Son fonctionnement est simple : il lit les fichiers sources et retrouve les déclarations de classe où la macro Q_OBJECT est utilisée. Une fois cela terminé, le Moc va générer des fichiers reconnaissables par leur nom sous la forme de moc_[Nom du fichier d'en-tête].cpp (dans le cas d'une utilisation de Q_OBJECT dans un fichier d'en-tête) ou bien sous la forme de [Nom du fichier].moc (dans le cas d'une utilisation de la macro sans fichier d'en-tête), qui contiendront le code de méta-objets, par exemple nécessaire à l'utilisation des signaux et des slots.

Voici un schéma illustrant les étapes de la compilation de deux fichiers respectivement nommés Classe.cpp et Classe.h avec un compilateur quelconque. Ce dernier fichier contient dans le cas présent, à la différence du fichier Classe.cpp, une déclaration de classe dans laquelle la macro Q_OBJECT est employée.

Bien entendu, le fichier objet de moc_Classe.cpp est lui aussi généré après l'utilisation du compilateur car ce fichier est bel et bien considéré comme un fichier source.

Ce système a beau être attrayant, il possède tout de même des points faibles. Par exemple, il ne gère pas correctement les classes templates qui se voient donc privées des signaux et des slots. La documentation détaille ici les limitations que cause le Moc.

Les propriétés constituent un dispositif multiplateforme s'avérant être le pilier de la majorité des classes de Qt utilisant le système de méta-objets. Elles prennent d'ailleurs base sur ce système. Afin d'expliquer clairement comment s'en servir, nous allons étudier un petit code contenant une classe nommée MyWidget, héritant de QWidget et ayant la macro Q_OBJECT définie dans sa section privée. Ci-dessous se trouve une première utilisation des propriétés avec la propriété « windowTitle » :

MyWidget widget;
widget.setProperty("windowTitle", "MyWidget");

Ici, nous instancions notre classe MyWidget et nous définissons la propriété windowTitle avec la valeur MyWidget. Une alternative plus commune de l'utilisation de setProperty consiste à utiliser la fonction setWindowTitle. Toutefois, utiliser cette fonction à la place de setProperty ne contourne pas l'utilisation du système de propriétés, car elle s'avère être ce qu'on appelle la fonction d'écriture WRITE de la propriété windowTitle, dont nous allons parler à la suite.

Pour paraître plus concret, les propriétés constituent un outil utilisé par les modules QtScript et QtDBus pour déterminer ce qui peut être exporté depuis l'objet au script/à l'environnement D-Bus, ainsi que par le module QtDeclarative pour déterminer ce qui sera exporté depuis une classe dans QML.

Cette courte introduction a pour objectif de vous familiariser avec les propriétés. Nous allons voir en détail comment définir une propriété (et cela en premier lieu car nécessaire à la compréhension des propriétés fournies par défaut), comment gérer les valeurs d'une propriété, l'utilité des propriétés dynamiques et d'autres éléments. Par la suite, nous verrons l'intérêt des propriétés du point de vue des méta-objets.

V-D-1. Comment définir une propriété ?▲

Q_PROPERTY(type name
		READ getFunction
		[WRITE setFunction]
		[RESET resetFunction]
		[NOTIFY notifySignal]
		[DESIGNABLE bool]
		[SCRIPTABLE bool]
		[STORED bool]
		[USER bool]
		[CONSTANT]
		[FINAL])

Q_PROPERTY(bool myProperty READ getValue WRITE setValue);

class MyWidget : public QWidget
{
	Q_OBJECT
	Q_PROPERTY(bool myProperty READ getValue WRITE setValue);

	public:
	MyWidget();
	void setValue(bool);
	bool getValue() const;

	private:
	QVariant value;
};

void MyWidget::setValue(bool v)
{
	value = QVariant(v);
}
bool MyWidget::getValue() const
{
	return qvariant_cast<bool>(value);
}

V-D-2. Changer la valeur d'une propriété▲

MyWidget widget;
widget.setProperty("myProperty", true);
widget.setValue(true);

Q_PROPERTY(bool myProperty READ getValue WRITE setValue NOTIFY valueChanged);
// ...
signals:
void valueChanged(bool);

void MyWidget::setValue(bool v)
{
	value = QVariant(v);
	emit valueChanged(v);
}

V-D-3. Les propriétés dynamiques▲

Un des grands avantages du système de méta-objets de Qt est de fournir un système d'introspection. L'introspection est la capacité d'un programme à s'examiner, à s'étudier. Pour être plus précis, il est possible de dire que le RTTI constitue en lui-même un sous-ensemble de l'introspection.

Le RTTI (soit Run Time Type Information en anglais et donc Informations de Type disponibles à l'Exécution en français) peut être considéré comme un mécanisme permettant comme son nom l'indique de déterminer le type des objets durant l'exécution. Dans le cas du C++, le RTTI est associé à l'opérateur typeid et à la classe type_info, donc au header <typeinfo>. Pour plus d'informations concernant le RTTI sur ce langage, veuillez consulter cet article.

Avec Qt, les informations de type peuvent être gérées de la même manière qu'en C++ mais bénéficient d'un support plus efficace. Ce support est basé sur les méta-objets et sur QObject, la classe de base de la quasi-totalité des classes de Qt. Il est donc principalement géré par le compilateur de méta-objets (Moc).

Dans le cas de Qt, l'introspection permet, par exemple, de connaître le nom, le type de retour, le type d'accès, etc. d'une méthode, d'un constructeur ou autre. Cet exemple n'a pas été choisi au hasard. En effet, un exemple sera fourni durant cette partie, concernant la récupération des informations des méthodes et des constructeurs d'une classe. Comment utiliser l'introspection ? Cette question est celle à laquelle il me faudra répondre dans cette partie.

Comme vous avez probablement dû le comprendre, chaque classe dérivée de QObject contenant la macro Q_OBJECT possède son propre méta-objet, soit une seule et unique instance de QMetaObject. Cette instance peut être récupérée à l'aide de la fonction metaObject() de QObject. L'instance récupérée est logiquement constante car les méta-objets ne peuvent pas subir directement de traitement intercessif, c'est-à-dire qu'on ne peut pas modifier, par exemple, le nom d'une classe par le biais de son méta-objet. Cette fonction nécessite la présence d'une instance de la classe concernée. Dans le cas où aucune instance ne serait accessible pour utiliser la fonction metaObject(), la variable staticMetaObject peut être utilisée (exemple : QDialog::staticMetaObject). Toutefois, son cas ne sera pas traité ici.

const QMetaObject *_metaObject = metaObject();

A partir d'une instance de QMetaObject, on peut utiliser un bon nombre de fonctions informatives, telles que les fonctions method(), constructorCount(), access() et bien d'autres.

QString name(_metaObject->className());
// name contient le nom de la classe dont le méta-objet est _metaObject.

Voici un fragment de code dans lequel on stocke toutes les méthodes et tous les constructeurs de la classe concernée dans un tableau, en indiquant la « signature » de la méthode, son type de retour (bool, QString, etc.), son type de fonction (signal, slot, méthode ou constructeur) et son type d'accès (privé, protégé ou public).

QTableWidget *table = new QTableWidget(this);
table->setColumnCount(3);
table->setHorizontalHeaderItem(0, new QTableWidgetItem("Type d'accès"));
table->setHorizontalHeaderItem(1, new QTableWidgetItem("Type de méthode"));
table->setHorizontalHeaderItem(2, new QTableWidgetItem("Type de fonction"));

table->setRowCount(_metaObject->methodCount() + _metaObject->constructorCount());
for(int i = 0; i < _metaObject->methodCount(); i++)
{
	table->setVerticalHeaderItem(i, new QTableWidgetItem(_metaObject->method(i).signature()));
	table->setItem(i, 2, new QTableWidgetItem(_metaObject->method(i).typeName()));

	if(_metaObject->method(i).access()	==	QMetaMethod::Private)	table->setItem(i, 0, new QTableWidgetItem("Privé"));
	if(_metaObject->method(i).access()	==	QMetaMethod::Protected)	table->setItem(i, 0, new QTableWidgetItem("Protégé"));
	if(_metaObject->method(i).access()	==	QMetaMethod::Public)	table->setItem(i, 0, new QTableWidgetItem("Public"));
	if(_metaObject->method(i).methodType()	==	QMetaMethod::Signal)	table->setItem(i, 1, new QTableWidgetItem("Signal"));
	if(_metaObject->method(i).methodType()	==	QMetaMethod::Slot)	table->setItem(i, 1, new QTableWidgetItem("Slot"));
	if(_metaObject->method(i).methodType()	==	QMetaMethod::Method)	table->setItem(i, 1, new QTableWidgetItem("Méthode"));
}
for(int tmp = _metaObject->methodCount(); tmp < _metaObject->methodCount() + _metaObject->constructorCount(); tmp++)
{
	int i = tmp - _metaObject->methodCount();
	table->setItem(tmp, 1, new QTableWidgetItem("Constructeur"));
	table->setItem(tmp, 2, new QTableWidgetItem(_metaObject->constructor(i).typeName()));

	table->setVerticalHeaderItem(tmp, new QTableWidgetItem(_metaObject->constructor(i).signature()));
	if(_metaObject->constructor(i).access() == QMetaMethod::Private)	table->setItem(tmp, 0, new QTableWidgetItem("Privé"));
	if(_metaObject->constructor(i).access() == QMetaMethod::Protected)	table->setItem(tmp, 0, new QTableWidgetItem("Protégé"));
	if(_metaObject->constructor(i).access() == QMetaMethod::Public)		table->setItem(tmp, 0, new QTableWidgetItem("Public"));
}

À l'exécution, il est possible de voir de diverses méthodes, selon la classe concernée. On constate d'ailleurs que les signaux et les slots sont aussi stockés dans le méta-objet. C'est avec ce code que l'on peut comprendre une chose : les méta-objets ne disposent que des fonctions qui leur sont fournies par le Moc. Un slot par exemple est ajouté au méta-objet, tandis qu'une méthode publique ne l'est pas sans la présence d'une macro du type de Q_INVOKABLE.

Voici un petit tableau contenant les principales macros utiles pour le recensement de méthodes par le Moc :

Il existe bien entendu d'autres macros, comme par exemple Q_SCRIPTABLE.

Les méta-objets constituent le point central de l'article et nous les avons déjà abordés théoriquement dans les parties situées avant celle-ci. La partie précédente envisage une première manière de coder avec les méta-objets dans un but introspectif, ce qui correspond à une petite partie de ce que le système de méta-objet fournit.

Notez que cette partie n'a pas pour but de recenser toutes les macros mises à disposition par le système de méta-objets. Elle présentera les différents dispositifs mis à disposition sous la forme présentation/exemple.

V-F-1. Les superclasses▲

const QMetaObject *_metaObject = metaObject()->superClass();
while(_metaObject != 0)
{
	qDebug() << _metaObject->className();
	_metaObject = _metaObject->superClass();
}

V-F-2. Fonctions d'index▲

const QMetaObject *_metaObject = metaObject();
qDebug() << _metaObject->indexOfMethod(_metaObject->normalizedSignature("myFunction(QString)"));

V-F-3. L'appel de méthodes▲

bool QMetaObject::invokeMethod(QObject *obj,
			const char *member,
			Qt::ConnectionType type,
			QGenericReturnArgument ret,
			QGenericArgument val0 = QGenericArgument(0),
			QGenericArgument val1 = QGenericArgument(),
			//...,
			QGenericArgument val9 = QGenericArgument());

const QMetaObject *_metaObject = metaObject();
qDebug() << _metaObject->invokeMethod(this, "myFunction", Qt::DirectConnection, Q_ARG(QString, "Qt is good !"));

V-F-4. La création d'instances▲

QObject* QMetaObject::newInstance(QGenericArgument val0 = QGenericArgument(0),
					QGenericArgument val1 = QGenericArgument(),
					...,
					QGenericArgument val9 = QGenericArgument()) const

const QMetaObject *_metaObject = metaObject();
MyWidget *newObject = qobject_cast<MyWidget *>(_metaObject->newInstance(Q_ARG(QObject *, this)));
if(newObject) newObject->show();

V-F-5. Les propriétés▲

const QMetaObject *_metaObject = metaObject();
for(int i = 0; i < _metaObject->propertyCount(); i++)
qDebug() << _metaObject->property(i).name();