Plus j'utilise l'éditeur, plus je me pose de questions de plus en plus poussées. Et j'aimerais éclaircir quelques points sur les variables :
 
1. Lorsqu'une variable ne contient pas de valeur, la plupart du temps (ou toujours), la valeur est alors NULL. Est-ce vrai pour tous les types ?
 
2. A propos des fuites de mémoire, est-ce que à chaque appel d'une variable globale, cela occasionne une fuite de mémoire ? Les variables locales n'occasionnent-elles aucune fuite de mémoire ? Si oui, cette fuite de mémoire est-elle proportionnelle à la taille de la variable ? Est-ce que les fuites de mémoires occasionnées par les variables de types codés sur un faible nombre de bits sont négligeables ? (je suppose que les types du genre unité, compétence ou encore déclencheur sont codés sur beaucoup plus de bits que les types booléen, entier, réel ... )
 
3. Les variables sont codées sur combien de bits ? (l'idéal serait un site affichant cela pour chaque type de variable). Quelles sont les limites min et max des types réel et entier ? Quelle est la précision des réels ?  
 
4. Quelle est la différence entre les variables locales et globales (i.e. comment l'ordinateur gère-t-il les variables dans la mémoire) ? Et donc pourquoi les variables globales occasionnent-elles des fuites de mémoire et les variables locales non ?
 
5. Les tableaux de variables (ou encore listes) : ont-ils une taille maximale ? Lorsque l'on déclare une variable globale  de type tableau de <type>, si dans déploiement on met N, la taille du tableau ainsi créé sera-t-elle de N ou N+1 ? (puisque il faut savoir que le plus petit indice d'un tableau n'est pas 1 mais 0) Si l'on déclare un tableau de N éléments et qu'on essaie de donner une valeur à un indice supérieur à N+1, que se passe-t-il ?
Lorsque l'on fait la déclaration d'un tableau en jass de la façon suivante : "local <type> <nom_var> array" ; quelle taille à alors la variable ainsi créée ? Comment donne-t-on une taille spécifique à un tableau ? Peut-on redimensionner un tableau à n'importe quel moment ? Si oui, l'ordinateur crée-t-il en réalité une nouvelle variable ? Et si oui, les valeurs du tableau sont-elles effacées ?
 
Je ne vois pas d'autres questions à poser sur les variables pour le moment.
Merci d'avance pour vos réponses.

Tous les types peuvent sont en fait des entiers, mis à part le format des réels. Un entier est codé sur 4 octets.
 
1/ null est donc égale à 0, null est comparable avec tous les types même les réels.
 
2/ Etant donné que beaucoup de types sont des extentions de handle, donc des pointeurs, si tu ne détruit pas l'objet une fois que tu n'en a plus besoin, que ta variable soit locale ou globale, alors tu perdra le pointeur, donc la mémoire pour ton objet sera toujourrs alloué, c'est ce qu'on appele une fuite de mémoire. Pour des types tels que des points cela ne prend pas trop (deux réels), une unité prend en effet beaucoup, mais si tu en perd dans une boucle alors cela se fait sentir au cours de la partie. Si tu veux savoir s'il y a des fuites dans ta carte c'est simple, tu la lance et tu regarde dans le gestionnaire de processus si la mémoire utilisée par war3.exe augmente.
 
3/ Etant sur 4 octets tu peux faire le calcul ou le tester (set i = 0x7FFFFFFF), les limites pour un entier sont [-2147483648;2147483647], ce qui en Jass est amplement suffisant.
 
4/ C'est la même chose que pour du C++ ou tout autre langages utilisant des objets.
 
5/ D'après le common.j la limite est

Personne n'a jamais vraiment pris la peine de vérifier n'ayant pas d'utilité à faire des tableaux plus grands. Pour l'allocation de mémoire dans ce cas là je n'ais pas fait de teste mais il a l'air de se débrouiller assez bien là dessus. Les tableaux sont dynamiques, il les redimensionne tout seul en te conservant les valeurs. En fait il passe par un second tabbleau pour les index, permettant ainsi d'avoir des valeurs diverses.

juste une petite remarque concernant la 2).
Si tu lance une partie perso et que tu bascules sur le gestionnaire des taches tu ne verras aucune fuite de mémoire en "direct". Warcraft arrête son traitement.
Si tu veux vraiment voir l'amplitude des fuites lance une partie en réseau local

Merci pour toutes ces informations.
 

Comment peut-on détruire un objet ?
 
J'aimerais avoir plus d'informations sur les extensions de handle. Si j'ai bien compris, les entiers occasionneront autant de fuite de mémoire que les unités puisque c'est le pointeur qui n'est pas supprimé, et non le contenu de la variable directement, je me trompe ?

Les entiers ne sont pas des objets.
 
Par exemple
 

Outre le fait que cette fonction ne sert à rien, elle produira une fuite de mémoire car elle créer un nouvelle instance de location qui n'est pas supprimé par la suite.
Pour éviter cela il faut faire:

ok. Et comment fait-on pour supprimer des objets d'autres types ?

Ce sont toutes les fonctions qui commencent en Remove ou Destroy.

Quelle est la différence entre Destroy et Remove ?
 
Qu'est-ce que c'est "pool" dans DestroyUnitPool" ?
 
Si l'on veut libérer la mémoire utilisée par une variable de type unité il faut donc faire RemoveUnit(<var> ) ?
Mais dans ce cas l'unité est supprimée. Alors est-ce que c'est le contenu de la variable qui doit être supprimé et non le pointeur ?
Ou alors faut il supprimer le pointeur, d'une autre façon ?
 
exemple, mon trigger pour la glisse :

 
Que faut-il donc mettre à la place de call RemoveUnit(U) ligne 15 ?
Puisque je suppose qu'il faut libérer la mémoire, la variable U est de type unité, un objet.
Au fait si vous voyez un moyen quelconque permettant d'encore améliorer ce trigger, je suis prenant, bien que je ne vois pas d'autre possibilité de l'optimiser... sauf peut-etre créer des régions de début et de fin de glisse, et activer le déclencheur lorsque le personnage entre une zone de début de glisse et le désactiver lorsqu'il rentre dans une région de fin de glisse. Mais je n'ai pas que ça à faire et cela occasionneraient de nombreux bugs. De map contient plus de terre que de glace ^^.
 
PS : pourquoi ai-je décomposé mon trigger de glisse en 11 triggers, un par joueur ? Simplement pour pouvoir désactiver la glisse lorsque le personnage est mort, ainsi avoir le déclencheur le plus économe possible (inutile d'avoir un déclencheur qui gère la glisse des 11 personnages lorsque l'on est deux on trois dans la map !). Au passage cela résout le problème du personnage qui continue de glisser jusqu'à la terre lorsqu'il meurt .
 
Bon je vais me coucher moi... bonne nuit à tous.

cela veut dire que tu as une piscine d'unité ^^.
 
Explication par M. Ayane
 
Au lieu de 11 triggers tu aurais pu en faire un seul avec une variable bolenne déployée
 
Entre destroy et remove il n'y a pas de différence je penses, c'est juste un vocabulaire différent
 
tu peu faire set U = null mais je ne penses pas que cela soit necessaire, étant donné que c'est une variable locale et qui n'a d'existence que dans sa fonction, enfin à toi de tester    
 

mdr
 
En gros UnitPool c'est groupe d'unités.

un groupe de type d'unité

non le type c'est "groupe d'unités"

j'ai pas dit groupe de type unité mais groupe de type D'unité c'est du bon francais ^^

groupe de type "d'unités" ça veut rien dire lol
 
Je crois que j'ai enfin compris l'intérêt des variables locales par rapport aux variables globales quant aux fuites de mémoires : à la fin de l'exécution d'une fonction les variables locales sont supprimées. Ce que je ne comprends pas, c'est pourquoi chaque appel d'une variable globale provoque une fuite de mémoire.

bien sur que si un groupe contenant plusieurs types d'unités c'est pas ma faute si tu te bats avec le français    
Euh en fait c'est pas à chaque appel, c'est juste quand elle ne sont plus utilisées

ah ok. Sinon Le type "d'unités", ça veut peut-être dire quelque chose, mais d'après mes connaissances en français, pas dans cette langue si voluptueuse.

C'est ce que tu rajoutes/enleves/prends dans un unitpool.
Traduction : type d'unité   ou autrement dit paysan, grunt, chevalier , etc...

le type c'est alors "types d'unité"......ok je me cache xD

c'est vrai que j'avais fait une grossière erreur de faute d'orthographe, les torts sont partagés

^^

une petite question : il est beaucoup plus rapide de faire une division par 256 que par 200 vu que les nombres sont stockés en binaire, n'est-ce pas ?

surement mais on parle de nanosecondes là  

xD je sais mais je suis un perfectionniste, c'est d'ailleurs pourquoi je mets trois plombes à faire ma map .

Normalement remplacer des 0 par des 1 ne va rien changer au traitement, cela prendra le même temps. Ce n'est pas comme si on avait deriière un  compilateur qui va optimiser le code, il faut garder à l'esprit que le langage est interprêté et non compilé.
C'est pour cela que le code suivant

et

Feront la même chose au niveau machine pour un langage compilé.
Alors qu'en Jass vu qu'il est interprêté tu lui donne un else en plus à analyser à chaque fois. Le deuxième code est donc une optimisation pour un langage interprêté.

ok