Discussion :

[lirycs78]

Voila, j'ai une question simple, mais je n'arrive pas a y r�pondre.
Voulant d�buter sur de bonne base, j'aurais quelques questions.
Quand on d�veloppe par exemple avec la lib Qt qui est �norme, peut on dire que l'on d�veloppe en C++ ?
Car si je regarde bien, j'ai l'impression que de base le C++ est pauvre avec c'est lib d'origine. On est obliger parfois de repasser par le C.
Autre question, mais qui pourrait contredire la premi�re, la lib Qt par exemple est �norme et elle ce base je crois sur le C++ alors comment sa ce fait que Qt soit tr�s complet et que le C++ en lui m�me parait pauvre ?
J'esp�re en avoir vexer aucun :/

Merci.

[camboui]

Allez, je vais faire une sorte d'analogie.
Le fran�ais est une langue avec une syntaxte, une grammaire, et un vocabulaire assez complets.
Mais tu ne trouveras dans aucun becherelle ni aucun dictionnaire l'int�grale de Descartes ou de Balzac.

[LittleWhite]

Autre question, mais qui pourrait contredire la premi�re, la lib Qt par exemple est �norme et elle ce base je crois sur le C++ alors comment sa ce fait que Qt soit tr�s complet et que le C++ en lui m�me parait pauvre ?
Merci.

Je ferai une autre analogie
C++ c'est comme des pi�ces de l�go, on a quelque chose, basique, et il n'y a plus qu'a construire ( l'application ).
Qt, c'est comme si on vous offrais un set de l�go avec la maison, la voiture et tout plein de choses de d�j� assembl�. Vous pouvez utiliser votre maison + voiture, mais vous pouvez aussi ajouter de nouvelles pi�ces, pour l'am�liorer ou pour que cela corresponde � vos d�sirs ( pouvoir du C++ avec h�ritage et tout autre petite folie ).

[koala01]

Salut, et bienvenue sur le forum.

Peut �tre devrions nous d�j� nous mettre d'accord sur la signification � donner �

<snip> On est obliger parfois de repasser par le C.

et de ce qui t'en donne l'impression...

Est-ce � cause de la pr�sence de fonctions libres, de la pr�sence de fonctions r�ellement issues du C, ou, pourquoi pas, � cause du recours aux instructions pr�processeur

Et je vais donc me permettre une r�ponse en quatre point (qui pourra sans doute de nouveau "entrer dans la l�gende" du fait de sa longueur, et qui permettra � certains de me chambrer un peu plus ) pour te faire comprendre.

Pour ce qui concerne la pr�sence �ventuelle de fonctions libres, il faut se rappeler que C++ est un langage dit "multi-paradigme", parce que, contrairement � d'autres (tels que Java ou C#) il autorise, certe, une approche orient�e objet, mais �galement une approche purement proc�durale ou encore une approche g�n�rique.

Or, la POO a, d'une certaine mani�re, �t� longtemps consid�r�e comme la solution ultime � tous les probl�mes, et, si l'on est tout � fait d'accord sur les bienfait qu'elle apporte par rapport au paradigme proc�dural "pur et dur", il faut malgr� tout avouer que, dans certaines circonstances, elle rend malgr� tout certaine choses bien plus compliqu�es que si elles avaient �t� envisag�e d'un point de vue simplement proc�dural.

Ce n'est donc pas parce que l'on a recours � une fonction libre par ci par l� que l'on ne code *forc�ment* pas en C++

Si ton impression est bas�e sur l'utilisation de possibilit�s issues du C, il faut te dire que C et C++ partagent une base commune (une bonne partie de C sert de base � C++).

Il n'est donc pas forc�ment faux d'utiliser cette base commune dans un programme C++, m�me si on peut objecter l'existence de solutions plus s�curisantes ou plus simples � l'emploi.

Un tel m�lange est, d'ailleurs, souvent remarqu� pour des raisons historiques dans des codes de productions "assez anciens".

Le fait est alors que le risque que l'on prendrait � vouloir changer ce code afin de ne plus utiliser que les �quivalents C++ (en terme de r�gression, par exemple) soit trop important par rapport aux avantages r�els, et qu'il vaut souvent la peine d'�valuer tr�s attentivement le rapport entre le risque encouru et l'int�r�t potentiel esp�r�.

