PureBasic

A partir du moment où j'ai écrit : 1. Y a-y-il une différence entre

x1 = 5 et x1.d = 5

2. Au niveau du transtypage, que cela soit en 32 ou 64 bits, est-il "autorisé" d'écrire

x1.d = dr.i

.
3. Et dans l'autre sens ?

Un rapide petit test : Debug

5
5
3
2
-2

Le transtypage semble autorisé et renvoie la partie entière (C'est donc une simple troncature).

Cordialement. Gilles

Purebasic n'émet pas de message d'erreur ou de warning concernant le transtypage entre valeurs numériques.
C'est donc à l'utilisateur de savoir ce qu'il fait et quelle conséquence cela aura. En compilant en x86 il y aura une différence puisque si rien n'est précisé, le type est INTEGER (donc un entier codé sur 32 bits alors que le Double est un flottant sur 64 bits).
En compilant en x64, il y aura aussi une différence puisque le type Double est en fait un flottant sur 64 bits et le type INTEGER par défaut, un entier sur 64.

Par contre, entre x1=5 et x1.q=5, il n'y aura pas de différence sur x64 (INTEGER 64bits, la même chose qu'un QUAD)
Mais est différent sur X86 (INTEGER 32 bits contre QUAD cad entier sur 64 bits)

Cf: https://www.purebasic.com/french/docume ... ables.html

Si on manipule de grands nombres ou des nombres à virgule, il est nécessaire d'être méticuleux dans la notation et le type des opérandes acceptés par les commandes de purebasic.
Dans les cas les plus classiques, le type integer par défaut suffit et un débutant n'a pas à se poser de question.

Merci pour la réponse. C'est très moyen cela puisque je compile aussi bien en 32 qu'en 64 bits.

Si je comprends votre réponse le Define ne sert à rien ?

Define x1.d
x1 = 5 et x1.d = 5 ne sont pas équivalents en terme d'écriture (i.e. d'utilisation dans le code) ? Qu'ils soient encodés différemment en 32 et 64 bits a peu d'importance (sauf pour des limites que je n'utilise pas). Mais si dans un même code source où un réel est déclaré "Define x1.d", x1 n'est pas équivalent à x1.d, c'est la galère ! J'ai dû mal interpréter votre réponse. Rassurez-moi !

Pour le transtypage OK. J"avais bien remarqué qu'il n'y avait pas d'avertissement et je trouve cela fort regrettable : nul n'est à l'abri d'une erreur. En Pascal on est très strict. Ecrire "entier = réel" provoque une erreur de compilation directement. Là, cette permissivité sans message est un peu déroutante.

Cordialement. Gilles

J'ai répondu pour Je n'ai pas tenu compte de define là dedans désolé. Ma réponse n'est donc valable que sans define.

Le cas échéant, il est évident que si vous utilisez define, l'écriture est équivalente dans ce cas précis car le type par défaut de x1 devient celui que vous avez défini auparavant.

Si vous êtes contrarié par la façon dont purebasic fonctionne, je vous recommande d'utiliser la commande EnableExplicit() en début de programme. Cette fonction vous obligera à définir toutes vos variables sous peine d'erreur.

Ok,

je comprends un peu mieux pourquoi certains programmeurs en PureBasic s'obligent à utiliser dans toutes les lignes les extensions de type à côté de leurs variables. Même si on utilise Define, rien ne vous empêche par mégarde de transtyper sans prendre les précautions nécessaires (dr = x1)... et sans être averti à la compilation.

Donc effectivement un dr.i = x1.d prend tout son sens car le programmeur est conscient de son transtypage.
Encore merci pour toutes ces infos.
Cordialement GIlles

C'est :sans parenthèse. Je pense Fig n'en a pas besoin pour avoir fait cette petite faute.

"Define" a une utilité "récente" depuis que sa présence est possible dans une procedure et fait l'équivalence à "Protected".

Admettons un code :Si l'on veut porter un de ces codes en procédure, il suffit d'encadrer l'un des codes avec la paire Procedure/EndProcedure, et c'est bon : C'est une question de méthode de programmation, notamment quand on souhaite énumérer les hypothèses et les faire précéder au raisonnement.

Roger devient une variable locale au sein de la procédure.

Et Fig a raison pour la réponse 1, sauf à partir du moment où on a :ou.
A partir de cette hypothèse, il n'y aura pas de différence. Je suppose que Fig a ommis cette 1ère ligne d'hypothèse du message de Selzig.

Conclusion:

1. Non
2. Oui, par troncature effectivement
3. Oui, par assortiment de mantisse

Personnellement je m'oblige à déclarer toutes les variables en utilisant EnableExplicit.

Une faute de frappe est vite arrivée et cela peut vite donné un dysfonctionnement difficile à résoudre puisqu'il ne s'agis pas d'un bug. En effet (sans EnableExplicit) les variables sont crées à la volée et une faute de frappe crée une nouvelle variable.

Ne pas oublier aussi que ne pas typer un variable exemple "maVariable" la déclare en type integer qui varie selon le processeur avec une taille de 32 ou 64 bit. Je préfère donc personnellement la typée en long "maVariable.l" qui prendra une taille de 32 bit qu'elle que soit le processeur.

Effectivement il n'y a pas de () aux commandes pour la compilation comme le dit Olivier.