C++ est le langage le plus populaire et il sera utilisé encore longtemps dans le futur malgré l'apparition de Java. C++ s'exécute extrêmement vite et est en fait 10 à 20 fois plus RAPIDE que Java. Java s'exécute très lentement car il s'agit d'un langage avec interprétation de Byte-code fonctionnant sur une machine virtuelle. Java s'exécute plus rapidement avec un compilateur à la volée (JIT - Just In Time) mais reste malgré tout plus lent que le C++. Et les programmes en C++ optimisés sont environ 3 à 4 fois plus rapides que Java avec un compilateur à la volée ! La gestion de la mémoire en Java est automatique, donc les programmeurs n'ont pas à gérer directement les allocations de mémoire. Ce document tente d'automatiser la gestion de la mémoire en C++ pour la rendre plus facile à utiliser.
Les allocations de mémoire gérées automatiquement sont une fonctionnalité conviviale de Java. Ce document permettra au C++ d'égaler Java pour la facilité de la gestion de la mémoire.
En raison des allocations de mémoire manuelles, déboguer des programmes C++ prend une grande partie du temps de développement. Les informations de ce document vous donneront de bons trucs et astuces pour réduire le temps de débogage.
Puisque C++ est une surcouche de C, il comporte tous les défauts du C.
Par exemple, dans la programmation C, les fuites de mémoire et les débordements sont très courants en raison de l'utilisation des fonctionnalités telles que
char *
char[]
strcpy, strcat, strncpy, strncat,
malloc, realloc, strdup,
L'utilisation de char * et strcpy crée d'affreux problèmes dûs au débordement (overflow), aux accès hors limites (fence past errors), aux "je vous écrase les orteils" (altération des emplacements en mémoire d'autres variables) ou aux fuites de mémoire. Les problèmes de mémoire sont extrêmement difficiles à déboguer et très longs à corriger et à éliminer. Ils diminuent la productivité des programmeurs. Ce document aide à augmenter cette productivité grâce à différentes méthodes destinées à résoudre les défauts de la gestion de la mémoire en C++. Les bogues liés à la mémoire sont très durs à éliminer, et même les programmeurs expérimentés y passent plusieurs jours, semaines ou mois pour les déboguer. La plupart du temps, les bogues de mémoire restent "tapis" dans le code durant plusieurs mois et peuvent causer des plantages inattendus ! L'utilisation de char * en C++ coûte aux États-Unis et au Japon 2 milliards de dollars chaque année en temps perdu en débogage et en arrêt des programmes. Si vous utilisez char * en C++, cela est très coûteux, en particulier si vos programmes font plus de 50.000 lignes de code.
Par conséquent, les techniques suivantes sont proposées pour pallier les défauts du C.
Il est proposé que les compilateurs C++ devraient empêcher les programmeurs d'utiliser les types "char *" et "char[]" et les fonctions comme strcpy, strcat, strncpy, strncat. Ces types et ces fonctions sont dangereux et doivent être complètement BANNIS de la programmation en C++ ! "char *" est comme le virus de la variole et doit être éliminé de l'univers C++ ! Si vous voulez utiliser "char *", notamment avec certaines fonctions système, vous devriez utiliser le langage C. Vous mettrez alors vos programmes C dans un fichier séparé et les lierez aux programmes C++ en utilisant la directive de spécification de lienextern "C" :
extern "C" {
#include <stdlib.h> }
extern "C" {
une_fonction_c();
une_autre_fonction_c();
}
une_fonction_c()
et une_autre_fonction_c() sont compilés par un compilateur C).Au lieu d'utiliser char * et char[], tous les programmeurs C++ DOIVENT utiliser la classe String qui est fournie dans ce document et la classe string inclue dans la bibliothèque standard (STDLIB). La classe String utilise un constructeur et un destructeur pour automatiser la gestion de la mémoire et aussi fournir de nombreuses fonctions comme ltrim, substring, etc.
Voir aussi la classe string du compilateur C++. La classe
string fait partie de la bibliothèque standard GNU C++ et fournit un grand
nombre de fonctions de manipulation. Les classes string et
String peuvent supprimer le besoin du type char *.
Les programmeurs C++ doivent aussi être encouragés à utiliser les opérateurs
new et delete plutôt que malloc et free.
La classe String fait tout ce que char * et char [] font. Elle peut complètement remplacer le type char. Il faut en plus ajouter comme avantage que les programmeurs n'auront pas du tout à s'occuper des problèmes liés à la mémoire et à son allocation !
Le compilateur GNU C++ DOIT abandonner le support des types char * et char[] et pour permettre la compilation de vieux programmes utilisant le type char, il devrait fournir une nouvelle option appelée "-fchar-datatype" pour la commande g++. Dans les deux années qui viennent, tous les programmes C++ utiliseront les classes String et string et il n'y aura plus ni char * ni char[]. Le compilateur devrait empêcher les mauvaises habitudes de programmation !
Il vous est recommandé de programmer en C++ orienté objet pour toute votre
programmation généraliste ou d'applications. Vous pouvez bénéficier de tous
les avantages des fonctionnalités orientées-objet du C++. Le compilateur C++ est
beaucoup plus complexe que le compilateur C et les programmes en C++ peuvent
s'exécuter un peu plus lentement que les programmes en C. Mais la différence de
vitesse entre le C et le C++ est faible (cela peut être quelques
millisecondes qui peuvent avoir un faible impact pour la programmation
temps-réel). Depuis que le matériel informatique est devenu moins cher et plus
rapide et la mémoire plus rapide et moins chère, il vaut mieux coder en C++
car le temps gagné grâce à la clarté et la réutilisabilité du code C++ compense la
lenteur d'exécution.
Les options d'optimisation comme -O ou -O3 peuvent accélèrer
le C++/C, ce qui n'est pas possible en Java.
De nos jours, le langage C est principalement utilisé pour la programmation système pour développer les systèmes d'exploitation, les pilotes de périphériques, etc.
Note : En utilisant les classes String, StringBuffer, StringTokenizer et StringReader données dans ce Howto, vous pouvez coder un C++ qui ressemble "exactement" à Java ! Ce document essaie de combler le fossé entre C++ et Java, en imitant les classes Java en C++
Java est un langage indépendant de la plateforme mieux adapté au développement d'interfaces graphiques fonctionnant dans des butineurs (Java applets, appliquettes Java) mais qui s'exécute très lentement (NdT : Java ne se limite pas aux appliquettes). Préférez l'utilisation de la programmation "Fast-CGI" en C++ du côté serveur et HTML, DHTML, XML pour obtenir de meilleures performances. À partir de là, la règle d'or est "la programmation côté serveur en C++ et la programmation côté client (butineur) avec des appliquettes Java". La raison est que le système d'exploitation du côté serveur (Linux) est sous votre contrôle et ne change jamais, et que vous ne saurez jamais quel est celui du côté client/butineur. Cela peut être un terminal Internet (Linux embarqué + Netscape) ou un ordinateur avec Windows 95/98/NT/2000 ou Linux, Mac Os, OS/2, Netware, Solaris, etc.
Le gros avantage de Java est la possibilité d'exécuter des appliquettes graphiques qui fonctionnent sur n'importe quelle plateforme cliente (NdT : des applications graphiques aussi) ! Java a été créé pour remplacer les interfaces de programmation d'applications (API) de Microsoft Windows 95/NT comme MS Visual Basic ou MS Visual C++. NdT : Java a plutôt été créé pour servir de "colle universelle capable de connecter les utilisateurs aux informations" (extrait de "Au Coeur de Java" par Cay S. Horstmann et Gary Cornell). En d'autres termes, "Java est le système de fenêtrage du prochain siècle". Beaucoup de butineurs comme Netscape supportent les appliquettes et le butineur HotJava est écrit en Java. Mais le prix que vous payez pour la portabilité multi-plateformes est la baisse de performance. Les applications écrites en Java sont très lentes.
NdT : l'opposition C++/Java me semble ici réductrice. De nombreux langages de script sont utilisables et utilisés du côté serveur (Perl, Python, PHP), ainsi que les servlets et maintenant les JSP.