[6] Problèmes d'ordre général

Oui.

C++ est un outil pratique. Il n'est pas parfait , mais il est utile.

Dans le monde du logiciel industriel, C++ est vu comme un outil sur, mûr, et sans surprise. Il est très répandu dans l'industrie ce qui le valorise d'un point de vue productif en général.

Non.

C++ n'a pas été conçu pour montrer à quoi ressemble un langage OO parfait. Il a été conçu pour être un outil pratique de résolution des problèmes réels. Il a quelques verrues, mais le seul endroit où il est approprié de continuer à perfectionner une pièce jusqu'à la perfection est dans un configuration académique pure. Ce n'était pas but de C++.

Les techniques orientées objet sont la meilleure façon connue de traiter les gros projet, les applications complexes de logiciel et de systèmes.

Slogan OO : l'industrie du logiciel "n'arrive pas" à satisfaire les demandes de systèmes logiciel grands, et complexes. Mais cette "panne" est réellement due à nos succès: nos succès ont poussé les utilisateurs à demander plus. Malheureusement cela a créé une nouvelle demande que l'analyse "strucutrée", et les techniques de conception et de programmation classiques ne pouvaient pas satisfaire. Ceci a exigé de nous de créer un meilleur paradigme.

C++ est un langage de programmation OO. C++ peut également être utilisé comme langage de programmation traditionnel (comme "meilleur C"). Cependant si vous l'utilisez "comme meilleur C", ne comptez pas obtenir les avantages de la programmation orientée objet.

Cette question produit beaucoup beaucoup plus de chaleur que de lumière. Veuillez lire le paragraphe qui suit avant de poster une variante de cette question.

Dans 99% des cas, la sélection du langage de programmation est dominée par des considérations relatives à l'activité, et non pas par des considérations techniques. Les critères qui finissent par peser sont des citères de gestioncomme la disponibilité d'un environnement pour la machine de développement, la disponibilité de l' (des) environment(s) d'exécution pour la (les) machine(s) de déploiement, les problèmes légaux ou de licence des environnements d'exécution et/ou de développement, la disponibilité de développeurs qualifiés, la disponibilité de services de conseil, et la culture/politique de l'entreprise. Ces considérations de gestion jouent généralement un rôle beaucoup plus grand que le temps de compilation, le la vitesse d'exécution, le typage de donnée statique ou dynamique, le liage statique ou dynamique, etc...

Quiconque plaidant en faveur d'un langage par rapport aux autres d'une façon purement technique (c-à-d., qui ignore les problèmes de gestion) se désigne lui-même comme un technicien tétu, et ne mérite pas d'être écouté.

Un grand, un très grand nombre de sociétés et d'organismes gouvernementaux.

Le grand nombre de développeurs C++, donc le grand nombre d'outils, de librairies, est une des caractéristiques déterminantes du C++.

Des sociétés enseignent C++ avec succès en "courtes périodes" où un cours d'un semestre d'université est comprimé dans une semaine de travail de 40 heures. Mais indépendamment de l'endroit où vous obtenez votre formation, assurez vous que les cours ont un temps consacré à la pratique, car la plupart des personnes apprennent mieux quand elles ont des (mini-)projets pour appliquer les concepts "figés". Mais même la meilleureformation ne vous rend pas encore prêts.

Cela prend 6-12 mois pour devenir compétent en OO/C++. Moins si les développeurs ont un accès facile à un corps "local" d'experts, plus s'il n'y a pas de "bonne" bibliothèque de classes C++ tout usage. Devenir un de ces experts qui peuvent apprendre à d'autres prend autour de 3 ans.

Certains ne le font jamais. Vous n'avez pas une chance à moins que vous soyez receptif et motivé. Comme minimum strict, vous devez savoir admettre quand vous avez eu tort. Comme minimum strict de "motivation" vous devez être disposé à mettre quelques heures supplémentaires (il est beaucoup plus facile d'apprendre quelques nouveaux trucs que de changer votre paradigme [ c-à-d., pour changer votre manière de penser; pour changer votre notion de la qualité; pour changer votre modèle mental du monde de la technologie ]).

