Discussion :

[VivienD]

Bonsoir,

Ça fait un certain temps que je programme en C++ avec la bibliothèque logicielle Qt. J'ai remarqué que, pour utiliser une classe de cette dernière, il fallait ajouter un #include. Par exemple, pour utiliser la classe QWidget, il faut ajouter la ligne #include <QWidget>. Par ailleurs, une autre syntaxe est possible: #include <QtGui/QWidget>; dans cette syntaxe on indique la classe demandée (QWidget) et le module auquel elle appartient (QtGui), module inclus dans une bibliothèque dynamique qui lui est propre (à savoir QtGui4.dll pour le mode release et QtGuid4.dll pour le mode debug).
Ces deux syntaxes m'interpellent et font donc de l'objet de cette discussion. En effet, je voudrais savoir si elles sont spécifiques à Qt. Si ça n'est pas le cas, j'aimerais, bien évidemment, savoir comment les utiliser dans/pour mes petites bibliothèques personnelles.

Merci d'avance pour vos lumières.

Adishatz!

[JolyLoic]

Le C++ est extrêmement rustique en ce qui concerne le lien avec d'autres bibliothèques. Ce que tu prends pour une demande d'utiliser une classe dans un module est en fait simplement une demande pour inclure un fichier texte qui se situe dans un répertoire, lequel fichier va contenir des éléments que tu pourras ensuite utiliser dans ton programme.

Que tu puisse l'inclure de deux manières différentes es probablement lié au fait que quelque part, dans tes options de compilation, sont ajoutés deux chemins, et qu'il peut donc le trouver quel que soit la manière dont tu désignes ce fichier.

[VivienD]

En gros, lors de la compilation, le compilateur traduit #include <QWidget> et #include <QtGui/QWidget> en quelque chose du genre #include "chemin/relatif/ou/absolu/du/fichier/en/tete/concerne.h". C'est ça?

[koala01]

En gros, lors de la compilation, le compilateur traduit #include <QWidget> et #include <QtGui/QWidget> en quelque chose du genre #include "chemin/relatif/ou/absolu/du/fichier/en/tete/concerne.h". C'est ça?

Oui, tout à fait...

Si, au moment de la compilation (en ligne de commande), tu regardes un tout petit peu l'instruction qui compile un fichier, tu verras, selon le compilateur, quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

g++ -IunNomDeDossier -IunAutreNomDeDossier -IunTroisiemeNomDeDossier ...

ou (pour le compilateur visual studio)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cl  /IunNomDeDossier /IunAutreNomDeDossier /IunTroisiemeNomDeDossier ...

L'option I (i majuscule ) indique au compilateur quelque chose comme

Si tu cherches un fichier d'en-tête, vas voir dans le dossier indiqué s'il ne s'y trouve pas

Quand Qt a été compilé, qmake a enregistré tous les noms de dossiers dans lesquels il était susceptible de trouver les fichiers d'en-tête pour les différents "modules", et le fait de lancer qmake ajoute automatiquement les dossiers aux options du compilateur

Ceci dit, il y a bien une concordance, chez Qt, entre les noms de dossiers, les "modules" et les bibliothèques correspondantes, mais ce n'est, au final, que le résultat de décisions de développement:

Qt contient plusieurs milliers de fichiers sources, et il était donc important de les "triés" en fonction de leur objectifs.

Ils ont donc, naturellement, divisé le projet en plusieurs "modules" qui regroupent chaque fois les fichiers poursuivant un objectif commun de manière à pouvoir déterminer "plus facilement" dans quel groupe de fichiers se trouve un problème quand il survient.

Chaque "module" est, effectivement, compilé sous la forme d'une bibliothèque séparée, essentiellement, parce que, comme je l'ai déjà indiqué, cela regroupe les objectifs communs, mais, aussi, pour éviter de se retrouver avec une seule et unique bibliothèque "pharaonique" apportant une multitude de fonctionnalités dont on n'a pas *réellement* besoin.

De cette manière, tu n'es pas obligé de te "coltiner" l'ensemble des fonctionnalités réseau ou des fonctionnalités de gestion du Xml (par exemple) si tu fais une application qui n'utilise ni l'un ni l'autre

Cette manière de travailler est une pratique courante dans les projets de moyenne à grande ampleur (aller, on va dire "au delà d'une centaine de fichiers", par exemple ) et dans les projets "collaboratifs" (où il y a plusieurs développeurs qui travaillent "de leur coté) car elle facilite le travail au quotidien en facilitant les tests (on peut tester un ensemble de fonctionnalités ayant un objectif commun sans être embêté par un autre ensemble de fonctionnalités toujours en développement, pour autant que le "module" que l'on teste ne dépende pas de celui encore en développement ) et permet, au final, de partager beaucoup plus facilement le travail dans une équipe