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