[27] Apprendre le C++ si vous connaissez déjà Smalltalk

Tous deux supporte pleinement le paradigme Orienté Objet. Ni l'un ni l'autre ne sont catégoriquement et universellement "meilleur" que l'autre . Mais il y a des différences. Les plus importantes sont:

• Typage statique vs. typage dynamique
• Utilisé l'héritage uniquement pour les types dérivés
• Valeur vs. référence

Note:Beaucoup de programmeurs C++ viennent du monde Smalltalk. Si vous êtes dans ce cas, cette section vous indiquera quelle sont les choses les plus importantes que vous devez savoir pour faire la transition. S'il vous plaît n'ayez pas a l'esprit qu'un langage est quelque peu "inférieur" ou "mauvais" , ou que cette section fait la promotion d'un langage par rapport a l'autre (Je ne suis pas un bigot de langage; je travaille dans les comités de standardisations de l'ANSI C++ et de l'ANSI Smalltalk ). Au lieu de cela, cette section est conçu pour vous aidez a comprendre les différences.

Typage statique signifie que le compilateur vérifie la sûreté de chaque opération statiquement(a la compilation), plutôt que de générer du code qui le vérifiera a l'exécution. Par exemple, avec le typage statique, la correspondance de signature pour les arguments d'une fonction sont vérifiés a la compilation, pas a l'exécution. Une correspondance non trouvée est capturée comme une erreur par le compilateur et non pas par le système a l'exécution.

Dans du code Orienté Objet, la plus fréquente "erreur de type" est d'invoquer une fonction membre sur un objet qui n'est pas préparé à accepter cette appel. E.g., si la classFred a une fonction membre f() mais pas de fonction membre g(), et fred est une instance de la class Fred, alors fred.f() est légal et fred.g() est illégal. C++ (typé statiquement) capture les erreurs a la compilation, tandis que Smalltalk (typé dynamiquement) capture les erreurs a l'exécution. (Techniquement parlant, C++ ressemble au Pascal -pseudo statiquement typé- depuis que les transtypages de pointeurs et les unions peuvent être utilisés pour violer le système de typage; ce qui me rappelle: utilisez les transtypages de pointeurs et les unions aussi rarement que vous utilisé les gotos).

[Pour le contexte, lisez la FAQ précédente ].

Si vous voulez utiliser le C++ efficacement, utiliser le comme un langage typé statiquement.

C++ est suffisamment flexible pour que vous puissiez (via les transtypages de pointers, les unions, et les #define macros) faire en sorte qu'il "ressemble" à Smalltalk. Ne le faites pas. Ce qui me rappelle: Essayé d'éviter les #define .

Il y a des cas ou le transtypage de pointeurs et les unions sont nécessaires et même saines, mais ils devraient être utilisés avec soin et parcimonie. Un transtypage de pointeur dit au compilateur de vous croire. Un transtypage de pointeur incorrect peut corrompre votre tas, écrire dans de la mémoire possédée par d'autres objets, appeler des fonctions membres inexistantes, et provoquer toutes sortes d'erreurs. Ce n'est pas un joli spectacle. Si vous les évitez ainsi que les constructions en relation, vous rendrez votre votre C++ à la fois plus sûr et plus rapide, car tout ce qui peut être vérifié a la compilation n'as pas besoin d'être vérifié a l'exécution

Si vous voulez utilisé le transtypage de pointeur, utilisez le nouveau style de transtypage. L'exemple le plus fréquent est de changer un transtypage ancien style tel que (X*)p en un transtypage nouveau style dynamique tel que dynamic_cast<X*>(p), ou p est un pointeur et X un type. En plus de dynamic_cast, il y a static_cast et const_cast, mais dynamic_cast un de ceux qui simule le mieux les avantages du typages dynamique (l'autre est le typeid(); par exemple, typeid(*p).name() retournera le nom du type de *p).

Certains pensent que le propos de l'héritage est la réutilisation du code. En C++, ceci est faux. Enoncé clairement, "l'héritage n'est pas fait pourla réutilisation du code."

Le propos de l'héritage en C++ est d'exprimer la conformité d'interface (sous-typage), et non pas pour avoir du code réutilisable. En C++, la réutilisation du code vient de la composition plutôt que de l'héritage. En d'autres termes l'héritage est principalement une technique de spécification plutôt qu'une technique d'implémentation.

Il y a une différence majeur avec Smalltalk, ou il n'y a qu'une forme d'héritage (C++ fournit l'héritage privé qui signifie "partagé le code mais ne pas se conformer à l'interface", et l'héritage public qui signifie "sorte-de (kind-of)"). Smalltalk pris dans sa lettre (par opposition au convention d'écriture) vous permet d'avoir l' effet de "cacher" une méthode héritée en fournissant une surcharge de la méthode "je ne comprend pas". De plus Smalltalk permet à une relation "is-a (est-un)" d'exister en dehors de la hiérarchie de classe (les sous-types) n'ont pas besoin d'être des classes dérivés; E.g., vous pouvez faire quelque chose qui est une (is-a) Pile mais qui n'hérite pas de la classe Pile).

A l'opposé, C++ est plus restrictif a propos de l'héritage: il n'y a pas de moyen de spécifier un "concept is-a(est-un)" sans utiliser l'héritage (le C++ sépare l'interface de l'implémentation via les ABCs ). Le compilateur C++ exploite les informations sémantiques ajoutées par l'héritage public pour fournir le typage statique.

[Pour le contexte, lisez la FAQ précédente ].

Smalltalk vous permet d'écrire un sous-type qui n'est pas une sous-classe, et permet de faire une sous-classe qui n'est pas un sous-type. Ceci permet au programmeur d'être insouciant quand au choix des donnés (bits, représentation, structure de données) d'une classe (E.g., vos pouvez mettre une liste chaîné dans une classePile). Après tout si quelqu'un désire une Pile basé sur un vecteur, il n'a pas besoin d'hériter depuis Pile; il pourrait hérité une telle classe depuis Tableau si il le désire, bien qu'une PileBaséTableau n'est pas une sorte-de (kind-of) Tableau!

En C++, vous ne pouvez pas être aussi libre. Seulement les mécanismes (code des fonctions membres), mais pas la représentation (données) peuvent être surchargées dans une classe dérivée. Vous êtes en général plus à l'aise en ne mettant pas les structures de données dans la classe de base. Ceci mène a une plus forte confiance dans les classes de base abstraites.

J'aime a penser cela en terme de différence entre une 4x4 et une Maseratti. Un 4x4 est plus amusant car vous pouvez "jouer aux alentours"" en conduisant a travers champs, chemins etc. Une Maseratti, d'un autre coté, vous permet d'aller plus vite mais vous force a rester sur la route. Mon avis au programmeur C++ est simple : rester sur la route. Même si vous faite partie des gens qui aime "la liberté d'expression" pour conduire a travers champs, ne le faites pas en C++; Ce n'est pas une bonne manière de faire.