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...

[thewho]

Bonjour,

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...

J'ai de la peine à croire que l'utilisation de lazarus, quelle que soient les options choisies, entraîne cette erreur pour freepascal, car ça le sort complètement du travail normal d'un compilateur Pascal.

J'ose espérer que ce n'est pas une option prévue par freepascal, car sinon il faudra garder le cerveau du concepteur après sa mort, pour vérifier comment il est fait : je conçois parfaitement des options pour modifier le comportement d'un compilateur, pour gérer par exemple des optimisations, ou des extensions non prévues par la définition du langage, mais pas du tout une option lui permettant de détruire le comportement normal du compilateur, concernant la définition standard du langage utilisé.

[Clandestino]

voici les resultats des compilations manuelles :

en lançant le compilateur sans paramètre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
C:\lazarus\fpc\2.0.4\bin\i386-win32>fpc c:\verytemp\test.pas
Free Pascal Compiler version 2.0.4 [2006/09/22] for i386
Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Win32 for i386
Compiling c:\verytemp\test.pas
test.pas(4,13) Error: Identifier not found "class"
test.pas(4,13) Fatal: You need ObjFpc (-S2) or Delphi (-Sd) mode to compile this
 module
test.pas(4,13) Fatal: Compilation aborted
Error: C:\lazarus\fpc\2.0.4\bin\i386-win32\ppc386.exe returned an error exitcode
 (normal if you did not specify a source file to be compiled)

Il nous faut une compatibilité Delphi...
en utilisant -S2 (compatibilité delphi 2)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
C:\lazarus\fpc\2.0.4\bin\i386-win32>fpc c:\verytemp\test.pas -S2
Free Pascal Compiler version 2.0.4 [2006/09/22] for i386
Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Win32 for i386
Compiling c:\verytemp\test.pas
test.pas(13,24) Error: Duplicate identifier "x"
test.pas(14,24) Error: Duplicate identifier "x"
test.pas(31) Fatal: There were 2 errors compiling module, stopping
test.pas(31) Fatal: Compilation aborted
Error: C:\lazarus\fpc\2.0.4\bin\i386-win32\ppc386.exe returned an error exitcode
 (normal if you did not specify a source file to be compiled)

On obtient le meme défaut que dans lazarus (et, je suppose, que dans delphi2)

En spécifiant -Sd (compatibilité delphi), la compilation est réussie

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
C:\lazarus\fpc\2.0.4\bin\i386-win32>fpc c:\verytemp\test.pas -Sd
Free Pascal Compiler version 2.0.4 [2006/09/22] for i386
Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Win32 for i386
Compiling c:\verytemp\test.pas
test.pas(17,18) Warning: Function result does not seem to be set
test.pas(6,10) Note: Private field "THPpile.Mem" is never used
test.pas(7,10) Note: Private field "THPpile.LastX" is never used
test.pas(8,10) Note: Private field "THPpile.pile" is never used
test.pas(9,10) Note: Private field "THPpile.Mode" is never used
Linking c:\verytemp\test.exe
30 Lines compiled, 0.2 sec

L'auteur de freepascal s'est contenté de reproduire les comportements d'autres compilateurs. En l'occurence ici, ceux de delphi2 qui semblent activés par défaut dans Lazarus.
Je te confirme après l'avoir de nouveau testé que la modification de la case adhoc dans l'interface de Lazarus ne change pas le mode de compilation, pas plus que la modification manuelle du fichier fpc.cfg. C'est bien un bug de Lazarus.



Pour répondre à The Who, freepascal permet de compiler des sources ecrits pour différents compilateurs en utilisant des paramètres à la compilation. En voici quelques-uns :

-M<x> set language mode to <x>
-Mfpc free pascal dialect (default)
-Mobjfpc switch some Delphi 2 extensions on
-Mdelphi tries to be Delphi compatible
-Mtp tries to be TP/BP 7.0 compatible
-Mgpc tries to be gpc compatible
-Mmacpas tries to be compatible to the macintosh pascal dialects