Deux choses que vous devriez faire:

• Trouvez un "mentor"
• Procurez à vos gens deux livres: un pour leur dire ce qui est légal, un autre pour leur dire ce qui est moral

Deux choses vous ne devriez pasfaire:

• Vous ne devez pas considérer le C comme une étape intermédiaire dans l'apprentissage de OO/C++
• Vous ne devez pas considérer le Smalltalk comme une étape intermédiaire dans l'apprentissage de OO/C++

Voici quelques caractéristiques OO/C++ d'un point vue business:

• C++ a une énorme base existante , ce qui signifie que vous aurez plusieurs vendeurs pour les outils de développement, les environments, les services de conseil, etc. , plus une ligne très valorisante dans votre cv.
• C++ permet aux développeurs de fournir des interfaces simplifiés aux morceaux de logiciel, ce qui diminue la probabilité de défaut lorsque ces morceaux sont réutilisés.
• C++ vous permet d'exploiter l'intuition des developpeur grâce à la surcharge d'operateur , ce qui réduit le temps d'apprentissage pour les (ré)utilisateurs.
• C++ localise l'acces à une partie de logiciel, ce qui réduit le coût de changements.
• C++ réduit le compromis fiabilité/utilisabilité , ce qui réduit le coût de (re)utilisation d'une partie de logiciel.
• C++ réduit le compromis fiabilité/vitesse, ce qui améliore la qualité sans dégrader la performance.
• C++ vous apporte l'héritage et l'appel dynamique ce qui permet au vieux code d'appeler le nouveau code, rendant possible de rapidement étendre/adapter votre logiciel pour toucher des fenêtres de marché étroite.

Oui!
Sans les functions virtuelles, C++ ne serait pas orienté objet. La surcharge d'opérateurne sont après tout, qu'une variante syntaxique du C.

D'un point de vue de gestion, C++ sans les fonctions virtuelles a peu de valeur ajouté sur C. Les spécialistes pensent souvent qu'il y a une grande différence entre C et un C++ non orienté objet, mais sans OO, la différence n'est habituellement pas suffisante pour justifier le coût de formation des développeurs, des nouveaux outils, etc. En d'autres termes, si je devais conseiller un gestionnaire sur la pertinance d'un passage de C à un C++ non orienté objet (c-à-d changer de langage mais non de paradigme), je le ou la découragerais probablement à moins qu'il y ait des contraintes liées aux outils de développement. D'un point de vue gestion, OO peut aider à faire des systèmes plus extensibles et adaptables, mais la syntaxe des classes C++ seule sans OO peut éventuellement ne pas réduire le coût de maintenance, et certainement ajoute au coût de formation de manière significative.

