Integer en long, c'est quoi la différence

[Anonyme2]

Je ne comprend pas la différence entre un long et un integer

d'après la doc, les plages sont les suivantes :

Long .l 4 octets -2147483648 à +2147483647
Integer .i 4 octets (32 bits) -2147483648 à +2147483647

mis à part le 32 bits entre parenthèses, elle est ou la différence ?

[Progi1984]

Une petite explication :

Code : Tout sélectionner

Many people have the habit of appending .l to every variable, even though this has been the default type all the time. Well, now is the time to stop that practice. Not only will the speed be worse using a too small type on x64, you also need to constantly worry what you store in the variable, as many things need 8 bytes for storage on x64 (pointers, handles, #PB_Any values, etc). Do not try to get guided by the urge to “save memory” here. 64bit systems have a ton of memory, and for normal variables this is really no argument.

From now on, you should treat the long type as you treated words and bytes so far. Use them only when really needed inside structures, or for Arrays/Lists where memory concerns really become an issue. For every normal variable just leave out the type (which will default to .i), or if you really cannot shake the habit, use .i instead. Just do this consistently, even for counter variables and the like. This will save you a ton of trouble, trust me. Truncated pointers are the worst kind of bug to try to track down.

Another good habit is to simply use a real *Pointer instead of just an integer variable whenever a pointer is stored. This is no requirement, as the .i type will work just as well. But in the long term this increases readability of the code in my opinion.

Source : http://www.purebasic.fr/blog/?p=42

[Anonyme2]

Je l'avais lu mais je ne me souvenais plus.

L'idéal aurait été de supprimer les long, non ?

[cha0s]

Pour résumer la taille du .i dépend de pure (64 ou 32bits). Ce qui donne en 64 bit -9.10^18 a +9.10^18. (2^64 valeurs différentes)

[Anonyme2]

Il semble qu'en 64 bits, certains éléments (structures) acceptent des éléments 32 bits, donc des long et des éléments 64 bits d'où les integer.

[case]

Je l'avais lu mais je ne me souvenais plus.

L'idéal aurait été de supprimer les long, non ?

bah non tu peux avoir besoin d'écrire sur 32 bit seulement sinon autant aussi enlever les word et les bytes ...

[Backup]

il me semble avoir lu quelque part

qu'il valait mieux utiliser les '.i' plutot que les ".l" depuis la version 4.30

pour maintenir une compatibilité avec les OS 64 bit !!

car dans ce cas , le prg compilé sur un os64 peut s'adapter sur un os 32
et inversement....

je crois même qu'il disait qu'il valait mieux ne rien mettre du tout a la variable !!

[comtois]

je crois même qu'il disait qu'il valait mieux ne rien mettre du tout a la variable !!

avant la 4.30 le type par défaut était le long .l
avec la 4.30 le type par défaut devient l'integer .i, donc en effet si tu ne mets rien, tu auras un integer.

tout ceci me rappelle un article sur les types en C++
http://cpp.developpez.com/cours/cpp/?page=page_3#LIII-B

Notamment ce passage

Afin de résoudre ces problèmes, la plupart des compilateurs brisent la règle selon laquelle le type int est le type des entiers natifs du processeur, et fixent sa taille à 32 bits quelle que soit l'architecture utilisée. Ainsi, le type short est toujours codé sur 16 bits, le type int sur 32 bits et le type long sur 32 ou 64 bits selon que l'architecture de la machine est 32 ou 64 bits. Autrement dit, le type qui représente les entiers nativement n'est plus le type int, mais le type long. Cela ne change pas les programmes 32 bits, puisque ces deux types sont identiques dans ce cas. Les programmes destinés aux machines 64 bits pourront quant à eux être optimisés en utilisant le type long à chaque fois que l'on voudra utiliser le type de données natif de la machine cible. Les programmes 16 bits en revanchent ne sont en revanche plus compatibles avec ces règles, mais la plupart des compilateurs actuels ne permettent plus de compiler des programmes 16 bits de toutes manières.

[comtois]

Tiens au fait, Freak nous a révélé que l'integer était déjà dans la 4.20 !!
ils nous en cachent des trucs !!

[Fig]

Justement, je me posais cette question et j'ai trouvé ce fils en faisant une recherche....

Donc est ce que j'ai bien compris :

un integer sera de 32bts sur un systeme 32 et de 64 sur un systeme 64...
Si je veux garder, indépendemment du systeme, un format 32 je dois choisir long et si je veux un format 64 les quad...

C'est bon ?

[Progi1984]

Réponse affirmative

[minirop]

pour info, je suis sous vista 64, int ET long font 32b, pour 64 faut utiliser long long

[beauregard]

il me semble avoir lu quelque part

qu'il valait mieux utiliser les '.i' plutot que les ".l" depuis la version 4.30

.f car avec un .i, mes sprites sont figés pour l'éternité...

[Ollivier]

@Beauregard

.f car avec un .i, mes sprites sont figés pour l'éternité...

Là, c'est autre chose! Ce sont les flottants 32 bits les F. C'est vrai que dans le cas où l'on ne veut pas se prendre la tête avec des demi-vitesses ou des quarts de vitesse, le flottant est important, quoique j'ai réussi un scroll graphique à vitesse variable uniquement avec les I, sauf que j'ai dû jongler, d'autres algos entrent en jeu.

Ollivier

[beauregard]

@Beauregard

.f car avec un .i, mes sprites sont figés pour l'éternité...

Là, c'est autre chose! Ce sont les flottants 32 bits les F. C'est vrai que dans le cas où l'on ne veut pas se prendre la tête avec des demi-vitesses ou des quarts de vitesse, le flottant est important, quoique j'ai réussi un scroll graphique à vitesse variable uniquement avec les I, sauf que j'ai dû jongler, d'autres algos entrent en jeu.

Ollivier

attend je vérifie,... ah oui effectivement çà marche, bon ben je le note