Discussion :

[e-ric]

Salut à tous

Je vous expose une petite recherche personnelle.

Pour reprendre le paragraphe Extension proposée du Wiki FPC ajouté par Gilles, je suggère une solution employant un énumérateur (dit aussi itérateur) générique. L'idée m'est venue en voulant décomposer une chaîne contenant des sous-chaînes séparées par des ';' (une ligne de fichier csv pour tout dire) en vue de proposer une alternative à l'emploi d'une TStringList.

La solution étant basée sur la généricité, l'énumérateur générique est récupérable pour d'autres usages, par exemple pour parcourir une liste chaînée en simulant un indice qui ne serait pas disponible directement dans l'interface de la liste elle-même. Le code est relativement simple mais appelle quelques explications.

La documentation standard sur les génériques est plutôt réduite et les énumérateurs n'y apparaissent même pas, seuls quelques paragraphes sont disponibles dans le Wiki. Ce qui est dommage car cela n'encourage pas l'emploi de ces mécanismes modernes et fort utiles. En outre, l'implémentation que je propose met en jeu aussi une type interne.

Un énumérateur (ou itérateur) permet d'accéder à une suite d'éléments depuis un structure conteneur (par exemple les éléments d'un tableau) via la boucle for..in.
Cependant si nous voulons un indice sur ces données, il faut déclarer et incrémenter une variable entière supplémentaire car la construction for..in n'expose pas un tel indice. Ma solution consiste à embarquer dans l'itérateur la gestion de l'indice et d'en permettre l'accès. Bon montrons le code ce sera plus parlant.

Déclaration du type générique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
generic TGIndicedEnumerator<TContainer, TElement> = class
public type
  TIndicedValue = record
    Value: TElement;
    Ind: Integer;
  end;
protected
  FCntnr: TContainer;
  FCurrent: TIndicedValue;
public
  constructor Create(aCntnr: TContainer); virtual;
  function MoveNext: Boolean; virtual; abstract;
  property Current: TIndicedValue read FCurrent;
  function GetEnumerator: TGIndicedEnumerator;
end;

Spécialisation et dérivation du type générique pour notre exemple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
TCsvAnsiStringFieldEnumerator = class(specialize TGIndicedEnumerator<AnsiString, AnsiString>)
private
  FCurrPos: Integer;
  FSeparator: Char;
public
  // On introduit ici la notion de séparateur.
  constructor Create(aString: AnsiString; Separator: AnsiChar); overload;
  function MoveNext: Boolean; override;
end;

L'implémentation des types est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
{ TGIndicedEnumerator }
 
constructor TGIndicedEnumerator.Create(aCntnr: TContainer);
begin
  FCntnr := aCntnr;
end;
 
function TGIndicedEnumerator.GetEnumerator: TGIndicedEnumerator;
begin
  Result := Self;
end;
 
{ TCsvAnsiStringFieldEnumerator }
 
constructor TCsvAnsiStringFieldEnumerator.Create(aString: AnsiString; Separator: AnsiChar);
begin
  inherited Create(aString);
  FCurrPos := 0;
  FSeparator := Separator;
  FCurrent.Ind := -1;
end;
 
function TCsvAnsiStringFieldEnumerator.MoveNext: Boolean;
begin
  if FCurrPos > Length(FCntnr) then exit(False);
  // Premier élément
  Inc(FCurrent.ind);
  FCurrent.Value := '';
  Inc(FCurrPos);
  while (FCurrPos <= Length(FCntnr)) and (FCntnr[FCurrPos] <> FSeparator) do
  begin
    FCurrent.Value += FCntnr[FCurrPos];
    Inc(FCurrPos);
  end;
  Result := True;
end;

Le type générique reprend les méthodes et proriétés nécessaires à la mise en oeuvre de l'énumérateur (MoveNext, Current), j'ai ajouté GetEnumerator car l'énumérateur servira aussi de conteneur en quelque sorte.
Les marques substitutives TContainer et TElement ne sont pas encore des types, les types effectifs seront précisés lors de la spécialisation (mot-clé specialize).

Le type TIndicedValue qui définit la paire (Valeur, Indice) est interne à la classe générique afin de bénéficier des mêmes identificateurs de types génériques et aussi pour être sûr que les types sont identiques après spécialisation.

En fait, le plus surprenant (pour moi) a été que la méthode GetEnumerator: TGIndicedEnumerator; change correctement de type de retour après la spécialisation (i.e. ce dernier devient TCsvAnsiStringFieldEnumerator), je pensais que cette opération ne s'intéressait qu'aux marques substitutives, c'est une excellente nouvelle sinon ma conception initiale aurait été remise en question, il aurait fallu créer cette méthode dans les types dérivés, accroissant le code à écrire. L'ajout de cette méthode est nécessaire car l'itérateur est obtenu directement depuis l'objet itérateur lui-même.

Le code de décomposition d'une chaîne devient très simple, l'indice permet de savoir quelle composante de la chaîne on manipule (la première d'incide 0, la suivante d'indice 1...). Il se ramène à une simple boucle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#!/usr/bin/instantfpc
 
// pour emploi avec instantfpc, 
// remplacer la première ligne par "program TestCsv;" si vous n'utilisez pas InstantFPC.
 
{$mode objfpc}{$H+}
 
uses
  SysUtils,
  IndicedEnumerators;  
 
var
  IndStr: TCsvAnsiStringFieldEnumerator.TIndicedValue;
 
begin
  for IndStr in TCsvAnsiStringFieldEnumerator.Create(ParamStr(1),';') do
    WriteLn(Format('%d : "%s"', [IndStr.Ind, IndStr.Value]));
end.

Le type de la variable IndStr est TIndicedValue mais qualifié par le type spécialisé, l'ensemble constitue donc aussi un type particulier à part entière.

Exemple d'appel en ligne de commande (nom du fichier source pascal avec des droit d'exécution sous Linux + un paramètre)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
./TestStringFieldEnums.pas "petit;programme;pascal;pour;faire;un;test"

