Une référence est un alias, un nom alternatif pour un objet. Le principe à retenir est que tout se passe comme si c'était l'objet lui-même et non une référence sur lui.

Les références sont souvent utilisées lors du passage de paramètres, en particulier avec le mot-clé const (référence constante : donc le paramètre passé est non modifiable) afin de rendre l'appel à la fonction plus performant sur des objets volumineux. Sans le mot-clé const l'usage d'une référence indique alors que le paramètre est modifié par la fonction.

// fonction qui échange i et j
void swap(int& i, int& j)
{
    int tmp = i;
    i = j;
    j = tmp;
}
 
int main()
{
    int x = 1;
    int y = 2;
    swap( x, y );
    // x = 2, y = 1
}

Dans cet exemple, i et j sont des alias pour x et y du main. En d'autres mots, i est x (pas un pointeur sur x, ni une copie, mais x lui-même). Tout ce qui est fait à x est fait à i et inversement.

Bon, maintenant, pensons aux références du point de vue du programmeur. Au risque de provoquer la confusion en donnant une autre perspective voici comment les références sont implémentées en pratique. Au fond, une référence i vers un objet x est habituellement son adresse. Mais quand le programmeur fait un i++, le compilateur génère du code qui incrémente x. Typiquement, les bits d'adressage que le compilateur utilise pour accéder à x sont inchangés. Un programmeur C pensera qu'il s'agit du passage d'un pointeur, avec les variantes syntaxiques suivantes :

• Déplacer le & de l'appelant à l'appelé
• Supprimer les notations *s

En d'autres mots, un programmeur le considérera comme une macro pour (*p), où p est un pointeur sur x (par ex., le compilateur déréférencerait automatiquement le pointeur : i++ serait transformé en (*p)++).

Note : même si une référence est souvent implémentée en utilisant une adresse dans le langage d'assemblage généré, ne considérez pas les références comme un pointeur "marrant" sur un objet. Une référence est l'objet. Ce n'est pas un pointeur sur l'objet, ni une copie de l'objet. C'est l'objet.

L'état du référent (le référent est l'objet auquel la référence se rapporte) est modifié.

Le référent est la référence, donc toute modification faite à la référence est faite au référent. Au niveau du compilateur, une référence est une "lvalue", c'est-à-dire qu'il peut apparaître à la gauche d'un opérateur d'affectation.

L'appel de fonction peut se trouver à la gauche d'un opérateur d'assignation.

Cette possibilité peut sembler étrange au premier abord. Par exemple, personne ne penserait que l'expression

f() = 7;

ait un sens. Par contre, si a est un objet de la classe Array, la plupart des gens trouveront que

a[i] = 7;