Je suis prêt à parier que delphi2 (je n'ai pas cette version pour le vérifier) se comporte exactement comme freepascal sur cet exemple précis...

[thewho]

Bonjour,

Pour répondre à The Who, freepascal permet de compiler des sources ecrits pour différents compilateurs en utilisant des paramètres à la compilation. En voici quelques-uns :

-M<x> set language mode to <x>
-Mfpc free pascal dialect (default)
-Mobjfpc switch some Delphi 2 extensions on
-Mdelphi tries to be Delphi compatible
-Mtp tries to be TP/BP 7.0 compatible
-Mgpc tries to be gpc compatible
-Mmacpas tries to be compatible to the macintosh pascal dialects

Je suis prêt à parier que delphi2 (je n'ai pas cette version pour le vérifier) se comporte exactement comme freepascal sur cet exemple précis...

Tu as parié combien ?

Je n'ai jamais eu ce genre de problème de non respect du standard du langage avec Delphi, que j'ai utilisé depuis la version 1 (ça ne nous rajeunit pas), ni avec turbo pascal, que j'ai également utilisé dès sa sortie (ça nous rajeunit encore moins !)

Pour moi, un compilateur qui ne respecte pas au moins ce point précis, la portée - ici, locale - d'une définition, si cela est défini dans le langage, bien entendu, contient un grave bug.

Donc, c'est un bug, il n'y a pas à essayer d'ergoter : il vaudrait mieux le signaler au(x) développeur(s) du compilateur.

[ALT]

Je confirme que cette règle de portée fait partie du standard du langage Pascal tel que défini par Niklaus Wirth.
Du moins c'est celle utilisée par le compilateur UCSD (sur Apple II...Ça ne nous rajeunit pas plus !) & reprise par les différentes versions de TurboPascal que j'ai utilisées (4,5.5,7) ainsi que de Delphi (bah, c'est aussi du Borland).
D'où mon étonnement.

Bref, j'envoie un rapport de bug.
Merci à vous.

[thewho]

Bonjours,

Je confirme que cette règle de portée fait partie du standard du langage Pascal tel que défini par Niklaus Wirth.
Du moins c'est celle utilisée par le compilateur UCSD (sur Apple II...Ça ne nous rajeunit pas plus !) & reprise par les différentes versions de TurboPascal que j'ai utilisées (4,5.5,7) ainsi que de Delphi (bah, c'est aussi du Borland).
D'où mon étonnement.

Bref, j'envoie un rapport de bug.
Merci à vous.

Pourquoi "du moins" ?

C'est très clairement défini. Les compilateurs qui ne respectent pas cela ne sont pas en règle avec la définition du langage.

[ALT]

Parce que n'ayant pas lu la spécification du langage Pascal, je me refuse à affirmer quoi que ce soit.
Ça ne m'empêche pas d'en être sûr.

[ALT]

Bon.
Résumons :
J'ai un pb de portée de variables. Boarf, j'ai envoyé un courriel à l'auteur principal de FreePascal. Pas de réponse, mais ça viendra sûrement.
Quant au pb de fiches qui fonctionnent mal, j'ai refait la même fiche, en mettant d'abord tous les boutons, toutes les zones de texte... puis en ajoutant leurs méthodes. Et là, ça fonctionne parfaitement.

Je persiste à penser qu'il s'agit d'un bug, mais j'avais parfois ce genre de comportement anormal avec Delphi...

Donc, même si on ne peut pas considérer les pb résolus, il est clair qu'ils ne sont pas bloquants.
Par conséquent, je pense inutile de chercher plus loin.
À moins, bien sûr que quelqu'un ait une explication géniale...

Bon après midi à tous

[Clandestino]

J'ai aussi signalé le bug inhérent à Lazarus découvert grace à ce topic : Le non fonctionnement des choix d'option de compilation par l'utilisateur via l'IDE dans:
Projet >> Option du compilateur >> Analyse

ref (forum officiel en Anglais)
http://www.lazarus.freepascal.org/in...&p=13977#13977

[Clandestino]

La réponse concernant la partie du bug dans Lazarus m'a été donnée sur le forum anglophone.
Par défaut, Lazarus insère dans le code source la ligne
{$mode objfpc}{$H+}

{$H+} permet d'utiliser des ansistrings... celà n'a rien à voir avec notre bug.
{$mode objfpc} veut dire la meme chose que d'envoyer le paramètre -S2 au compilateur.

Quand au bg de freepascal : la documentation officielle explique les limitations de ce mode :
(voir http://community.freepascal.org:1000...x266-268000D.5)

D.5 OBJFPC mode
This mode is selected by the $MODE OBJFPC switch. On the command-line, this mode is selected by the -Mobjfpc switch.
You must use the address operator to assign procedural variables.
A forward declaration must be repeated exactly the same by the implementation of a function/procedure. In particular, you can not omit the parameters when implementing the function or procedure.
Overloading of functions is allowed.
Nested comments are allowed.
The Objpas unit is loaded right after the system unit. One of the consequences of this is that the type Integer is redefined as Longint.
You can use the cvar type.
PChars are converted to strings automatically.
Parameters in class methods cannot have the same names as class properties.

C'est donc une limitation volontaire sous ce mode de compilation.

Ce qui est défini dans le code source l'emportant sur les paramètres passés au programme via la ligne de commande, nous sommes par défaut dans ce mode sous lazarus.
Voilà pourquoi les tentatives pour passer en mode Delphi (delphi7 compatible) par le biais de la boite de dialogue d'options de compilation restaient vaines.


le mode delphi semble plus compatible avec nos habitudes.

D.3 Delphi mode
This mode is selected by the $MODE DELPHI switch. It tries to emulate, as closely as possible, the behavior of Delphi 4. On the command-line, this mode is selected by the -Mdelpih switch.
You can not use the address operator to assign procedural variables.
A forward declaration must not be repeated exactly the same by the implementation of a function/procedure. In particular, you not omit the parameters when implementing the function or procedure.
Overloading of functions is not allowed.
Nested comments are not allowed.
The Objpas unit is loaded right after the system unit. One of the consequences of this is that the type Integer is redefined as Longint.
Parameters in class methods can have the same names as class properties (although it is bad programming practice).

Ce dernier est déclenché dans le code en ajoutant la ligne
{$mode Delphi} (après avoir retiré {$mode objfpc})dans votre code source ou en envoyant au compilateur le paramètre -Sd

Pour plus de renseignements sur les différents modes, voir la documentation officielle en ligne à ce sujet :
http://community.freepascal.org:1000...90-900001.2.17

Pour plus de renseignements sur les differentes options du compilateur, lancez C:\lazarus\pp\bin\i386-win32>fpc -h dans une console.

Bonne programmation
Clandestino