Pourquoi un paramètre const change-t-il mystérieusement de valeur ?

Voici la situation : vous avez implémenté une routine ou méthode avec un paramètre (appelé Param) déclaré const, et vous remarquez en pas-à-pas la chose suivante. Un appel à une autre routine/méthode, sans même passer Param en paramètre, modifie Param !

Voici l'explication rationnelle du problème (si si, il y en a une).

Avant de commencer, il est indispensable de mettre bien au clair la nature des paramètres const. En effet, c'est en raison de cette nature quelque peu particulière que se déclenche le « problème ».

Prenons en exemple la routine ci-dessous :

// TPoint est déclaré en Windows.pas
procedure WritePoint(Point : TPoint);
begin
  WriteLn(Point.X, ', ', Point.Y);
end;

Lors d'un appel à cette routine, le compilateur Delphi duplique la valeur du paramètre effectif dans un emplacement dédié, puis passe l'adresse de cet emplacement à la routine WritePoint. Pour un appel comme ça avec un point, qui ne contient jamais que 8 octets, ça n'est pas bien grave. Mais si l'on doit appeler 100 fois des routines en passant en paramètre des records de plusieurs dizaines d'octets, cela devient vite gênant.

C'est pourquoi le langage Pascal Objet propose les paramètres de type const, qui permettent d'optimiser les appels. Modifions l'en-tête de WritePoint pour utiliser un paramètre const :

procedure WritePoint(const Point : TPoint);

Du point de vue de l'intérieur de la méthode, le compilateur va générer des erreurs sur l'utilisation de Point de la même manière, et pour les mêmes raisons, que pour des utilisations litigieuses de constantes tout à fait classiques, à savoir : affectation à une constante, et passage en paramètre var/out d'une constante.

Cela permet d'être sûr qu'un appel à la méthode WritePoint ne modifiera pas Point, et par conséquent, on n'a plus besoin de dupliquer la valeur du paramètre effectif. On peut envoyer directement l'adresse originale.

Cela fait évidemment gagner énormément de temps. C'est pourquoi on privilégiera l'utilisation de paramètres const pour tous les paramètres de types chaînes, tableaux ou record, qui sont les seuls types à s'étendre sur un nombre variable (et donc potentiellement grand) d'octets.

L'explication est toute proche, maintenant que nous savons exactement comment est transmis un paramètre const. Il faut s'intéresser non pas au dedans de la routine, mais bien au-dehors.

Lorsque j'appelle WritePoint, je lui transmets donc l'adresse d'un TPoint. Et c'est à cette adresse - la même pour toute la durée de l'exécution de la routine - qu'est lue la valeur du paramètre.

Donc si, de quelque façon que ce soit, durant l'exécution de WritePoint, le contenu de la variable originale change, la valeur du paramètre changera en conséquence !

Mais comment diable cette variable pourrait-elle changer ? Nous allons voir dans la suite quatre cas de figure, dont trois avec le code.

IV-A. Des paramètres var et const pointant au même endroit▲

procedure AddPoints(var Point1 : TPoint; const Point2 : TPoint);
begin
  inc(Point1.X, Point2.X);
  inc(Point1.Y, Point2.Y);
  WriteLn('J''ai avancé de ', Point2.X, ' et monté de ', Point2.Y);
end;

procedure DoublePoint;
var MonPoint : TPoint;
begin
  ReadLn(MonPoint.X;
  ReadLn(MonPoint.Y);
  AddPoints(MonPoint, MonPoint);
  WriteLn('Résultat : ', MonPoint.X, ', ', MonPoint.Y);
end;

IV-B. Variable d'instance▲

type
  TMaClasse = class
  private
    FMonPoint : TPoint;
  public
    procedure DoSomething(const Point : TPoint);
    procedure AppelInitial;
  end;

implementation

procedure TMaClasse.DoSomething(const Point : TPoint);
begin
  WriteLn(Point.X, ', ', Point.Y);
  inc(FMonPoint.Y, 5);
  WriteLn(Point.X, ', ', Point.Y);
end;

procedure TMaClasse.AppelInitial;
begin
  DoSomething(FMonPoint);
end;

IV-C. Modification par sous-routine interposée▲

procedure TMaClasse.Bouge(X, Y : integer);
begin
  inc(FMonPoint.X, X);
  inc(FMonPoint.Y, Y);
end;

procedure TMaClasse.DoSomething(const Point : TPoint);
begin
  WriteLn(Point.X, ', ', Point.Y);
  Bouge(5, -10);
  WriteLn(Point.X, ', ', Point.Y);
end;

IV-D. Thread concurrent▲

Ce genre de cas a l'air très improbable comme ça, mais dans certaines applications complexes travaillant sur des records dans presque toutes les méthodes, avec donc des paramètres const partout pour optimiser, et des appels de call-back dans tous les sens, on peut y arriver.

L'exemple concret dans lequel je me suis moi-même retrouvé est malheureusement beaucoup trop complexe pour être expliqué ici. Mais vous pouvez savoir qu'il s'agit d'un cas de mon troisième exemple, à savoir la modification d'une variable d'instance dans une sous-méthode.
Comble de malheur, il s'agissait d'ailleurs d'un appel indirectement récursif à cette sous-méthode.

Mais alors, comment l'éviter ? Ou, si vous vous retrouvez dans la situation, comment contourner le problème ?

Il suffit de s'assurer qu'une routine/méthode à laquelle vous passez un paramètre const n'a aucun moyen d'obtenir d'une autre façon l'adresse de la variable transmise. Cela peut être fait notamment en copiant le contenu de la variable dans une variable locale, laquelle sera ensuite transmise.

Bien entendu, il ne faut faire cela que dans les cas litigieux que nous venons d'expliquer. Si vous copiez systématiquement tout paramètre const avant de le transmettre, vous perdez tout le bénéfice de ce système (éviter la copie justement).