a un sens, même si a n'est qu'un appel de fonction caché (c'est en fait l'appel de l'opérateur Array::operator [](int), qui est l'opérateur d'indexation de la classe Array)

class Array {
 public:
   int size() const;
   float& operator[] (int index);
   ...
 };
 
 int main()
 {
   Array a;
   for (int i = 0; i < a.size(); ++i)
     a[i] = 7;    // cette ligne appelle Array::operator[](int)
   ...
 }

Ce n'est pas possible.

On ne peut pas séparer le référé de sa référence.

Contrairement aux pointeurs, lorsqu'une référence est liée à un objet, elle ne peut pas être réaffectée à un autre objet. La référence en elle-même n'est pas un objet (elle n'a pas d'identité : prendre l'adresse d'une référence retourne l'adresse du référent).

De ce point de vue, une référence est similaire à un pointeur constant

int* const p

par opposition à un pointeur sur une constante

const int* p

En dépit d'une certaine ressemblance, ne confondez pas les références et les pointeurs ; ce n'est pas du tout la même chose.

Utilisez les références aussi souvent que possible, et les pointeurs quand vous le devez.

Les références sont habituellement préférables aux pointeurs, à moins que vous ne deviez la réallouer à un moment donné. Cela veut dire que les références sont plus utiles dans les interfaces publiques des classes. Les références apparaissent typiquement dans les interfaces, alors que les pointeurs sont utilisés à l'intérieur.

Exception à ce qui vient d'être dit : lorsqu'un paramètre ou la valeur de retour d'une fonction a besoin d'une référence "sentinelle". Ceci est habituellement mieux fait en retournant ou recevant un pointeur et en donnant à NULL cette signification particulière. Les références devraient toujours désigner un objet et jamais un pointeur NULL déréférencé).

Note : les vieux programmeurs C n'apprécient pas d'utiliser des références étant donné qu'elles attribuent une sémantique à la référence qui n'est pas claire dans le code appelant. Mais, après une certaine pratique du C++, certains réalisent qu'il s'agit d'une forme de masquage d'information, ce qui est plus un bien qu'un défaut.
Par ex. : les programmeurs devraient écrire le code dans le langage du problème plutôt que dans le langage de la machine.

le terme handle est utilisé pour désigner n'importe quelle technique qui permet de manipuler un autre objet (un genre de pseudo pointeur généralisé). Ce terme est (volontairement) ambigu et peu précis.

L'ambiguïté est un avantage dans certains cas. Par exemple, au tout début du design vous ne serez peut-être pas prêt à adopter une représentation spécifique pour désigner les handles. Vous ne serez peut-être pas sûr du choix à faire entre les simples pointeurs, les références, les pointeurs de pointeurs, les références de pointeurs, ou encore des tableaux indicés, ou des tables de hachage, ou des bases de données ou n'importe quelle autre technique. Si vous savez que vous aurez besoin de quelque chose qui identifiera de façon unique un objet, appelez cette chose un handle.

Si votre but final est de permettre à une portion de code d'identifier/rechercher un objet spécifique d'une classe d'un certain type (par ex. Fred), vous devrez passer un handle sur Fred à cette portion de code. Le handle peut être une chaîne qui peut-être utilisée comme une clé dans une table de recherche bien connue. Par exemple, une clé dans

std::map<std::string,Fred>

ou

std::map<std::string,Fred*>

ou encore un entier qui sera un indice dans un tableau du genre

Fred* array = new Fred[maxNumFreds]

ou tout simplement un pointeur sur Fred, ou n'importe quoi d'autre.

Les débutants pensent souvent en termes de pointeurs, mais en réalité, ils prennent un risque. Que se passe-t-il si l'objet Fred doit être déplacé ? Comment savoir quand il est sans risque d'effacer l'objet Fred ? Que se passe-t-il si l'objet doit être sérialisé ? .... La plupart du temps, on aura tendance à ajouter de plus en plus de couches d'indirections pour gérer ces cas de figure. Par exemple, le handle sur Fred devrait être un Fred**, où le pointeur pointant sur Fred* est supposé ne jamais être déplacé, mais à un moment le pointeur doit être déplacé, on met seulement à jour le pointeur sur Fred*. Ou vous décidez que le handle devient un entier désignant l'objet Fred dans une table, etc.....

Le fait est que nous utilisons le mot handle tant que nous ne savons pas le détail de ce que nous allons faire.

Une autre circonstance dans laquelle nous utilisons le mot handle est quand on préfère rester vague au sujet de ce que nous avons déjà fait (on utilise parfois le terme 'cookie' pour cela, par ex. "Le programme passe un cookie qui est utilisé pour identifier de façon unique l'objet Fred adéquat"). La raison pour laquelle nous voulons (parfois) rester vague est de minimiser les effets de bord si les détails d'implémentations devaient changer. Par exemple, si quelqu'un change le handle qui était une chaîne qui servait à faire une recherche dans une liste de hachage en un entier qui sert à indicer une table, cela pourrait causer le changement de dizaines de milliers de lignes de code.

Pour faciliter la maintenance quand les détails de représentation d'un handle changent (ou tout simplement pour rendre le code plus lisible), nous encapsulerons le handle dans une classe. Cette classe surchargera souvent les opérateurs -> et * (comme le handle agit comme un pointeur, il semble logique qu'il ressemble à un pointeur).