Si, tu fait r�f�rence � la pr�sence de directives pr�processeurs, il faut, l� aussi, comprendre que, non seulement, cela fait partie du langage, mais que leur utilisation est souvent le seul moyen de r�soudre certains probl�mes (par exemple, le moyen de r�soudre les probl�mes de d�finition multiple, en ce qui concerne les gardes anti inclusions multiples), mais que c'est aussi le meilleur moyen possible afin d'assurer une compatibilit� maximale avec les diff�rents compilateurs.

En effet, s'il y a beaucoup de chances pour que deux compilateurs issus de fournisseurs diff�rents datant d'une m�me �poque soient bas�s sur la m�me norme, il n'est malheureusement pas rare de constater des aspects "non support�es" de la norme diff�rents, voire, des interpr�tations diff�rentes de la norme d'un compilateur � l'autre.

Le fait qu'il existe � nouveau deux architectures diff�rentes au niveau des PC (car il existe encore des PC �quip�s en 32 bits ) et les diff�rences de tailles de certains types que l'on observe (la taille n�cessaire pour repr�senter les pointeur, par exemple) rendent, encore une fois, le recours � des directives pr�processeur quasi indispensable si tu souhaite pouvoir �crire quelque chose de compatible avec "un maximum de compilateurs et de plateformes".

Enfin, et c'est sans doute le point le plus important de ma r�ponse, il faut te rappeler que toute biblioth�que "un peu ancienne" (comprend: dont le d�veloppement originel a �t� entrepris il y a quelques ann�es) est fondamentalement li�e � son historique, et aux circonstances en vigueur au moment du lancement de son d�veloppement.

Le d�veloppement Qt par exemple, a �t� lanc�, si mes souvenirs sont bons, il y a plus de dix ans.

Depuis, C++ a vu arriver au minimum une norme compl�te et un Technical Report, et nous attendons (avec impatience ) la finalisation d'une nouvelle norme.

Comme il y a souvent un d�calage entre la sortie d'une norme et le moment o� un compilateur donn� va officiellement la supporter de mani�re stable et d�finitive, on peut tr�s facilement comprendre que toute biblioth�que dont le d�veloppement d�bute avant cette "date b�nie entre toutes" prenne les manques et les restrictions du (des) compilateur(s) cible(s) du d�but du d�veloppement en compte.

Si donc, au d�but du d�veloppement d'une biblioth�que, il se faisait que l'impl�mentation des collections (vector, list et autre (multi-)map) par le compilateur utilis� n'�tait pas parfait (si tant est d�j� que la norme existe), mais que la biblioth�que souhaitait fournir un support similaire � ce que la norme pr�voyait, elle n'avait pas �norm�ment d'autre choix que... d'en fournir sa propre impl�mentation (bas�e sur ce que la norme conseille)

Et on ne prend m�me pas encore en compte le fait que la biblioth�que puisse avoir d�cid� de rajouter une ou l'autre possibilit� � ses propres collections

Si j'ai d�cid� de pr�ciser tout cela, c'est pour arriver � te faire comprendre que, si tu es habitu� aux QString, QList et autres QMachinChose parce que tu travailles principalement avec Qt, ce n'est pas *forc�ment* parce qu'il n'existe pas d'�quivalent dans le C++ "de base", mais, simplement, parce que "tant qu'� faire" Qt pr�f�re... utiliser ses propres types.

Pour se faire une id�e r�elle de ce que repr�sente r�ellement C++, l'id�al est pour ainsi dire de travailler un certain temps sans utiliser de biblioth�que tierce, m�me si cela sous entend souvent cr�er une application fonctionnant en mode console.

Cela te permettra de te rendre compte de l'�norme potentiel de C++ et du fait qu'il s'agit d'un langage beaucoup plus imposant que tu pourrait le croire de prime abord (en plus, l'utilisation importante des template dans C++ fait qu'il n'est pas impossible que certaines de ses fonctionnalit�s soient r�ellement compatibles avec les types propres de Qt).

Enfin, comme camboui l'a fait remarquer, il faut comprendre que C++ fournit "les briques de base", qu'il t'appartient d'assembler "comme bon te semble" en fonction de tes besoins