Laissez un commentaire si cela est difficile à faire sous Windows, on verra ce qu'on peut faire.

Voilà, j'espère vous avoir exposé quelque chose d'utile, intéressant et compréhensible.

Qu'en pensez-vous ?

NB : pour les administrateurs : les mots-clés generic et specialize ne sont pas mis en évidence comme les autres mots-clés, pouvez-vous corriger cela dans le site ?

[gvasseur58]

Bonsoir,

La discussion que tu as ouverte m'intéresse vraiment beaucoup. En effet, j'ai en projet un tutoriel sur les génériques (c'est le numéro 3 d'une nouvelle série POO à gogo en gestation), mais le traitement d'un indice est une excellente idée à laquelle je n'avais pas pensé .
Je vais tester très rapidement ton code...

PS : je vais voir pour generic et specialize.

[e-ric]

Salut

Content que cela t'intéresse. Concernant ton tutoriel, je te souhaite bon courage car la doc de FPC (référence + Wiki) n'est pas faramineuse sur ces sujets (en tout cas sur les énumérateurs, c'est quasi nul).
Si je peux apporter encore quelques éclairages, ce sera avec plaisir.

Le test du code ne devrait pas te poser trop de problème. Je souligne le fait que dans mon exemple la spécialisation et la dérivation sont réalisées simultanément, ce qui n'est pas nécessairement la meilleure solution, je l'ai privilégiée par souci de concision.

Un des problèmes ennuyeux à gérer avec la généricité dans FPC est qu'il sépare nettement, que dis-je c'est une fosse abyssale, les classes et les types simples car leur gestion de la mémoire est différente, ce qui rend passablement compliquée la mise en oeuvre de ce mécanisme (p.ex. une pile toute bête), et encore l'ajout récent, car réclamé haut et fort, de la fonction intrinsèque Default lève quelques problèmes.

Eiffel ne fait pas cette distinction, ce qui facilite et encourage grandement l'emploi de la généricité. En outre, un ramasse-miette apporterait une grande simplification dans l'écriture des classes et de leur code client. Eiffel montre que tout cela n'est pas incompatible avec un typage fort et statique, comme en Pascal.

Cdlt

PS : je pense compléter le Wiki FPC/fr avec cet exemple, autant que tout le monde en profite...

[e-ric]

Salut Gilles,

Toujours au sujet des extensions proposées, tu évoques la possibilité de traverse à l'envers (équivalent au downto). J'avoue ne pas voir comment le compilateur pourrait s'y prendre pour automatiser cela. En effet, il suffit de penser à une liste simplement chaînée pour se rendre compte que la solution n'est pas aisée. Une solution plus simple consiste à créer un énumérateur dédié.

Dans Python, c'est supporté en standard mais les concepts de Python sont bien éloignés de ceux de Pascal, le concept d'itérateur y est fondamental. Il serait bien d'intégrer dans Pascal certains concepts de Python, comme les générateurs par exemple ou l'héritage multiple). J'avoue trouver ce langage beaucoup plus confortable à programmer que Pascal mais le typage statique de ce dernier demeure un atout important.

