Il s'agit sûrement de la question la plus posée et
pour laquelle la réponse est sujette à une controverse interminable.
Il n'est pas nécessaire ni obligatoire de connaître le C pour faire du C++. Il est tout à fait possible et raisonnable
d'apprendre le C++ directement.
La connaissance du C peut être une aide (syntaxe semblable). Par contre, cela peut donner lieu à l'utilisation d'habitudes
qui sont mauvaises en C++ (par exemple, utilisation excessive des pointeurs, alors que les références permettent le même comportement).
Oui, C++ est un langage pratique.
Dans le monde de l'industrie logicielle, C++ est vu comme un outil solide, mature et sans surprises.
Il est largement utilisé et supporté par l'industrie, ce qui le valorise d'un point de vue productif en général.
Le C++ n'a pas été créé pour démontrer à quoi ressemblait un langage Orienté Objet pafait. Il a été conçu pour être un outil pratique,
pour répondre à des problèmes pratiques.
Il présente quelques défauts, mais les seuls endroits où il serait judicieux d'apporter des modifications, pour atteindre la perfection,
n'auraient qu'un but purement académique, ce qui n'est pas le but du C++.
Les techniques OO sont la meilleure façon connue de développer de grosses applications ou des systèmes complexes.
L'industrie du logiciel n'arrive pas à satisfaire les demandes pour des systèmes logiciels aussi imposants que complexes, mais cet échec
est dû à nos succès : nos réussites ont habitué les utilisateurs à toujours en demander plus. Malheureusement, nous avons ainsi créé
une demande du marché que les techniques 'classiques' de programmation ne pouvaient satisfaire. Cela nous a obligé à créer un meilleur
paradigme.
le C++ permet de programmer OO, mais il peut aussi être utilisé comme un langage classique ("un C amélioré"). Si vous comptez
l'utiliser de cette façon, n'espérez pas profiter des bénéfices apportés par la programmation OO.
Il s'agit sûrement de la question qui genère le plus de bruit par rapport à l'information utile qui en ressort. Veuillez lire ce qui
suit avant de vous lancer dans ce genre de débat.
Dans 99% des cas, le choix d'un langage de programmation est fait en fonction de considérations financières ou commerciales, mais pas
en fonction des considérations techniques.
Les choses réellement importantes qui pèsent lors de la décision sont la présence d'un environnement de développement, la possibilité de
faire fonctionner le logiciel sur la machine cible, les licences, la disponibilité de développeurs expérimentés, de consultants,
sans oublier la "culture de l'entreprise".
Ces considératons financières et commerciales jouent souvent un rôle plus important que la vitesse de compilation, la vitesse d'exécution,
le typage dynamique ou le typage statique, etc ....
Quiconque argumente en faveur d'un langage par rapport à un autre de façon purement technique (c'est-à-dire en ignorant les éléments commerciaux)
s'expose à être traité de 'technicien extrémiste' et à ne pas être écouté.
Le nombre important de développeurs (et par conséquent le grand nombre d'infrastructures de support, y compris vendeurs, outils, cours, ....)
est une des caractéristiques importantes du C++.
Des sociétés arrivent à prodiguer des cours intensifs, où un semestre de cours de niveau universitaire est compressé en une semaine de 40 heures.
Mais, indépendemment du lieu où vous suivrez vos cours, assurez-vous que les cours ont des séances 'pratiques', étant donné que la plupart
des gens apprennent mieux en ayant des projets sur lesquels travailler et faire des essais. Mais même avec la meilleure formation, ils ne
sont pas encore prêts.
Cela prend de 6 à 12 mois pour devenir productif en technique OO / C++, moins si les développeurs ont accès facilement à un groupe local
d'experts, plus si il n'y a pas de
bonne librairie des classes à usage général de disponible.
Devenir un de ces experts capable de guider les autres prend à peu près 3 ans.
Certaines personnes n'y arrivent jamais. Vous n'avez aucune chance à moins que vous n'acceptiez que l'on vous apprenne et que vous soyez
motivé. Un minimum de receptivité
signifie que vous devez être capable de reconnaître quand vous vous êtes trompé. Un minimum de motivation
signifie que vous devez être disposé à investir quelques heures supplémentaires (Il est nettement plus facile d'apprendre quelques nouveautés
que de modifier votre paradigme [par ex., de changer votre façon de penser, la notion du bien, etc....])
Il y a 2 choses que vous devriez faire :
trouver un mentor, un guide
fournir 2 livres à vos elèves
: un pour leur expliquer ce qui est légal, l'autre pour ce qui est moral.
et 2 que vous ne devriez pas faire
considérer le C comme un passage obligé pour apprendre le C++
considérer SmallTalk comme un passage obligé pour apprendre le C++
Le C++ bénéficie d'une large base installée, ce qui veut dire qu'il y a un support de plusieurs vendeurs pour les outils,
environnements, services de consultance, ...
Le C++ permet aux développeurs de fournir des interfaces simplifiées, ce qui réduit la quantité de défauts rencontrés
lorsqu'elles sont réutilisées.
Le C++ permet d'exploiter l'intuition des développeurs grâce à l'utilisation de la surcharge d'opérateur, ce qui permet de réduire
la courbe d'apprentissage pour les utilisateurs.
Le C++ permet de "localiser l'accès" à une partie du logiciel, ce qui réduit la charge de travail causée par les changements.
Le C++ permet de réduire le compromis fiabilité / utilisabilité, donc le coût d'utilisation ou de réutilisation du logiciel.
Le C++ permet de réduire le
compromis fiabilité / vitesse, donc d'améliorer la qualité sans dégradation des performances.
Le C++ offre les techniques d'héritage et d'appel dynamique, ce qui permet d'appeler du nouveau code à partir de code plus ancien,
permettant donc d'ajouter de nouvelles fonctionnalités ou d'adapter vos programmes à la demande du marché.
Sans les fonctions virtuelles, le C++ ne serait pas un langage orienté objet. La surchage d'opérateur et les fonctions membres non virtuelles
sont très pratiques, mais ne sont, finalement qu'une variante syntaxique de la notion beaucoup plus classique de passage de pointeur sur une
strucutre à une fonction. La librairie standard contient de nombreux templates illustrant les techniques de "programmation générique", qui
sont aussi très pratiques, mais les
fonctions virtuelles sont le coeur même de la programmation orientée objet.
D'un point de vue 'business', il y a très peu de raison de passer du C pur au C++ sans les fonctions virtuelles (pour le moment, nous
ferons abstraction de la programmation générique et de la librairie standard). Les spécialistes pensent souvent qu'il a une grande différence
entre le C et le C++ non orienté objet ; mais sans l'orientation objet, la différence n'est pas suffisante pour justifier le coût de
formation des développeurs, des nouveaux outils, ....
En d'autres termes, si je devais conseiller un gestionnaire concernant le passage du
C au C++ sans orientation objet (c'est-à-dire changer le langage sans changer de paradigme), je le découragerais probablement, à moins
qu'il y ait des contraintes liées aux outils utilisés. D'un point de vue gestion, la programmation orientée objet permet de concevoir
des systèmes extensibles et adaptables, mais la syntaxe seule sans l'orientation objet ne réduira jamais le coût de maintenance, mais
augmentera probablement les coûts de formation de façon significative.
Nota : le C++ sans virtualité n'est pas orienté objet. Programmer avec des classes mais sans liaison dynamique est une programmation
basée sur des objects, mais n'est pas de la programmation objet. Ignorer la virtualité est équivalent à ignorer l'orientation object.
Tout ce qui reste est une programmation basée sur des objets, tout comme la version originale d'ADA. (Soit dit en passant, le nouvel ADA
supporte la véritable orientation objet, et non plus simplement la programmation basée sur les objets).
L'appel dynamique permet d'augmenter la réutilisabilité en autorisant le 'vieux' code à appeler du nouveau code.
Avant l'apparition de l'orientation objet, la réutilisation du code se faisait en appelant du vieux code à partir du nouveau code.
Par exemple, un programmeur peur
écrire du code appelant du code réutilisable comme printf(), ....
Avec l'orientation objet, la réutilisation peut aussi être accomplie via l'appel de nouveau code par de l'ancien.
Par exemple, un programmeur peut écrire du code qui est appelé par un framework qui a été écrit par son arrière grand-père. Il n'y a pas
besoin de modifier le code écrit par l'arrière
grand-père. En fait, il n'a même pas besoin d'être recompilé. Et si jamais il ne restait que
le fichier objet, et que le code écrit par l'arrière grand-père ait été perdu depuis 25 ans, cet ancien fichier objet appelera le code avec
les nouvelles fonctionnalités sans rien changer d'autre.
C'est cela l'extensibilité, et c'est cela l'orientation objet.
ne prend pas de paramètres, alors qu'en C, on peut passer un nombre arbitraire de paramètres.
Il y a d'autres différences parfois très subtiles. Par exemple
sizeof('x')
vaut
sizeof(char)
en C++, alors qu'en C, cela vaut
sizeof(int)
Un autre exemple est celui des étiquettes de structures qui sont stockées dans le même namespace que les
autres identificateurs. Là où le C exige la déclaration explicite d'une structure, cela devient redondant
en C++. Par exemple, l'écriture suivante est valide en C++ mais est redondante, alors qu'elle est
obligatoire en C.
Le standard du C++ a été finalisé et adopté par l'ISO (International Organization for Standardization) et
par d'autres organismes de normalisation tels que l'ANSI (The American National Standards Institute), le
BSI (The British Standards Institute), le DIN (The German National Standards Organization).
L'adoption du standard s'est faite à l'unanimité le 14 novembre 1997.
Le comité ANSI C++ est appelé "X3J16". Le groupe de travail de l'ISO se nomme "WG21". Le processus de normalisation implique un grand nombre d'acteurs : des représentants de l'Australie,
du Canada, du Danemark, de la France, de l'Allemangne, de l'Irelande, du Japon, de la Hollande, de la
Nouvelle-Zélande, de la Suède, du Royaume-Uni, et des Etats-Unis ainsi que des représentants d'une centaine
de sociétés, ansi que de nombreux particuliers impliqués. Les acteurs majeurs incluent AT&T, Ericsson,
Digital, Borland, Hewlett Packard, IBM, Mentor Graphics, Microsoft, Silicon Graphics, Sun Microsystems et Siemens.
Après 8 ans de travaux, le standard est maintenant finalisé. Le standard à été approuvé par un vote à
l'unanimité des représentants présents à Morristown le 14 novembre 1997.
Note : le document fourni par l'ISO est plus de 10 fois plus onéreux que celui de l'ANSI, alors que le contenu technique est identique.
La page de garde est différente, mais le contenu technique est identique. Ne me demandez pas pourquoi l'ISO demande aussi cher par rapport
aux autres pour la même chose ; c'est
la technique commerciale de l'ISO ; si malgré tout vous voulez poser la question, faites-le à leur
service commercial.
Il y a au moins 2 façons d'obtenir une copie papier du document :
Prix non connu (publié par
l'ANSI) : appelez le NCITS (National Committee for Information
Technology Standards ; c'est le nouveau
nom du commité autrefois connu sour le nom de "X3"). La personne de contact est Monica Vega, 202-626-5739 ou 202-626-5738.
Demandez le document FDC 14882. Soyez prêt à dépenser un peu d'argent, il n'est sûrement pas gratuit.
Il y a 2 autres moyens d'obtenir (gratuitement) un document intéressant à consulter :
Cette question se destine tout d'abord aux responsables non-techniques et au personnel des ressources humaines qui essaient de faire un
travail de bonne qualité quand ils interviewent des candidats développeurs C++. Si vous êtes un programmeur C++ sur le point d'être
interviewé, et que vous consultez cette FAQ en espérant savoir à l'avance quelles questions vont vous être posées de façon à ne pas devoir
apprendre réellement le C++, honte à vous. Prenez le temps de devenir un développeur compétent et vous n'aurez pas besoin d'essayer de
tricher.
Pour revenir aux non-techniciens et au personnel des ressources humaines : il est évident que vous êtes parfaitement qualifiés pour juger
si un candidat a un profil correspondant à la culture de votre entreprise. Cependant, il y a assez de charlatans, de menteurs et de frimeurs
pour que vous ayez besoin de faire équipe avec quelqu'un qui est techniquement compétent pour s'assurer que le candidat a le niveau
technique adéquat. Assez de sociétés ont souffert d'avoir engagé des gens sympathiques mais incompétents, des gens globalement
incompétents malgré le fait qu'ils connaissent les réponses à quelques questions très pointues. La seule façon de démasquer les menteurs
et les frimeurs est d'avoir à vos cotés une personne capable de poser des questions techniques pointues. Il n'y a aucun espoir que vous y
arriviez par vous-même. Même si je vous donnais une série de questions pièges, elles ne vous permettraient pas de démasquer ces personnes.
Votre partenaire technique n'a pas
besoin d'être qualifié (et bien souvent, elle ne l'est pas) pour juger la personnalité du candidat,
donc, par pitié, n'oubliez pas que
vous êtes le seul juge au final. Mais ne pensez pas que vous pouvez
poser une demi-douzaine de question sur
le C++ et avoir la moindre chance de savoir si le candidat sait de quoi il parle, du moins d'un point de vue technique.
Par contre, si vous avez un niveau techique suffisant pour lire cette FAQ, vous pouvez y piocher quantité de bonnes questions pour une
interview. La FAQ contient bon nombre de choses permettant de séparer le bon grain de l'ivraie. La FAQ se concentre sur ce que les
programmeurs doivent faire, plutôt que
d'essayer de voir ce que le compilateur leur laisse faire. Il y a des choses en C++ qu'il est possible
de faire mais qu'il vaut mieux éviter. La FAQ sert à faire le tri là-dedans.
Cela signifie que c'est quelque chose que vous devez éviter la plupart du temps, mais pas tout le temps. Par exemple, vous finirez par
utiliser la solution "mauvaise" quand elle est la moins mauvaise solution possible. C'est de l'humour. Ne le prenez pas
au premier degré.
La véritable raison de l'utilisation de ce terme
(je vous entend dire : "il y a un motif réel caché derrière cela". Et bien c'est tout à fait le cas)
est de pousser les nouveaux programmeurs C++ à remettre en question leux vieilles habitudes. Par exemple, les programmeurs C
qui passent au C++ utilisent souvent des pointeurs, des tableaux, des #define plus que nécessaire. Cette FAQ liste ces choses commes
"mauvaises" afin de pousser ces nouveaux programmeurs C++ dans la bonne direction. Le but des métaphores du genre "les pointeurs sont
mauvais" est de convaincre les nouveaux programmeurs C++ que le C++ n'est pas "simplement du C avec les commentaires //".
Un peu plus sérieusement, je ne veux pas dire que les macros, les tableaux, les pointeurs sont criminels comme un meurte ou un enlèvement.
Bien que pour les pointeurs ... (ceci est une PLAISANTERIE). "Mauvais" , dans le cas présent, veut dire "choquant". Ne cherchez donc pas
une définition technique pour savoir ce qui est "mauvais" ou ne l'est pas.
Autre chose : les choses étiquetées "mauvaises" ne le sont pas dans toutes les situations. Quand elles sont la moins mauvaise des solutions,
utilisez-les !
Ce qui convient à l'un ne convient pas à un autre. Gardez toujours à l'esprit que "Développer des programmes, c'est Prendre des Décisisons".
PENSER n'est pas qu'un mot. Il y a très peu de règles du genre "Il faut toujours ..." ou "Il ne faut jamais ...." dans le développement, le
genre de règle que l'on applique sans réfléchir, les règles qui conviennent à tout le monde.
En bon français, vous devrez prendre des décisions, et la justesse de vos décisions affecteront la valeur commerciale de votre software.
Et dans certains cas, vous devrez faire le choix parmi une série de solutions toutes plus ou moins mauvaises. Qaund cela arrive, le mieux
que vous puissiez espérer est de choisir la moins mauvaise de ces solutions.
Finalement, vous finirez par utiliser des techniques "mauvaises". Si cela vous dérange, changez "mauvais" en "généralement indésirable"
(mais ne quittez pas votre travail pour cela, ce changement de terme permet juste aux gens de mieux dormir).
En C, l'encapsulation se faisait en
définissant les static dans un fichier compilé ou dans un module. Cela permettait d'éviter
qu'un autre module n'accède à la partie déclarée statique. (Au passage, les données statiques dans la limite d'un fichier est dépréciée
en C++, ne le faites donc plus).
Malheureusement, cette approche ne permet pas de supporter plusieurs instances des données, étant donné qu'il n'y a pas de support direct
pour créer des instances multiples des données statiques d'un module. Si plusieurs instances étaient nécessaires en C, les programmeurs
utilisaient généralement une structure. Mais, pas de chance, les structures C ne supportent pas l'encapsulation. Cela dégradait le
compromis entre fiabilité (le fait ce dissimuler l'information) et facilité d'utilisation (les instances multiples).
En C++, vous pouvez avoir des instances multiples et l'encapsulation en utilisant les classes. La partie publique de la classe contient
son interface, qui consiste habituellement en ses fonctions membres publiques et ses fonctions amies. Les parties protégées et/ou privées
contiennent l'implémentation de la classe, ce qui est habituellement l'endroit où sont stockées les données.
Le résultat final est comme une "structure encapsulée". Cela améliore le compromis entre fiabilité (dissimulation de l'information) et
facilité d'utilisation (les instances multiples).
Ce document issu de http://www.developpez.com est soumis à la licence
GNU FDL traduit en français
ici.
Permission vous est donnée de distribuer, modifier des copies de cette page tant que cette note apparaît clairement.
Certaines parties de ce document sont sous copyright Marshall Cline