Note: C++ sans virtual n'est pas OO. La programmation avec classes mais sans appels dynamiques s'appelle la programmation "basé objet", et non "orienté objet". Jeter les fonctions virtual est équivalent à jeter OO. Tout ce qu'il vous reste est la programmation basé objet, similaire au première version d'Ada (les versions récente d'Ada sont véritablement OO).

Vue d'ensemble: L'appel dynamique facilite la réutilisation du code en laissant l'anciencode appeler le nouveaucode.

Avant la programmation OO, la réutilisation se limitait à du code nouveau appelant du code ancien. Par exemple, un programmeur pouvait écrire une routine qui utilisait un code existant réutilisable tel que printf().

Avec la programmation OO, la réutilisation peut également être accomplie dans l'autre sens. Par exemple, un programmeur peut écrire une routine destinée à être appelée par un cadre d'exécution qui a été écrit par leur arrière, arrière grand-père. Et il n'y a aucun besoin de changer le code de l'arrière arrière grand-père. En fait, on n'a même pas besoin de recompiler le cadre appellant. Même si tout ce que vous avez est le fichier objet et si les fichiers sources que l'arrière, arrière grand-père avait écrit il y a 25 ans sont perdu, ce fichier objet antique appellera la nouvelle extension sans que quoi que ce soit tombe en morceaux.

Ceci s'appelle extensibilité, et ceci s'appelle programmation OO.

Quasiment.

C++ est aussi proche que possible de la compatibilité avec C, mais pas plus proche. En pratique, la différence principale est d'une part que C++ exige des prototypes, et que d'autre part la déclaration f() déclare une fonction qui ne prend aucun paramètre alors qu'en C, f() est le même chose que le f(...), c'est-à-dire une fonction prenant un nombre d'argument variable.

Il y a quelques autres différences plus subtiles, comme sizeof('x ') qui est égal à sizeof(char) en C++ mais qui est égal à sizeof(int) en C. De plus, C++ met les structures "étiquette" dans le même espace de nom que les autres noms, tandis que C exige un struct explicite (par exemple, la technique typedef struct Fred Fred; fonctionne toujours, mais elle est redondante en C++).

Oui.

C++ a été normalisé par l'ANSI (l'organisme de normalisation national américain), BSI (l'institut britannique de normes), DIN (l'organisme de normalisation national allemand), plusieurs autres organismes nationaux de normalisation, et ISO (l'organisme de normalisation international). La norme ISO a été menée à bonne fin et adoptée à l'unanimité le 14 Novemebre 1997.

Le comité ANSI-C++ s'appelle le "X3J16". Le groupe de standardisation ISO de C++ s'appelle le "WG21". L'ensemble des acteurs principaux dans le processus de normalisation de l'ANSI/ISO C++ compte des représentants d'Australie, du Canada, du Danemark, de France, d'Allemagne, d'Irlande, du Japon, de Hollandes, de Nouvelle Zélande, de Suède, du R-U, et des Etats-Unis, plus des représentants d'une centaine de société et de beaucoup de particuliers intéressés. Les principales sociétés incluent AT&T, Ericsson, Digital, Borland, Hewlett Packard, IBM, Mentor Graphics, Microsoft, Silicon Graphics, Sun Microsystems, et Siemens. Après environ 8 ans de travail, cette norme est maintenant complète. Le 14 Novembre 1997 a vu la norme être approuvée à l'unanimité des pays représentés à Morristown. La ratification finale par deux douzaines de pays est attendue pour Mars 1998.

Il y a au moins 3 facons differentes d'obtenir une version electronique du standard:

• $18 [par ANSI]: Ici et cliquer "Add to Basket."
• $34 [par ANSI]: Ici, selectionner "PDF file", et cliquer "Place this in your shopping basket."
• $245 [par ISO]: Ici et cliquer "Add to Basket."

Note: Le document par l'ISO est dix fois plus cher que celui de l'ANSI, bien que leurs contenus soient les memes. Le document de l'ISO a un titre different. Merci de ne pas me demander pourquoi l'ISO charge beaucoup plus pour ce qui est fondamentallement la meme chose, c'est leur decision donc aller leur demander.

Il y a au moins 2 moyens d'obtenir une version papier du standard:

• $175 [par ANSI]: Ici, selectionner "Hardcopy", et cliquer "Place this in your shopping basket."
• Prix inconnu [par ANSI]: Appeler le NCITS, National Committee for Information Technology Standards (anciennement "X3"). La personne a contacte est: Monica Vega, 202-626-5739 ou 202-626-5738. Demander le document: FDC 14882. Preparer vos sous car ce document n'est pas gratuit.

Il y a deux autres documents qui pourraient aussi vous interesser (et qui sont gratuits):

• $0: If you're willing to put up with a (free) document that's non-authorative, out-of-date, and partially incorrect, you can get "committee draft #2" ici et/ou là.
• $0: Le communiqué de presse de l'ISO (ce n'est pas une copie du standard par l'ANSI ou l'ISO!) est ici. Ce communiqué de presse est lisible par des non-programmeurs.

Cette réponse est destinée aux managers non-techniques et aux personnes des resources humaines qui essayent de faire un bon boulot lors d'interviews de candidats. Si tu es un programmeur C++ qui vient ici dans l'espoir de trouver les questions qui te seront posées, honte a toi: apprend a programmer et tu n'auras pas a tricher dans ta vie!.

