Discussion :

[ALT]

Bonjour à tous

Quand je compile ceci (qui vient d'une unité Delphi, mais bon) :

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
type
  THPpile = class
  private
         Mem: extended;
         LastX: extended;
         pile: array[0..3] of extended;
         Mode: integer;
 ...
  public
        function x: string;
        function y: string;
        function z: string;
        function t: string;
        function m: string;
        procedure SetX(x: extended);
        procedure push(x: extended);
...
        procedure divide;
        procedure pow;
        procedure chgsgn;
        procedure Settings (m,d:integer);
        procedure invert;
        function YEnCours:extended;
  end;

j'ai un message d'erreur : duplicate identifier x (sur la ligne procedure SetX, ainsi que sur toutes celles qui sont sur le même modèle).
J'ai la même erreur pour m, aussi !
La portée des variables n'est-elle pourtant pas la même qu'en Pascal ?

D'autre part, j'ai cru (hum !) remarquer que dès que le nombre d'objets dans une fenêtre dépassait la quinzaine, on ne pouvait plus en ajouter :

• soit je l'ajoute graphiquement, mais il n'apparaît pas dans le code, donc je ne peux pas le renommer, lui attribuer une méthode...
• soit je l'ajoute à la main dans le code, mais il n'apparaît pas graphiquement
• soit j'essaye les deux à la fois & il me déclare qu'un objet du même nom existe déjà.

Je précise que j'ai essayé ça plusieurs fois (sur des projets différents).
Y a-t-il un remède à ceci, ou est-ce un bug de Lazarus ?

Merci d'avance de vos réponses.

[Clandestino]

Pour ce qui est du duplicate identifier: ce n'est pas un problème de portée, mais plus le fait que tu utilises le meme nom pour une variable et une fonction ...

Je viens de créer une fenetre avec 22 boutons, 7 memos et 4 labels sans le moindre soucis...

[ALT]

Euh...

Pour ce qui est du duplicate identifier: ce n'est pas un problème de portée, mais plus le fait que tu utilises le meme nom pour une variable et une fonction ...

Hum...

1. La déclaration d'un paramètre de fonction, jusqu'à preuve du contraire, n'empêche pas d'avoir une autre variable ou une fonction du même nom dans le module père.
2. Cette unité se compilait sans souci avec Delphi 4 & Kylix...

Je viens de créer une fenetre avec 22 boutons, 7 memos et 4 labels sans le moindre soucis...

Aïe ! Ça semblerait confirmer mes craintes : un pb dans ma config.
Là, ça va être plus dur à diagnostiquer, donc à traiter.
Accessoirement, ça expliquerait peut-être le pb ci-dessus.

Conclusion, je suis toujours preneur de vos bonnes idées.
Merci d'avance.

[Clandestino]

C'est pourtant bien cette erreur que te signale freepascal...
Renomme ta fonction pour t'en convaincre...

Delphi, par contre, compile ton code sans problème... Voilà une différence notable entre les deux compilateurs...

[thewho]

Bonjour,

C'est pourtant bien cette erreur que te signale freepascal...
Renomme ta fonction pour t'en convaincre...

Delphi, par contre, compile ton code sans problème... Voilà une différence notable entre les deux compilateurs...

Différence effectivement notable, et surtout, qui montre que FreePascal ne respecte pas le standard Pascal, tel qu'il a été clairement défini dès l'origine par Jansen et Wirth.

C'est d'ailleurs commun à tous les langages que je connais : le nom d'un argument passé à une fonction est strictement local à cette fonction, et ne doit donc pas interférer avec toute définition hors de la fonction utilisant le même nom.

Pas de doute, c'est un joli bug, bien costaud.

[Alcatîz]

C'est pourtant bien cette erreur que te signale freepascal...
Renomme ta fonction pour t'en convaincre...

Delphi, par contre, compile ton code sans problème... Voilà une différence notable entre les deux compilateurs...

@ALT : Est-ce que tu as activé la compatibilité avec Delphi dans les options de compilation ?

[Clandestino]

J'ai fait le test en cochant la case dans Lazarus, avant de répondre...
celà ne fonctionnait pas.
Puis, pris par le doute, j'ai recompilé un bout de code manuellement, en utilisant le compilateur fpc 2.0.4 fournit avec lazarus, en ligne de commande, avec l'option -Sd (compatibilité Delphi), et dans ce cas, freepascal est tout à fait d'accord avec ce bout de code (pour peu qu'on satisfasse les "forward declarations"...)

Le bug semble propre à lazarus et pas à freepascal...
Je suppose que certaines des options cochées pour le compilateur via l'interface, ne fonctionnent pas...