Mélange des genres

Le C++ est le langage le plus courant qui permette de bien organiser les développements d'applications de toutes sortes. Cependant, des informaticiens ayant acquis l'expérience nécessaire pour obtenir de bons résultats à ce niveau (rien n'est prévu pour éviter les "débordements" : le C++ est un descendant du C et il y est toujours possible d'écrire des ignominies du point de vue de la lisibilité) ne sont pas forcément au bout de leurs peines pour autant. L'organisation la plus carrée des différents sources du programme peut être incompatible avec la vitesse de fonctionnement désirée (mais ce n'est pas obligatoire), d'autant plus qu'il ne suffit pas de se baser sur les matériels les plus récents - les plus rapides - mais qu'il faut aussi penser à ceux qui datent un peu. En cas de dilemmes entre ordonnancement (donc délais raccourcis et fiabilité) et performances il faut savoir jusqu'où ne pas aller trop loin dans les astuces en tous genres. Cela risque tout spécialement d'apparaître dans les domaines du multimédia et du graphisme.

Si l'on choisit de "sacrifier" la lisibilité de certaines parties de l'application pour les accélérer notablement, ceci afin de ne pas devoir le faire pour la totalité, on peut aller au bout de cette logique. Il est possible de définir des fonctions de bases, choisies pour le gain attendu par rapport au supplément de travail à fournir, qui seront écrites en assembleur et appelées par les modules C ou C++. C'est particulièrement vrai pour les architectures CISC car pour les processeurs RISC la facilité d'utilisation du langage d'assemblage est souvent négligée par rapport à l'optimisation des compilateurs courants. Avec cette solution il n'est bien sûr plus question de parler de portabilité de ces fonctionnalités élémentaires puisqu'un module précis ne sera utilisable qu'avec la famille de microprocesseurs correspondante.

Ceci n'est pas réellement gênant dans la mesure où l'incompatibilité est limitée à une partie de bas niveau et où des bibliothèques (regroupements de modules déjà compilés) sont employées. En fait, il vaut mieux avoir pour une architecture donnée une version des fonctions écrite en langage évolué (donc portable et plus facile à fiabiliser, première bibliothèque) et une autre écrite en assembleur (optimisée au mieux, deuxième bibliothèque). Il n'y a alors qu'à jongler avec les 2 versions durant les essais pour réaliser ceux-ci dans les meilleures conditions tout en s'assurant que chacune donne les mêmes résultats dans tous les cas. De toute façon, plus elles seront réutilisées et moins il restera de chances que des problèmes aient échappé à ce crible.