If you're a C++ programmer about to be interviewed, and if you're lurking in this FAQ hoping to know the questions they'll ask you ahead of time so you can avoid having to really learn C++, shame on you: spend your time becoming technically competent and you won't have to try to "cheat" your way through life!

Pour revenir aux managers, s'il est clair que vous etes parfaitement qualifié pour juger si un candidat est adapté avec la culture de votre entreprise. Il y a malheureusement suffisamment de charlatans, starlettes ou de posers ici bas qu'il faut vraiment que vous faisaiez équipe avec quelqu'un qui est techniquement compétent pour etre sur que le candidat a un niveau technique correct. Beaucoup de compagnies se sont brulées en embauchant des gens incompétents bien que connaissant les réponses a quelques obscures questions. La seule facon de séparer le bon grain de l'ivraie c'est d'avoir quelqu'un qui puisse poser des questions pertinents. Vous n'avez aucun espoir de faire cela vous meme. Meme avec quelques questions piégeuses, vous ne pourrez pas détecter les mauvais.

Votre conseiller technique n'est peut-etre pas le plus qualifié pour juger la personnalité ou le charactere du candidat donc n'oublier pas votre role de décideur dans la décision finale. Mais s'il vous plait ne pensez pas que vous pouvez poser une demi douzaine de questions sur le C++ est avoir la plus petite idée du niveau technique du candidat.

Maintenant si vous etes assez technique pour lire cette FAQ, vous pourrez y trouver de nombreuses bonnes questions. La FAQ se concentre sur ce que les programmeurs doivent faire, par opposition a ce que le compilateur va leur laisser faire. Il y a des choses qui peuvent etre faites en C++ qui ne le devraient pas. Cette FAQ aide a séparer les deux.

Cela veux dire que machin est a éviter la plupart du temps, mais pas tout le temps. Par exemple, il faudra bien utiliser une de ces "mauvaises" constructions quand vous ne pouvez choisir qu'entre plusieurs "mauvaises" constructions. C'est de l'humour, ok? Donc a ne pas prendre trop sérieusement.

Le vrai but de cette dénomination est d'essayer d'éviter que les nouveaux développeurs C++ n'utilisent d'anciennes techniques. Par exemple, les programmeurs C qui sont nouveaux en C++ utilisent souvent des pointers, des tableaux et/ou des #define la ou ils pourraient sans passer. La FAQ liste ces constructions mauvaises pour pousser les nouveaux programmeurs C++ dans la bonne direction. Le but quand on dit que: "pointers sont mauvais" c'est de convaincre les nouveaux developeurs C++ que le C++ n'est pas seulement du C avec des commentaires de la forme // comments.

Now let's get real here. I'm not suggesting macros or arrays or pointers are right up there with murder or kidnapping. Well, may be pointers. (Just kidding!) So don't get all hyper about the word "evil": it's supposed to sound a little outrageous. So don't look for a technically precise definition of exactly when something is or isn't "evil": there isn't one.

Another thing: things labeled as "evil" (macros, arrays, pointers, etc.) aren't always bad in all situations. When they are the "least bad" of the alternatives, use them!

Tres certainement!

Une solution ne marche pas pour tout. Arrete toi. Maintenant prend un marker et ecrit a l'interieur de tes lunettes: Software Development Is Decision Making. Il y a tres peu, voire aucunes, regles de development qui commencent par "ne jamais..." ou "toujours...", des regles qui s'appliquent sans reflechir et qui marchent dans toutes les situations, pour tous les marches.

Simplement, vous allez devoir prendre des decisions et la qualite de ces decisions va avoir un effet sur la valeur economique de vos programme. Et des fois il vous faudra choisir entre plusieurs mauvaises options. Quand cela arrive, le mieux que vous pouvez esperer c'est de choisir la moins mauvaise des alternatives.

Donc vous utiliserez des techniques et des constructions qui sont connues pour etre "mauvaises". Si cela vous rend incomfortable, vous n'avez qu'a remplacer "mauvais" par "souvent indesirables"