Création de Constante et d'expression

Bonjour,

A l'heure actuelle, l'accès aux objets sous panoramic se fait à l'aide de leurs numéro d'identification. Soit...
Or par commodité la plupart du temps les objets sont indicés par rapport à un objet de base. par exemple il arrive fréquemment d'avoir des lignes de ce style :

Code:

dim toto,titi

toto=1
titi = toto+1

List toto
...
...
edit titi
....

ou alors :

on_click nf%+3,abandon_form100
                              ou
scroll_bar GLIST_numero_objet% + 2

bref cela devient vite incompréhensible....puis cela bouffe de la RAM pour des variables qui ne sont pas vraiment "variables".
serait-il possible d'avoir une instruction du genre :
CONST toto=2
CONST titi=toto+1
(en gros l'équivalent du #define en C)

Cela éliminerai la déclaration de "variables" inutiles puis cela permettrai d'avoir un code beaucoup plus lisible...

Il y a longtemps que j'ai voulu introduire la notion de CONSTANTE par le mot-clé #CONST.

Mais quand j'ai vu les difficultés que certains avaient pour comprendre et utiliser #INCLUDE, j'y ai renoncé.
En effet, les principes de #include et de #const sont voisins. Comme j'ai du réexpliquer je ne sais combien de fois sur ce forum le fonctionnement de #include, j'ai renoncé au #const.
Je n'ai plus l'énergie pour réexpliquer la même chose pendant des jours et des jours.

Tu peux relire:
https://panoramic.1fr1.net/vos-souhaits-d-amelioration-de-panoramic-f8/include-t666.htm?sid=6e018f05fb9b723b34584de3d87da8df

Excuse moi Jack, mais je ne vois pas pourquoi tu prives certains d'une nouvelle commande sous prétexte que d'autres ne maitrisent pas bien certaines fonctions.
Y font comme moi, ils remettent cent fois l'ouvrage sur le métier.
Je fais parti de ceux qui ne maitrise pas bien #INCLUDE, Hé bien je me débrouille autrement. Et un jour (à force) j'y arriverai. Et si c'est pareil avec une CONSTANTE, alors je laisserais de coté.

C'est mon avis......

Je ne l'ai pas écrit plus haut mais tout de même, je le fait:

Faut-il que je quitte PANORAMIC pour ne pas l'empécher d'évoluer.

c'est un peu vif, j'en convient, mais rassure-toi c'est pas demain la veille...

Des constantes j'en ai utilisé dans d'autre basic, je ne vois pas la difficulté majeur. C'est un conteste simple, et même de très loin beaucoup plus simple qu'un #include qui a une structure particulière (l'emplacement de celui-ci dans l'enchainement, l'emplacement des variables et des labels ainsi que leurs doublons éventuels). Ou alors on ne parle pas de la même chose, par exemple pi=3.14159 est pour moi une constante et ne doit pas changer. Si c'est ça une constante, quel est la difficulté majeur?

Employer une variable qui ne bouge plus pour un objet, cela est tellement évident, que je ne comprend pas le problème, et si on pouvait la définir comme un entier, cela éviterait de mettre des "%" en fin de nom.

A mon avis si je ne suis pas hors de course, tu peux te lancer. Il y a suffisamment aujourd'hui de personne compétente, vu les nouveaux, pour prendre le relai dans les explications pour quelqu'un qui ne maitrise pas.

Une constante, ce n'est pas tout à fait pi=3.14 ou une variable qui ne change pas.
Une constante, c'est une suite de caractères qui est remplacée par une autre suite de caractères.
C'est par exemple les 2 caractères p et i qui sont remplacés dans ton source par la suite de caractères 3 point 1 4 1 5 9 et cela AVANT toute interpretation et toute exécution. C'est fondamentalement different.
Mettre des constantes, c'est faire des copier/coller.

J'ai peut-être un sal caractère mais cette fin de non reçevoir, je l'accepte pas.

Tchao !

Je n'ai fait que rappeler ce qu'est une constante. C'est tout.

Tant fait pas Jean Claude, on me remet souvent à ma place, et je laisse glisser.
Par contre, moi je comprend ceci:

Citation :

CONSTANTE ET VARIABLE
Base
Delphi fait une distinction entre constantes et variables. Une constante garde sa valeur initiale tout au long du programme, elle ne peut être modifiée. Une variable pourra durant la durée du programme changer sa valeur initiale. Les constantes et les variables doivent être déclarées avant leur utilisation. Voici un exemple de déclaration de constantes et de variables :

procedure premier;
const nul = 0;
code = 'secret';

var age : integer;
salaire : real;
sexe : char;
...
Dans le cas des constantes, l'identificateur est suivi du signe "=" et de la valeur que l'on associe à la constante. Pour les variables, l'identificateur est suivi du signe ":" et du type de la variable.

Chaque déclaration de constante ou de variable se termine par un point virgule. Si plusieurs variables sont du même type, il est possible de les déclarer sous forme de liste d'identificateurs (séparés par une virgule) suivie du signe ":" et du type des variables :

var
age, enfants, voitures : integer;
salaire, taille : real;

En dehors de la syntaxe de Delphi et de Panoramic, j'ai du mal de comprendre l'explication de Jack. Est-ce différent, ou dit-il la même chose?

N'importe comment, lorsque je fais un programme et que je ne comprends pas une instruction, et ça arrive régulièrement lorsque j'ai pas de traduction, je laisse de côté celle-ci. De plus l'utilisation de constante si elle n'est pas comprise, n'interdit pas de coder comme on l'a déjà fait jusqu'à lors. Si une instruction aide à la programmation pour certain, pourquoi ne pas la faire, lorsque cela ne remet pas en cause la facilité du reste des instructions.

Dans la plupart des langages (Delphi compris) une variable tient une place en mémoire. C'est normal, car cette place en mémoire sert à stocker la valeur de la variable.
Mais une constante ne tient AUCUNE place en mémoire.
La preuve: essayez un peu de "patcher" la valeur d'une constante dans un exécutable. Vous n'y arriverez pas car c'est impossible.

Parce qu' une constante c'est comme un copier/coller avant de compiler un source et qu'elle n'existe plus ensuite.

Je reprend mon exemple de "pi".
Si je déclare une constante pi qui vaut 3.14159, alors, avant de compiler, à chaque fois que "pi" sera rencontré dans le source, il sera remplacé par LA CHAINE DE CARACTERES "3.14159".

Il faut bien comprendre qu'une constante n'existe pas en tant que telle.

Déclarer une constante pi comme 3.14159, c'est demander qu'avant la compilation, tous les "pi" rencontrés soient changés par "3.14159".
Quand je dis tous les "pi" rencontrés, c'est bien-sûr tous les "pi" qui ne sont pas à l'intérieur d'un texte ou d'un nom de variable.

print pi sera changé en print 3.14159
print 2*pi sera changé en print 2*3.14159
et bien-sûr, print pirate restera tel quel.

Il n'y a ensuite plus aucune trace de pi.

Me suis-je bien exprimé?

J'enfonce le clou:
Si je fais

Code:

#const pi=3.14159

print pi

l'éditeur enverra cela au compilateur:

Code:

print 3.14159

et la constante pi aura disparu et sera complètement inconnue du compilateur.

Le mot-clé #const n'est pas encore sorti en Panoramic, et il crée déjà des problèmes...

Maintenant, si quelqu'un n'a pas compris, il ne faut pas qu'il utilise les constantes le jour où elles seront utilisables dans Panoramic.
Moi, je ne vais pas m'user la santé à répéter dix fois la même chose.

Dans les mêmes joyeusetés que #include et #const, j'ai prévu de sortir aussi #macro qui insèrera des macro-instructions paramétrées dans le source. Mais ça, c'est pour un autre épisode. A chaque jour suffit sa peine...

Pour ma part, je suis très intéressé par les constantes. Cela permettra d'écrire des programmes plus lisibles, et plus paramétrables. Après tes explications, Jack, je pense qu'il est clair pour tout le monde ce qu'est une constante. Et je crois que même intuitivement, le terme "constante" a uns signification suffisamment claire pour tout le monde.

Dans la foulée des directives au compilateur, je voudrais relancer une idée que j'avais lancée il y a déjà un certain temps:
#PRIVATE_ON et #PRIVATE_OFF
Ces directives moduleraient l'action des commandes dim et label. Avec #PRIVATE_ON, les dims et labels suivants sont marqués "privé", et la directive #PRIVATE_OFF les "efface" tout simplement de la liste des variables et labels. Sachant qu'un #PRIVATE_ON ne peut pas suivre un autre PRIVATE_ON et pourrait éventuellement être ignoré. Par défaut, l'état serait #PRIVATE_OFF.

J'en constate l'importance tous les jours, en codant GLIST, par exemple. TOUS les labels et TOUTES les variables doivent être préfixés par une chaine de caractères identifiants (ici "GLIST_") afin de ne pas créer de conflits en utilisant ce modèle par #INCLUDE; le même problème se pose à tous ceux qui utilisent #INCLUDE, quelque soit son usage. Ce serait génial d'avoir une possibilité de restreindre le champ de "visibilité" d'une variable ou d'un label à une section précise du code. Et le fait que ce soit une directive et donc appliqué avant toute interprétation me semble parfait pour cet usage.

C'est bien clair pour les constantes, ça n'intervient qu'au moment de la compilation. Mais bon, à défaut on peut utiliser des variables (ce que nous faisons tous), en attendant mieux.

Klaus, ce que tu veux finalement ce sont des variables (et des étiquettes) locales pour incorporer sans problèmes de collisions des morceaux de code venus d'ailleurs. Ca c'est intéressant.