Un interpréteur traduit le code source en activités (lesquelles peuvent être constituées de groupes d'instructions machine) et exécute immédiatement ces activités. Le BASIC, par exemple, a été un langage interprété très populaire. Traditionnellement, les interpréteurs BASIC traduisent et exécutent une ligne à la fois, puis oublient que la ligne a été traduite. Cela fait qu'ils sont lents, puisqu'ils doivent retraduire tout le code répété. Le BASIC a été également compilé, pour la rapidité. Des interpréteurs plus modernes, comme ceux du langage Python, traduisent le programme entier dans un langage intermédiaire qui est alors exécuté par un interpréteur beaucoup plus rapide (24)

Les interpréteurs ont beaucoup d'avantages. La transition entre l'écriture du code et son exécution est presque immédiate, et le code source est toujours disponible ainsi l'interpréteur peut être beaucoup plus spécifique quand une erreur se produit. Les avantages souvent cités pour les interpréteurs sont la facilité d'interaction et la vitesse de développement (mais pas nécessairement d'exécution) des programmes.

Les langages interprétés ont souvent de graves limitations lors de la réalisation de grands projets (Python semble être une exception en cela). L'interpréteur (ou une version réduite) doit toujours être en mémoire pour exécuter le code, et même l'interpréteur le plus rapide introduira d'inacceptables restrictions de vitesse. La plupart des interpréteurs requièrent que la totalité du code source soit passé à l'interpréteur en une fois. Non seulement cela introduit une limitation spatiale, mais cela entraîne également plus de bogues difficiles à résoudre si le langage ne fournit pas de facilités pour localiser les effets des différentes parties du code.

Un compilateur traduit le code source directement en langage assembleur ou en instructions machine. L'éventuel produit fini est un fichier ou des fichiers contenant le code machine. C'est un processus complexe, nécessitant généralement plusieurs étapes. La transition entre l'écriture du code et son exécution est significativement plus longue avec un compilateur.

En fonction de la perspicacité du créateur du compilateur, les programmes générés par un compilateur tendent à utiliser beaucoup moins d'espace pour s'exécuter, et s'exécutent beaucoup plus rapidement. Bien que la taille et la vitesse soient probablement les raisons les plus citées d'utilisation des compilateurs, dans nombre de situations ce ne sont pas les raisons les plus importantes. Certains langages (comme le C) sont conçus pour autoriser la compilation séparée de certaines parties du programme. Ces parties sont éventuellement combinées en un programme exécutable final par un outil appelé éditeur de liens( linker). Ce processus est appelé compilation séparée.

La compilation séparée a moult avantages. Un programme qui, en prenant tout en une fois, excède les limites du compilateur ou de l'environnement de compilation peut être compilé par morceaux. Les programmes peuvent être construits et testés morceau par morceau. Une fois qu'un morceau fonctionne, il peut être sauvegardé et traité comme un module. Les collections de morceaux testés et validés peuvent être combinées en bibliothèques pour être utilisés par d'autres programmeurs. Pendant que chaque morceau est créé, la complexité des autres morceaux est cachée. Tous ces dispositifs permettent la création de programmes volumineux (25).

Les dispositifs de débogage des compilateurs se sont sensiblement améliorés ces derniers temps. Les compilateurs de première génération généraient seulement du code machine, et le programmeur insérait des rapports d'impression pour voir ce qui se passait. Ce n'est pas toujours efficace. Les compilateurs modernes peuvent insérer des informations à propos du code source dans le programme exécutable. Ces informations sont utilisées par de puissants débogueurs de haut-niveau pour montrer exactement ce qui se passe en traçant la progression dans le code source.

Quelques compilateurs abordent le problème de la vitesse de compilation en exécutant une compilation en mémoire. La plupart des compilateurs fonctionnent avec des fichiers, les lisant et les écrivant à chaque étape du processus de compilation. Les compilateurs résidents gardent le programme de compilation dans la RAM. Pour les petits programmes, cela peut sembler aussi réactif qu'un interpréteur.

Pour programmer en C et C++ vous avez besoin de comprendre les étapes et les outils du processus de compilation. Certains langages (le C et le C++, en particulier) débutent la compilation en exécutant un préprocesseur sur le code source. Le préprocesseur est un programme simple qui remplace les modèles dans le code source par d'autres modèles que le programmeur a défini (en utilisant les directives du préprocesseur). Les directives du préprocesseur sont utilisées pour limiter les frappes et augmenter la lisibilité du code. (Plus loin dans le livre vous apprendrez comment la conception du C++ est faite pour décourager une grande partie de l'utilisation du préprocesseur, puisqu'elle peut causer les bogues subtils.) Le code prétraité est souvent écrit dans un fichier intermédiaire.

Les compilateurs travaillent souvent en deux temps. La première passe décompose le code prétraité. Le compilateur sépare le code source en petites unités et l'organise dans une structure appelé arbre. Dans l'expression " A + B" les éléments " A", " +", et " B" sont des feuilles de l'arbre de décomposition.

Un optimisateur global est parfois utilisé entre la première et la deuxième passe pour produire un code plus petit et plus rapide.

Dans la seconde passe, le générateur de code parcourt l'arbre de décomposition et génère soit du code en langage assembleur soit du code machine pour les noeuds de l'arbre. Si le générateur de code produit du code assembleur, l'assembleur doit être exécuté. Le résultat final dans les deux cas est un module objet (un fichier dont l'extension est typiquement .o ou .obj). Un optimiseur à lucarne( peephole optimizer) est parfois utilisé dans la deuxième passe pour rechercher des morceaux de code contenant des instructions de langage assembleur redondantes.

L'utilisation du mot "objet" pour décrire les morceaux du code machine est un artefact regrettable. Le mot fût employé avant que la programmation orientée objet ne se soit généralisée. "Objet" est utilisé dans le même sens que "but" lorsqu'on parle de compilation, alors qu'en programmation orientée objet cela désigne "une chose avec une frontière".

L' éditeur de liens combine une liste de modules objets en un programme exécutable qui peut être chargé et lancé par le système d'exploitation. Quand une fonction d'un module objet fait référence à une fonction ou une variable d'un autre module objet, l'éditeur de liens résout ces références ; cela assure que toutes les fonctions et les données externes dont vous déclarez l'existence pendant la compilation existent. L'éditeur de liens ajoute également un module objet spécial pour accomplir les activités du démarrage.

L'éditeur de liens peut faire des recherches dans des fichiers spéciaux appelés bibliothèques afin de résoudre toutes les références. Une bibliothèque contient une collection de modules objets dans un fichier unique. Une bibliothèque est créée et maintenue par un programme appelé bibliothécaire( librarian).

Vérification statique du type

Le compilateur exécute la vérification de type pendant la première passe. La vérification de type teste l'utilisation appropriée des arguments dans les fonctions et empêche beaucoup de sortes d'erreurs de programmation. Puisque la vérification de type se produit pendant la compilation et non à l'exécution du programme, elle est appelé vérification statique du type.

Certains langages orientés objet (notamment Java) font des vérifications de type pendant l'exécution ( vérification dynamique du type). Si elle est combinée à la vérification statique du type, la vérification dynamique du type est plus puissante que la vérification statique seule. Cependant, cela ajoute également un coût supplémentaire à l'exécution du programme.

Le C++ utilise la vérification statique de type car le langage ne peut assumer aucun support d'exécution particulier en cas de mauvaises opérations. La vérification statique du type notifie au programmeur les mauvaises utilisations de types pendant la compilation, et ainsi maximise la vitesse d'exécution. En apprenant le C++, vous verrez que la plupart des décisions de conception du langage favorisent ce genre de rapidité, programmation axée sur la production pour laquelle le langage C est célèbre.

Vous pouvez désactiver la vérification statique du type en C++. Vous pouvez également mettre en oeuvre votre propre vérification dynamique de type - vous avez seulement besoin d'écrire le code.

Il est important de comprendre la différence entre déclarations et définitions, parce que ces termes seront utilisés précisément partout dans le livre. Par essence, tous les programmes C et C++ exigent des déclarations. Avant que vous puissiez écrire votre premier programme, vous devez comprendre la manière convenable d'écrire une déclaration.

Une déclaration introduit un nom - un identifiant - pour le compilateur. Elle indique au compilateur "Cette fonction ou cette variable existe quelque part, et voici à quoi elle devrait ressembler." Une définition, d'un autre côté, dit : "Faire cette variable ici" ou "Faire cette fonction ici". Elle alloue de l'espace pour le nom. Ce principe s'applique aux variables comme aux fonction ; dans tous les cas, le compilateur alloue de l'espace au moment de la définition. Pour une variable, le compilateur détermine sa taille et entraîne la réservation de l'espace en mémoire pour contenir les données de cette variable. Pour une fonction, le compilateur génère le code, qui finit par occuper de l'espace en mémoire.

Vous pouvez déclarer une variable ou une fonction dans beaucoup d'endroits différents, mais il doit y avoir seulement une définition en C et C++ (ceci s'appelle parfois l'ODR : one-definition rule). Quand l'éditeur de liens unit tous les modules objets, il se plaindra généralement s'il trouve plus d'une définition pour la même fonction ou variable.

Une définition peut également être une déclaration. Si le compilateur n'a pas vu le nom x avant, et que vous définissez int x;, le compilateur voit le nom comme une déclaration et alloue son espace de stockage en une seule fois.

Syntaxe de la déclaration de fonction

Une déclaration de fonction en C et C++ donne le nom de fonction, le type des paramètres passés à la fonction, et la valeur de retour de la fonction. Par exemple, voici une déclaration pour une fonction appelée func1( ) qui prend deux arguments entiers (les nombres entiers sont annoncés en C/C++ avec le mot-clé int) et retourne un entier :

int func1(int,int);

Le premier mot-clé que vous voyez est la valeur de retour elle-même int. Les paramètres sont entourés de parenthèses après le nom de la fonction, dans l'ordre dans lequel ils sont utilisés. Le point virgule indique la fin d'une instruction; dans l'exemple, il indique au compilateur "c'est tout - il n'y a pas de définition de fonction ici !"

Les déclarations du C et du C++ essaient d'imiter la forme d'utilisation de l'élément. Par exemple, si a est un autre entier la fonction ci-dessus peut être utilisée de cette façon :

a = func1(2,3);

Puisque func1( ) retourne un entier, le compilateur C ou C++ vérifiera l'utilisation de func1( ) pour s'assurer que a peut accepter la valeur de retour de la fonction et que les arguments sont appropriés.

Les arguments dans les déclarations de fonction peuvent avoir des noms. le compilateur ignore les noms, mais ils peuvent être utiles en tant que dispositifs mnémoniques pour l'utilisateur. Par exemple, nous pouvons déclarer func1( ) d'une façon différente qui a la même signification :

int func1(int taille, int largeur);

Un piège

Il y a une différence significative entre le C et le C++ pour les fonctions dont la liste d'arguments est vide. En C, la déclaration :

int func2();

signifie "une fonction avec n'importe quel nombre et type d'arguments." Cela empêche la vérification du type, alors qu'en C++ cela signifie "une fonction sans argument."

Définitions de fonction

Les définitions de fonction ressemblent aux déclarations de fonction sauf qu'elles ont un corps. Un corps est un ensemble d'instructions entouré d'accolades. Les accolades annoncent le début et la fin d'un bloc de code. Pour donner une définition à func1( ) qui soit un corps vide (un corps ne contenant aucun code), écrivez :

int func1(int taille, int largeur) { }

Notez que dans la définition de fonction, les accolades remplacent le point-virgule. Puisque les accolades entourent une instruction ou un groupe d'instructions, vous n'avez pas besoin d'un point-virgule. Notez aussi que les paramètres dans la définition de fonction doivent avoir des noms si vous voulez les utiliser dans le corps de la fonction (comme ils ne sont jamais utilisés dans l'exemple, c'est optionnel).

Syntaxe de la déclaration de variable

La signification attribuée à l'expression "déclaration de variable" a historiquement été déroutante et contradictoire, et il est important que vous compreniez la définition correcte, ainsi vous pouvez lire le code correctement. Une déclaration de variable indique au compilateur à quoi une variable ressemble. Elle dit, "Je sais que tu n'as pas vu ce nom avant, mais je promets qu'il existe quelque part, et que c'est une variable du type X."

Dans une déclaration de fonction, vous donnez un type (la valeur de retour), le nom de la fonction, la liste des arguments, et un point-virgule. C'est suffisant pour que le compilateur comprenne que c'est une déclaration et ce à quoi la fonction devrait ressembler. de la même manière, une déclaration de variable pourrait être un type suivi d'un nom. Par exemple :

int a;

pourrait déclarer la variable a comme un entier, en utilisant la logique ci-dessus. Voilà le conflit : il y a assez d'information dans le code ci-dessus pour que le compilateur crée l'espace pour un entier appelé a, et c'est ce qui se produit. Pour résoudre ce dilemme, un mot-clé était nécessaire en C et C++ pour dire "ceci est seulement une déclaration ; elle a été définie ailleurs." Le mot-clé est extern. Il peut signifier que la définition est extern e au fichier, ou que la définition a lieu plus tard dans le fichier.

Déclarer une variable sans la définir signifie utiliser le mot-clé extern avant une description de la variable, comme ceci :

extern int a;

extern peut aussi s'appliquer aux déclarations de fonctions. Pour func1( ), ça ressemble à :

extern int func1(int taille, int largeur);

Cette instruction est équivalente aux précédentes déclarations de func1( ). Puisqu'il n'y a pas de corps de fonction, le compilateur doit la traiter comme une déclaration de fonction plutôt qu'une définition de fonction. Le mot-clé extern est donc superflu et optionnel pour les déclarations de fonctions. Il est vraisemblablement regrettable que les concepteurs du C n'aient pas requis l'utilisation d' extern pour les déclarations de fonctions ; cela aurait été plus cohérent et moins déroutant (mais cela aurait nécessité plus de frappes, ce qui explique probablement la décision).

Voici quelques exemples de déclarations :

//: C02:Declare.cpp
// Exemples de déclaration & définition
extern int i; // Déclaration sans définition
extern float f(float); // Déclaration de fonction
 
float b;  // Déclaration & définition
float f(float a) {  // Définition
  return a + 1.0;
}
 
int i; // Définition
int h(int x) { // Déclaration & définition
  return x + 1;
}
 
int main() {
  b = 1.0;
  i = 2;
  f(b);
  h(i);
} ///:~

Dans les déclarations de fonctions, les identifiants d'argument sont optionnels. Dans les définitions, ils sont requis (les identifiants sont requis uniquement en C, pas en C++).

Inclusion d'en-têtes

La plupart des bibliothèques contiennent un nombre significatif de fonctions et de variables. Pour économiser le travail et assurer la cohérence quand sont faites des déclarations externes pour ces éléments, le C et le C++ utilisent un dispositif appelé le fichier d'en-tête. Un fichier d'en-tête est un fichier contenant les déclarations externes d'une bibliothèque; il a par convention une extension de nom de fichier "h", comme headerfile.h. (Vous pourrez également voir certains codes plus anciens utilisant des extensions différentes, comme .hxx ou .hpp, mais cela devient rare.)

Le programmeur qui crée la bibliothèque fournis le fichier d'en-tête. Pour déclarer les fonctions et variables externes de la bibliothèque, l'utilisateur inclus simplement le fichier d'en-tête. Pour inclure un fichier d'en-tête, utilisez la directive du préprocesseur #include. Elle demande au préprocesseur d'ouvrir le fichier d'en-tête cité et d'insérer son contenu là où l'instruction #include apparaît. Un #include peut citer un fichier de deux façons : entre équerres ( < >) ou entre guillemets doubles.

Les noms de fichiers entre équerres, comme :

#include <entete>

font rechercher le fichier par le préprocesseur d'une manière propre à votre implémentation, mais typiquement il y a une sorte de "chemin de recherche des inclusions" que vous spécifiez dans votre environnement ou en ligne de commandes du compilateur. Le mécanisme de définition du chemin de recherche varie selon les machines, les systèmes d'exploitation, et les implémentations du C++, et peut nécessiter quelque investigation de votre part.

Les noms de fichiers entre guillemets doubles, comme :

#include "local.h"

indiquent au préprocesseur de chercher le fichier (selon les spécifications) "d'une manière définie par l'implémentation." Ceci signifie typiquement de chercher le fichier relativement au répertoire courant. Si le fichier n'est pas trouvé, alors la directive d'inclusion est retraitée comme s'ils s'agissait d'équerres et non de guillemets.

Pour inclure le fichier d'en-tête iostream, vous écrivez :

#include <iostream>

Le préprocesseur trouvera le fichier d'en-tête iostream (souvent dans un sous-répertoire appelé "include") et l'insérera.

Format d'inclusion du Standard C++

Alors que le C++ évoluait, les différents fournisseurs de compilateurs ont choisi différentes extensions pour les noms de fichiers. En outre, les divers systèmes d'exploitation ont différentes contraintes sur les noms de fichiers, en particulier la taille du nom. Ces sujets ont entraîné des problèmes de portabilité du code source. Pour arrondir les angles, le standard utilise un format qui permet des noms de fichiers plus longs que les huit caractères notoires et élimine l'extension. Par exemple, au lieu du vieux style d'inclusion iostream.h, qui ressemble à :

#include <iostream.h>

vous pouvez maintenant écrire :

#include <iostream>

L'interprète peut mettre en application les instructions d'inclusion d'une façon qui convient aux besoins de ces compilateur et système d'exploitation particuliers, si nécessaire en tronquant le nom et en ajoutant une extension. Bien sûr, vous pouvez aussi copier les en-têtes donnés par le fournisseur de votre compilateur dans ceux sans extensions si vous voulez utiliser ce style avant que le fournisseur ne le supporte.

Les bibliothèques héritées du C sont toujours disponibles avec l'extension traditionnelle " .h". Cependant, vous pouvez aussi les utiliser avec le style d'inclusion plus moderne du C++ en ajoutant un " c" devant le nom. Ainsi :

#include <stdio.h>;
#include <stdlib.h>

devient :

#include <cstdio>
#include <cstdlib>

Et ainsi de suite, pour tous les en-têtes standards du C. Cela apporte une distinction agréable au lecteur, indiquant quand vous employez des bibliothèques C et non C++.

L'effet du nouveau format d'inclusion n'est pas identique à l'ancien : utiliser le .h vous donne la version plus ancienne, sans modèles, et omettre le .h vous donne la nouvelle version, avec modèles. Vous aurez généralement des problèmes si vous essayez d'entremêler les deux formes dans un même programme.

L'éditeur de liens rassemble les modules objets (qui utilisent souvent des extensions de nom de fichier comme .o ou .obj), générés par le compilateur, dans un programme exécutable que le système d'exploitation peut charger et démarrer. C'est la dernière phase du processus de compilation.

Les caractéristiques de l'éditeur de liens changent d'un système à l'autre. Généralement, vous donnez simplement à l'éditeur de liens les noms des modules objets et des bibliothèques que vous voulez lier ensemble, et le nom de l'exécutable, et il va fonctionner. Certains systèmes nécessitent d'appeler l'éditeur de liens vous-même. Avec la plupart des éditeurs C++, vous appelez l'éditeur de liens à travers le compilateur C++. Dans beaucoup de situations, l'éditeur de liens est appelé sans que vous le voyez.

Certains éditeurs de liens plus anciens ne chercheront pas les fichiers objets et les bibliothèques plus d'une fois, et ils cherchent dans la liste que vous leur donnez de gauche à droite. Ceci signifie que l'ordre des fichiers objets et des bibliothèques peut être important. Si vous avez un problème mystérieux qui n'apparaît pas avant l'édition des liens, une cause possible est l'ordre dans lequel les fichiers sont donnés à l'éditeur de liens.

Maintenant que vous connaissez la terminologie de base, vous pouvez comprendre comment utiliser une bibliothèque :

1. Incluez le fichier d'en-tête de la bibliothèque.
2. Utilisez les fonctions et variables de la bibliothèque.
3. Liez la bibliothèque dans le programme exécutable.

Ces étapes s'appliquent également quand les modules objets ne sont pas combinés dans une bibliothèque. Inclure un fichier d'en-tête et lier les modules objets sont les étapes de base de la compilation séparée en C et C++.

Comment l'éditeur de liens cherche-t-il une bibliothèque ?

Quand vous faites une référence externe à une fonction ou variable en C ou C++, l'éditeur de liens, lorsqu'il rencontre cette référence, peut faire deux choses. S'il n'a pas encore rencontré la définition de la fonction ou variable, il ajoute l'identifiant à sa liste des "références non résolues". Si l'éditeur de liens a déjà rencontré la définition, la référence est résolue.

Si l'éditeur de liens ne peut pas trouver la définition dans la liste des modules objets, il cherche dans les bibliothèques. Les bibliothèques ont une sorte d'index de telle sorte que l'éditeur de liens n'a pas besoin de parcourir tous les modules objets de la bibliothèque - il regarde juste l'index. Quand l'éditeur de liens trouve une définition dans une bibliothèque, le module objet complet, et non seulement la définition de fonction, est lié dans le programme exécutable. Notez que la bibliothèque n'est pas liée dans son ensemble, seulement le module objet de la bibliothèque qui contient la définition que vous voulez (sinon les programmes seraient inutilement volumineux). Si vous voulez minimiser la taille du programme exécutable, vous pouvez imaginer mettre une seule fonction par fichier du code source quand vous construisez vos propres bibliothèques. Cela nécessite plus de rédaction. (26)mais ça peut être utile aux utilisateurs.

Comme l'éditeur de liens cherche les fichiers dans l'ordre dans lequel vous les listez, vous pouvez préempter l'utilisation d'une fonction de bibliothèque en insérant un fichier avec votre propre fonction, utilisant le même nom de fonction, dans la liste avant l'apparition du nom de la bibliothèque. Puisque l'éditeur de liens résoudra toutes les références à cette fonction en utilisant votre fonction avant de chercher dans la bibliothèque, votre fonction sera utilisée à la place de la fonction de la bibliothèque. Notez que cela peut aussi être un bogue, et que les espaces de nommage du C++ préviennent ce genre de choses.

Ajouts cachés

Quand un programme exécutable C ou C++ est créé, certains éléments sont secrètement liés. L'un d'eux est le module de démarrage, qui contient les routines d'initialisation qui doivent être lancées à chaque fois qu'un programme C ou C++ commence à s'exécuter. Ces routines mettent en place la pile et initialisent certaines variables du programme.

L'éditeur de liens cherche toujours dans la bibliothèque standard les versions compilées de toutes les fonctions "standard" appelées dans le programme. Puisque la librairie standard est toujours recherchée, vous pouvez utiliser tout ce qu'elle contient en incluant simplement le fichier d'en-tête approprié dans votre programme ; vous n'avez pas à indiquer de rechercher dans la bibliothèque standard. Les fonctions iostream, par exemple, sont dans la bibliothèque Standard du C++. Pour les utiliser, vous incluez juste le fichier d'en-tête <iostream>.

Si vous utilisez une bibliothèque complémentaire, vous devez explicitement ajouter le nom de la bibliothèque à la liste des fichiers donnés à l'éditeur de liens.

Utilisation des bibliothèques C

Bien que vous écriviez du code en C++, on ne vous empêchera jamais d'utiliser des fonctions d'une bibliothèque C. En fait, la bibliothèque C complète est incluse par défaut dans le Standard C++. Une quantité énorme de travail a été effectuée pour vous dans ces fonctions, elles peuvent donc vous faire gagner beaucoup de temps.

Ce livre utilisera les fonctions de la bibliothèque Standard C++ (et donc aussi le standard C) par commodité, mais seules les fonctions de la bibliothèque standard seront utilisées, pour assurer la portabilité des programmes. Dans les quelques cas pour lesquels des fonctions de bibliothèques qui ne sont pas dans le standard C++ doivent être utilisées, nous ferons tous les efforts possibles pour utiliser des fonctions conformes POSIX. POSIX est une norme basée sur un effort de standardisation d'Unix qui inclut des fonctions qui dépassent la portée de la bibliothèque C++. Vous pouvez généralement espérer trouver des fonctions POSIX sur les plateformes Unix (en particulier, Linux), et souvent sous DOS/Windows. Par exemple, si vous utilisez le multithreading, vous partez d'autant mieux que vous utilisez la bibliothèque de thread POSIX parce que votre code sera alors plus facile à comprendre, porter et maintenir (et la bibliothèque de thread POSIX utilisera généralement simplement les possibilités de thread sous-jacentes du système d'exploitation, si elles existent).

Pour déclarer les fonctions et données externes de la classe iostream, incluez le fichier d'en-tête avec l'instruction

#include <iostream>

Le premier programme utilise le concept de sortie standard, qui signifie "un endroit universel pour envoyer la sortie". Vous verrez d'autres exemples utilisant la sortie standard de différentes façons, mais ici elle ira simplement sur la console. La bibliothèque iostream définit automatiquement une variable (un objet) appelée cout qui accepte toutes les données liées à la sortie standard.

Pour envoyer des données à la sortie standard, vous utilisez l'opérateur <<. Les programmeurs C connaissent cet opérateur comme celui du "décalage des bits à gauche", ce qui sera décrit dans le prochain chapitre. Ca suffit pour dire qu'un décalage des bits à gauche n'a rien à voir avec la sortie. Cependant, le C++ permet la surcharge des opérateurs. Quand vous surchargez un opérateur, vous donnez un nouveau sens à cet opérateur quand il est utilisé avec un objet d'un type donné. Avec les objets iostream, l'opérateur << signifie "envoyer à". Par exemple :

cout << "salut !";

envoie la chaîne de caractères "salut !" à l'objet appelé cout(qui est le raccourci de "console output" - sortie de la console)

Ca fait assez de surcharge d'opérateur pour commencer. Le chapitre 12 couvre la surcharge des opérateurs en détail.

Comme mentionné dans le chapitre 1, un des problèmes rencontré dans le langage C est que vous "épuisez les noms" pour les fonctions et les identifiants quand vos programmes atteignent une certaine taille. Bien sûr, vous n'épuisez pas vraiment les noms ; cependant, il devient difficile d'en trouver de nouveaux après un certain temps. Plus important, quand un programme atteint une certaine taille il est généralement coupé en morceaux, chacun étant construit et maintenu par une personne ou un groupe différent. Puisque le C n'a en réalité qu'un seul domaine où tous les identifiants et noms de fonction existent, cela signifie que tous les développeurs doivent faire attention à ne pas utiliser accidentellement les mêmes noms dans des situations où ils peuvent entrer en conflit. Cela devient rapidement fastidieux, chronophage, et, en fin de compte, cher.

Le Standard C++ contient un mécanisme pour éviter ces heurts : le mot-clé namespace. Chaque ensemble de définitions C++ d'une bibliothèque ou d'un programme est "enveloppé" dans un espace de nom, et si une autre définition a un nom identique, mais dans un espace de nom différent, alors il n'y a pas de conflit.

Les espaces de noms sont un outil pratique et utile, mais leur présence signifie que vous devez vous rendre compte de leur présence avant que vous ne puissiez écrire le moindre programme. Si vous incluez simplement un fichier d'en-tête et que vous utilisez des fonctions ou objets de cet en-tête, vous aurez probablement des erreurs bizarres quand vous essaierez de compiler le programme, dues au fait que le compilateur ne peut trouver aucune des déclarations des éléments dont vous avez justement inclus le fichier d'en-tête ! Après avoir vu ce message plusieurs fois, vous deviendrez familier avec sa signification (qui est "Vous avez inclus le fichier d'en-tête mais toutes les déclarations sont dans un espace de nom et vous n'avez pas signalé au compilateur que vous vouliez utiliser les déclarations de cet espace de nom").

Il y a un mot-clé qui vous permet de dire "Je veux utiliser les déclarations et/ou définitions de cet espace de nom". Ce mot-clé, de façon assez appropriée, est using(utiliser). Toutes les bibliothèques du Standard C++ sont enveloppées dans un espace de nom unique, std(pour "standard"). Puisque ce livre utilise presque exclusivement les bibliothèques standards, vous verrez la directive using dans presque tous les programmes :

using namespace std;

Cela signifie que vous voulez exposer tous les éléments de l'espace de nom appelé std. Après cette instruction, vous n'avez plus à vous préoccuper de l'appartenance à un espace de nom de votre composant particulier de bibliothèque, puisque la directive using rend cet espace de nom disponible tout au long du fichier où la directive using a été écrite.

Exposer tous les éléments d'un espace de nom après que quelqu'un ait pris la peine de les masquer peut paraître un peu contre-productif, et en fait vous devez faire attention à moins penser le faire (comme vous allez l'apprendre plus tard dans ce livre). Cependant, la directive using expose seulement ces noms pour le fichier en cours, donc ce n'est pas si drastique qu'on peut le croire à première vue. (Mais pensez-y à deux fois avant de le faire dans un fichier d'en-tête - c'est risqué.)

Il y a un rapport entre les espaces de nom et la façon dont les fichiers d'en-tête sont inclus. Avant que l'inclusion moderne des fichiers d'en-tête soit standardisée (sans la fin " .h", comme dans <iostream>), la méthode classique d'inclusion d'un fichier d'en-tête était avec le " .h", comme <iostream.h>. A ce moment là, les espaces de nom ne faisaient pas non plus partie du langage. Donc pour assurer la compatibilité ascendante avec le code existant, si vous dites

#include <iostream.h>

cela signifie

#include <iostream>
using namespace std;

Cependant, dans ce livre, le format d'inclusion standard sera utilisé (sans le " .h") et donc la directive using doit être explicite.

Pour l'instant, c'est tout ce que vous avez besoin de savoir sur les espaces de nom, mais dans le chapitre 10 le sujet est couvert plus en détail.

Un programme C ou C++ est une collection de variables, de définitions de fonctions, et d'appels de fonctions. Quand le programme démarre, il exécute un code d'initialisation et appelle une fonction spéciale, " main( )". Vous mettez le code basique du programme dedans.

Comme mentionné plus tôt, une définition de fonction consiste en un type de valeur de retour (qui doit être spécifié en C++), un nom de fonction, une liste d'arguments entre parenthèses, et le code de la fonction contenu dans des accolades. Voici un échantillon de définition de fonction :

int fonction() {
  // Code de la fonction (ceci est un commentaire)
}

La fonction ci-dessus a une liste d'arguments vide et son corps contient uniquement un commentaire.

Il peut y avoir de nombreuses paires d'accolades dans une définition de fonction, mais il doit toujours y en avoir au moins une paire entourant le corps de la fonction. Puisque main( ) est une fonction, elle doit respecter ces règles. En C++, main( ) a toujours le type de valeur de retour int.

Le C et le C++ sont des langages de forme libre. A de rares exceptions près, le compilateur ignore les retours à la ligne et les espaces, il doit donc avoir une certaine manière de déterminer la fin d'une instruction. Les instructions sont délimitées par les points-virgules.

Les commentaires C commencent avec /* et finissent avec */. Ils peuvent comprendre des retours à la ligne. Le C++ utilise les commentaires du style C et a un type de commentaire supplémentaire : //. // commence un commentaire qui se termine avec un retour à la ligne. C'est plus pratique que /* */ pour les commentaires d'une seule ligne, et c'est beaucoup utilisé dans ce livre.

Et maintenant, enfin, le premier programme :

//: C02:Hello.cpp
// Dire bonjour en C++
#include <iostream> // Déclaration des flux
using namespace std;
 
int main() {
  cout << "Bonjour tout le monde ! J'ai "
       << 8 << " ans aujourd'hui !" << endl;
} ///:~

L'objet cout reçoit une série d'arguments à travers les opérateurs " <<". Il écrit ces arguments dans l'ordre gauche-à-droite. La fonction de flux spéciale endl restitue la ligne et en crée une nouvelle. Avec les flux d'entrée/sortie, vous pouvez enchaîner une série d'arguments comme indiqué, ce qui rend la classe facile à utiliser.

En C, le texte entre guillemets doubles est classiquement appelé une "string" (chaîne de caractères). Cependant, la bibliothèque du Standard C++ contient une classe puissante appelée string pour manipuler le texte, et donc j'utiliserai le terme plus précis tableau de caractères pour le texte entre guillemets doubles.

Le compilateur crée un espace de stockage pour les tableaux de caractères et stocke l'équivalent ASCII de chaque caractère dans cet espace. Le compilateur termine automatiquement ce tableau de caractères par un espace supplémentaire contenant la valeur 0 pour indiquer la fin du tableau de caractères.

Dans un tableau de caractères, vous pouvez insérer des caractères spéciaux en utilisant des séquences d'échappement. Elles consistent en un antislash ( \) suivi par un code spécial. Par exemple, \n signifie "nouvelle ligne". Le manuel de votre compilateur ou un guide C local donne l'ensemble complet des séquences d'échappement ; d'autres incluent \t(tabulation), \\(antislash), et \b(retour arrière).

Notez que l'instruction peut continuer sur plusieurs lignes, et que l'instruction complète se termine avec un point-virgule.

Les arguments tableau de caractère et entier constant sont mêlés ensemble dans l'instruction cout ci-dessus. Comme l'opérateur << est surchargé avec diverses significations quand il est utilisé avec cout, vous pouvez envoyer à cout une gamme d'arguments différents et il "comprendra quoi faire avec le message".

Tout au long du livre vous noterez que la première ligne de chaque fichier sera un commentaire qui commence par les caractères qui annoncent un commentaire (classiquement //), suivis de deux points, et la dernière ligne du listing se terminera avec un commentaire suivi par " /:~". C'est une technique que j'utilise pour permettre une extraction simple de l'information des fichiers de code (le programme pour le faire peut être trouvé dans le Volume 2 de ce livre, sur www.BruceEckel.com). La première ligne contient aussi le nom et l'emplacement du fichier, il peut donc être cité dans le texte ou dans d'autres fichiers, et ainsi vous pouvez facilement le trouver dans le code source pour ce livre (qui est téléchargeable sur www.BruceEckel.com).

Après avoir téléchargé et décompressé le code source du livre, trouvez le programme dans le sous-répertoire CO2. Lancez le compilateur avec Hello.cpp en argument. Pour de simples programmes d'un fichier comme celui-ci, la plupart des compilateurs mèneront le processus à terme. Par exemple, pour utiliser le compilateur C++ GNU (qui est disponible gratuitement sur internet), vous écrivez :

g++ Hello.cpp

Les autres compilateurs auront une syntaxe similaire ; consultez la documentation de votre compilateur pour les détails.

Une fonctionnalité importante du processeur C est la concaténation de tableaux de caractères. Cette fonctionnalité est utilisée dans certains exemples de ce livre. Si deux tableaux de caractères entre guillemets sont adjacents, et qu'aucune ponctuation ne les sépare, le compilateur regroupera les tableaux de caractères ensemble dans un unique tableau de caractères. C'est particulièrement utile quand les listes de code ont des restrictions de largeur :

//: C02:Concat.cpp
// Concaténation de tableaux de caractères
#include <iostream>;
using namespace std;
 
int main() {
  cout << "C'est vraiment trop long pour être mis "
    "sur une seule ligne mais ça peut être séparé sans "
    "effet indésirable\ntant qu'il n'y a pas "
    "de ponctuation pour séparer les tableaux de caractères "
    "adjacents.\n";
} ///:~

A première vue, le code ci-dessus peut ressembler à une erreur puisqu'il n'y a pas le point-virgule familier à la fin de chaque ligne. Souvenez-vous que le C et le C++ sont des langages de forme libre, et bien que vous verrez habituellement un point-virgule à la fin de chaque ligne, le besoin actuel est d'un point virgule à la fin de chaque instruction, et il est possible qu'une instruction s'étende sur plusieurs lignes.

Les classes de flux d'entrée-sortie offrent la possibilité de lire des entrées. L'objet utilisé pour l'entrée standard est cin(pour "console input" - entrée de la console). cin attend normalement une entrée sur la console, mais cette entrée peut être redirigée à partir d'autres sources. Un exemple de redirection est montré plus loin dans ce chapitre.

L'opérateur de flux d'entrée-sortie utilisé avec cin est >>. Cet opérateur attend le même type d'entrée que son argument. Par exemple, si vous donnez un argument entier, il attend un entier de la console. Voici un exemple :

//: C02:Numconv.cpp
// Convertit une notation décimale en octale et hexadécimale
#include <iostream>
using namespace std;
 
int main() {
  int number;
  cout << "Entrez un nombre décimal : ";
  cin >> number;
  cout << "Valeur en octal = 0" 
       << oct << number << endl;
  cout << "Valeur en hexadécimal = 0x" 
       << hex << number << endl;
} ///:~

Ce programme convertit un nombre tapé par l'utilisateur dans ses représentations octales et hexadécimales.

Alors que la manière classique d'appeler un programme qui lit l'entrée standard et écrit sur la sortie standard est un script dans un shell Unix ou un fichier batch du DOS, tout programme peut être appelé à partir d'un programme C ou C++ en utilisant la fonction du Standard C system( ), qui est déclarée dans le fichier d'en-tête <cstdlib>:

//: C02:CallHello.cpp
// Appeler un autre programme
#include <cstdlib> // Déclare "system()"
using namespace std;
 
int main() {
  system("Hello");
} ///:~

Pour utiliser la fonction system( ), vous lui donnez un tableau de caractères que vous pouvez normalement taper en ligne de commandes du système d'exploitation. Il peut aussi comprendre des arguments de ligne de commande, et le tableau de caractères peut être construit à l'exécution (au lieu de simplement utiliser un tableau de caractères statique comme montré ci- dessus). La commande exécute et contrôle les retours du programme.

Ce programme vous montre à quel point il est facile d'utiliser des fonctions de la bibliothèque C ordinaire en C++ ; incluez simplement le fichier d'en-tête et appelez la fonction. Cette compatibilité ascendante du C au C++ est un grand avantage si vous apprenez le langage en commençant avec une expérience en C.