Cdlt

[e-ric]

Salut

Le Wiki est modifié.

Cdlt

[gvasseur58]

Bonjour Eric,

Content que cela t'intéresse. Concernant ton tutoriel, je te souhaite bon courage car la doc de FPC (référence + Wiki) n'est pas faramineuse sur ces sujets (en tout cas sur les énumérateurs, c'est quasi nul). Si je peux apporter encore quelques éclairages, ce sera avec plaisir.

Effectivement, la documentation actuelle est faible, mais j'ai vu que tu l'avais enrichie . C'est avec grand plaisir que j'accepte ta proposition, mais, pour le moment, je tiens le tutoriel prévu de côté, car la version 3.0.0 de Free Pascal contient encore plusieurs bogues majeurs concernant les génériques. Depuis, ils ont été corrigés, mais le Lazarus stable n'a pas encore intégré ces corrections : je n'ai pas envie d'être submergé de questions pour des erreurs qui se produiraient à cause de cela .

Un des problèmes ennuyeux à gérer avec la généricité dans FPC est qu'il sépare nettement, que dis-je c'est une fosse abyssale, les classes et les types simples car leur gestion de la mémoire est différente, ce qui rend passablement compliquée la mise en œuvre de ce mécanisme (p.ex. une pile toute bête), et encore l'ajout récent, car réclamé haut et fort, de la fonction intrinsèque Default lève quelques problèmes. Eiffel ne fait pas cette distinction, ce qui facilite et encourage grandement l'emploi de la généricité. En outre, un ramasse-miette apporterait une grande simplification dans l'écriture des classes et de leur code client. Eiffel montre que tout cela n'est pas incompatible avec un typage fort et statique, comme en Pascal.

Ton exposé est intéressant, mais discutable. Au moins, avec Pascal, le programmeur dispose de trois grandes options pour la gestion de la mémoire :

• la création et la destruction explicites (avec Create/Free encadrés par des Try...Finally) ;
• la création suivie d'une destruction automatique avec les descendants de TComponent ;
• le comptage de références avec les interfaces (ARC).

Si la dernière est celle qui paraît avoir le plus d'avenir, les deux autres sont fort utiles en de nombreuses circonstances. L'ensemble peut paraître complexe, mais la puissance est au rendez-vous entre l'utilisation de la pile et celle du tas, par exemple. Rapprocher les types simples des classes reviendrait à instancier directement les classes (comme en C++), mais cette technique oblige à manipuler des pointeurs dès qu'une certaine maîtrise du temps de vie d'un objet est requise. Le modèle choisi par Delphi (et par conséquent Free Pascal) est différent et ressemble étrangement à celui du C# : chaque instance d'une classe contient non pas la valeur réelle associée, mais une référence (un pointeur sur la pile) à cette valeur (sur le tas). Tu as raison de dire que le mécanisme complique un peu les choses dans certains domaines, mais il les simplifie grandement dans l'ensemble et surtout apporte, à mon avis, beaucoup de souplesse et de puissance (ou alors Java et C# sont sur de mauvaises voies ).
Ne connaissant pas Eiffel, je ne me prononcerai pas, mais je serai attentif aux arguments le concernant. En particulier, je ne sais pas comment ce langage gère la mémoire .

Pour le moment, Lazarus n'a pas atteint la puissance de Delphi pour ce qui est de la généricité. Cependant, les progrès sont importants et il existe des bibliothèques à découvrir pour ceux qui ne les connaissent pas (je pense tout de suite à generics.collections).

Cordialement,

Gilles

[e-ric]

Salut

Avant tout, je rappelle que je reste un fan de Pascal mais cela n'interdit pas d'avoir un regard critique et de de percevoir ses limites. je ne remercierai jamais assez les développeurs de FPC/Lazarus pour la qualité de leur travail.

Effectivement, la documentation actuelle est faible, mais j'ai vu que tu l'avais enrichie . C'est avec grand plaisir que j'accepte ta proposition, mais, pour le moment, je tiens le tutoriel prévu de côté, car la version 3.0.0 de Free Pascal contient encore plusieurs bogues majeurs concernant les génériques. Depuis, ils ont été corrigés, mais le Lazarus stable n'a pas encore intégré ces corrections : je n'ai pas envie d'être submergé de questions pour des erreurs qui se produiraient à cause de cela .

J'ai consulté le bugtacker de FPC rapidement, je n'ai pas vu de postes concernant la généricité, quels sont les bugs actuels ?

Ton exposé est intéressant, mais discutable. Au moins, avec Pascal, le programmeur dispose de trois grandes options pour la gestion de la mémoire :

• la création et la destruction explicites (avec Create/Free encadrés par des Try...Finally) ;
• la création suivie d'une destruction automatique avec les descendants de TComponent ;
• le comptage de références avec les interfaces (ARC).

Je ne suis pas sûr que cela soit toujours un avantage, au contraire cela montre un certaine dispersion et peut contraindre le développeur à faire de mauvais choix (s'appuyer à tort par exemple sur la destruction 'automatique' de la classe TComponent pour créer de nouvelles classes qui n'ont rien à voir avec TComponent). La classe TComponent si elle rend de nombreux services démontre bien l'inexistence d'un réelle composition des objets, car seule la sémantique de référence est mise en oeuvre. Ce défaut originel complique le développement des classes et a permis la naissance de bien des bugs, mon expérience dans la maintenance me l'a montré à maintes reprises, où j'ai aussi constaté avec effroi que certains développeurs ne distinguent pas une relation d'association de celle de composition, et pas seulement en Delphi, je l'ai vu aussi dans du code Java (où tout est soit-disant objet, laissez-moi rire). Un risque patent est l'emploi de Free sur un objet censé en composer un autre, c'est toujours possible et pour pallier cela, il faut soit employer un dérivé de TComponent, ce qui impose un choix de conception dès le départ, l'héritage étant simple, soit tout recoder soit-même pour gérer correctement ce genre de situation et le lien entre la classe propriétaire et la classe composant.

Le comptage des références n'est pas forcément le meilleur moyen de vérifier qu'un objet peut ou non être libéré, il faudrait que je retrouve un exemple à ce sujet. En outre, j'ai toujours été très méfiant au sujet des interfaces qui ne sont qu'un béquille pour singer l'héritage multiple et demande à chaque dérivation de tout ré-implémenter. Ce qui à mon avis est un comble en POO.

Si la dernière est celle qui paraît avoir le plus d'avenir, les deux autres sont fort utiles en de nombreuses circonstances. L'ensemble peut paraître complexe, mais la puissance est au rendez-vous entre l'utilisation de la pile et celle du tas, par exemple. Rapprocher les types simples des classes reviendrait à instancier directement les classes (comme en C++), mais cette technique oblige à manipuler des pointeurs dès qu'une certaine maîtrise du temps de vie d'un objet est requise. Le modèle choisi par Delphi (et par conséquent Free Pascal) est différent et ressemble étrangement à celui du C# : chaque instance d'une classe contient non pas la valeur réelle associée, mais une référence (un pointeur sur la pile) à cette valeur (sur le tas). Tu as raison de dire que le mécanisme complique un peu les choses dans certains domaines, mais il les simplifie grandement dans l'ensemble et surtout apporte, à mon avis, beaucoup de souplesse et de puissance (ou alors Java et C# sont sur de mauvaises voies ).
Ne connaissant pas Eiffel, je ne me prononcerai pas, mais je serai attentif aux arguments le concernant. En particulier, je ne sais pas comment ce langage gère la mémoire .

Qui dit que manipuler des objets et des classes sous-tend l'utilisation de pointeurs/référence ? C'est une limitation originelle de Delphi et de FPC, un choix de conception. Par ailleurs, le fait de retrouver la même conception dans C# n'est pas une surprise, connaissant son géniteur.
La puissance de langage comme Delphi/FPC est indéniable. Mais ce qui a été simplifié avec la gestion des exceptions a, à mon sens, été perdu avec la gestion explicite de la mémoire. Il suffit d'instancier successivement une dizaine d'objets dans un morceau de code pour se rendre compte que l'écriture des différents blocs try..finally rend la lecture du code obtenu un plus lourde. A titre de comparaison, il suffit d'écrire un programme en Python et un autre en FPC pour se rendre compte des lourdeurs de ce dernier.

Pour le moment, Lazarus n'a pas atteint la puissance de Delphi pour ce qui est de la généricité. Cependant, les progrès sont importants et il existe des bibliothèques à découvrir pour ceux qui ne les connaissent pas (je pense tout de suite à generics.collections).

J'ai survolé le code de la FGL, tout cela est bien confus, la conception manque de clarté. Je ne me suis pas trop intéressé à Delphi (trop cher, ne fonctionne pas sous Linux et hors de ma mission actuelle), que manque-t'il à FPC pour combler son retard sur Delphi ?

As-tu pu tester mon code ? qu'en penses-tu ?

Cdlt

[gvasseur58]

Re-bonjour Eric,

Avant tout, je rappelle que je reste un fan de Pascal mais cela n'interdit pas d'avoir un regard critique et de de percevoir ses limites. je ne remercierai jamais assez les développeurs de FPC/Lazarus pour la qualité de leur travail.

Tout pareil pour moi

J'ai consulté le bugtacker de FPC rapidement, je n'ai pas vu de postes concernant la généricité, quels sont les bugs actuels ?

Je parlais de bogues encore présents dans la version 3.0.0. Tu peux consulter ces fils :

• Class operators for generics.
  (r34526 ; #30534)
• Patch for "Compilation raised exception internally" for wrong generic constraint.
  (r34381 ; #30494)
• Generics.Collections as part of FPC RTL.
  (r34229 ; #27206 ; v1.0.7 ; rv1.0.12)

Le dernier répond en partie à ta question concernant les manques de FPC par rapport à Delphi.

Je ne suis pas sûr que cela soit toujours un avantage, au contraire cela montre un certaine dispersion et peut contraindre le développeur à faire de mauvais choix (s'appuyer à tort par exemple sur la destruction 'automatique' de la classe TComponent pour créer de nouvelles classes qui n'ont rien à voir avec TComponent).

Entièrement d'accord. Mais le principe est simple : ce que je gagne d'un côté, je le perds de l'autre . Ainsi, bien que conscient que l'ARC a permis élégamment de régler certains problèmes d'allocation de la mémoire, je constate que son emploi est très délicat et conduit à des erreurs très délicates elles aussi (dont la célèbre circularité).

Le comptage des références n'est pas forcément le meilleur moyen de vérifier qu'un objet peut ou non être libéré, il faudrait que je retrouve un exemple à ce sujet. En outre, j'ai toujours été très méfiant au sujet des interfaces qui ne sont qu'un béquille pour singer l'héritage multiple et demande à chaque dérivation de tout ré-implémenter. Ce qui à mon avis est un comble en POO.

Entièrement d'accord aussi. Encore une fois, sur le papier, les interfaces sont extraordinaires, mais je constate qu'elles conduisent à des complications inutiles et à des aberrations. [Si Nick Hodges lit ceci, il va nous injurier, lui qui s'est fait l'apôtre de l'utilisation des interfaces à tout va].

Qui dit que manipuler des objets et des classes sous-tend l'utilisation de pointeurs/référence ? C'est une limitation originelle de Delphi et de FPC, un choix de conception.

Il ne me semble pas avoir dit le contraire. Je faisais remarquer que Delphi ou FPC ne sont pas les seuls à avoir fait ce choix... et qu'il ne doit pas être si limitant que ça. En tout cas, il évite bien des contorsions genre C++ (cela dit, vu ce qui a été et est toujours produit avec le C++, je n'engagerai pas de débat sur les avantages et inconvénients de chacun ).

A titre de comparaison, il suffit d'écrire un programme en Python et un autre en FPC pour se rendre compte des lourdeurs de ce dernier.

Je ne me lancerai pas non plus dans une comparaison de ce genre. Python est mille fois plus léger, j'en conviens, mais je ne crois pas avoir vu pires programmes (sauf peut-être en PHP ou JavaScript ) que certaines productions en Python. Loin d'être un spécialiste de ce langage, j'ai constaté sa lenteur, son incapacité à travailler au plus près de la machine (quid du threading, par exemple ?)... Je ne suis pas non plus un spécialiste de Python, mais il me semble qu'il a ses défauts lui aussi (et ils ne sont pas anodins).

Le problème que je vois à l'usage des try... finally est moins la difficulté à relire le texte que son caractère trompeur : si tu regardes bien les codes produits, tu verras que de nombreux programmeurs Pascal ne les utilisent tout simplement jamais : c'est sûr, le code est allégé, mais à quel prix .

As-tu pu tester mon code ? qu'en penses-tu ?

Je n'ai fait que le regarder pour le moment (et je le trouve intéressant) : j'aurai du temps ce week-end

Cordialement,

Gilles