La nouvelle syntaxe MQL4 - page 3

Nouveau commentaire
 

J'ai une question concernant les types de variables, int, uint, char, short ushort, etc. Le nouveau compilateur émet des avertissements quant à une éventuelle perte de données due à la conversion de type ;

a) d'utiliser celui qui correspond le mieux aux exigences de la variable ou,

b) d'éviter de convertir entre les types et donc d'utiliser int pour tout. (enfin, tout ce qui ne nécessite pas de virgule flottante).

 
SDC:

J'ai une question concernant les types de variables, int, uint, char, short ushort, etc ;

a) d'utiliser celui qui correspond le mieux aux exigences de la variable ou

b) d'éviter de convertir entre les types et donc d'utiliser int pour tout. (enfin, tout ce qui ne nécessite pas de virgule flottante).

Si vous avez besoin d'un long non signé, un int ne suffira pas... utilisez le bon type et une conversion de type explicite. IMO
 

Par conversion explicite de type, vous voulez dire qu'il faut effectuer la conversion avant tout calcul entre les différents types ?

 
RaptorUK:
Si vous avez besoin d'un long non signé, un int ne suffira pas... utilisez le bon type et une conversion de type explicite. IMO

Je suis d'accord.
 
SDC:

Par conversion explicite de type, vous voulez dire qu'il faut effectuer la conversion avant tout calcul entre les différents types ?

Voir ici : https://www.mql5.com/en/docs/basis/types/casting
 

Bon article merci angevoyageur je vais le lire correctement en rentrant du travail.

 
SDC:

par conversion explicite de type, vous voulez dire qu'il faut faire la conversion avant tout calcul entre les différents types ?

Non, je veux dire que vous pouvez convertir un ulong en int comme ceci . . .

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

OK, oui, c'est ce que je pensais que vous vouliez dire.

Sauf que je ne demandais pas vraiment à propos des ulong. J'ai rarement, voire jamais, besoin de travailler avec des valeurs aussi grandes que celles qui ne peuvent être contenues dans un entier de 32 bits. Je ne sais même pas comment dire le nombre qu'un entier de 64 bits peut contenir lol...

J'aurais probablement dû être plus précis, je n'ai pas eu le temps ce matin d'écrire ma question correctement mais maintenant que je suis à la maison, je vais le faire.

Dans l'ancienne mql4, nous utilisions des entiers pour tout. Nous pouvions écrire for(int i=0 ; i<100 ; i++) Nous n'avons pas besoin de valeurs négatives, et nous n'avons pas besoin d'une valeur plus grande que 100 donc nous pouvons utiliser un uchar pour cela. Est-ce que cela signifie que c'est ce que nous devons faire ?

Quand je regarde le code d'autres programmeurs, beaucoup d'entre eux semblent utiliser des types entiers 32 bits. Y a-t-il une raison valable à cela ? Que savent-ils que je n'ai pas encore découvert ? Est-ce que le fait d'utiliser les types de variables les plus petits dans un programme crée un casse-tête de typecasting sans autre raison qu'une taille de fichier légèrement plus petite ? Ou est-ce que cela permet d'économiser beaucoup de RAM ? Peut-on supposer que tant que la valeur d'un type peut être accommodée par un autre type, il est possible de le faire ? Le typecasting entre différents types utilise-t-il beaucoup plus de CPU que l'utilisation d'un même type ?

Mise à jour : J'ai fait des recherches et j'ai lu cette réponse à une question similaire sur stackoverflow.com.

"En termes de performances, un int est plus rapide dans presque tous les cas. Le CPU est conçu pour travailler efficacement avec des valeurs de 32 bits.

Les valeurs plus courtes sont compliquées à gérer. Pour lire un seul octet, par exemple, le CPU doit lire le bloc de 32 bits qui le contient, puis masquer les 24 bits supérieurs.

Pour écrire un octet, il doit lire le bloc de 32 bits de destination, écraser les 8 bits inférieurs avec la valeur d'octet souhaitée, puis réécrire le bloc de 32 bits entier.

En termes d'espace, bien sûr, vous économisez quelques octets en utilisant des types de données plus petits. Ainsi, si vous construisez une table de quelques millions de lignes, il peut être intéressant d'envisager des types de données plus courts. (Et la même chose pourrait être une bonne raison d'utiliser des types de données plus petits dans votre base de données).

Et du point de vue de la correction, un int ne déborde pas facilement. Que se passe-t-il si vous pensez que votre valeur va tenir dans un octet, et qu'à un moment donné dans le futur, une modification inoffensive du code signifie que des valeurs plus grandes sont stockées dans le code ?

Ce sont quelques-unes des raisons pour lesquelles int devrait être votre type de données par défaut pour toutes les données intégrales. N'utilisez byte que si vous voulez réellement stocker des octets machine. N'utilisez les shorts que si vous avez affaire à un format de fichier, un protocole ou autre qui spécifie réellement des valeurs entières de 16 bits. Si vous traitez simplement des entiers en général, faites-en des ints."

 
SDC:

OK, oui, c'est ce que je pensais que vous vouliez dire.

Sauf que je ne me posais pas vraiment de questions sur les ulongs. J'ai rarement, voire jamais, besoin de travailler avec des valeurs aussi grandes que celles qui ne peuvent être contenues dans un entier de 32 bits. Je ne sais même pas comment dire le nombre qu'un entier de 64 bits peut contenir lol...

J'aurais probablement dû être plus précis, je n'ai pas eu le temps ce matin d'écrire ma question correctement mais maintenant que je suis à la maison, je vais le faire.

Dans l'ancienne mql4, nous utilisions des entiers pour tout. Nous pouvions écrire for(int i=0 ; i<100 ; i++) Nous n'avons pas besoin de valeurs négatives, et nous n'avons pas besoin d'une valeur plus grande que 100 donc nous pouvons utiliser un uchar pour cela. Est-ce que cela signifie que c'est ce que nous devons faire ?

uchar - Unsigned Character (caractère non signé), pourquoi l'utiliser pour une boucle ? Cela n'a aucun sens pour moi... utilisez un int. Vous allez travailler avec des ulongs, c'est ce qu'est une nouvelle datetime... et si vous tapez sans y penser à l'avenir, vous serez averti... faites avec ou ignorez l'avertissement. Ne vous contentez pas d'espérer le meilleur, faites comme vous le faites maintenant, apprenez et comprenez.

Ce que vous avez posté sur stackoverflow me paraît logique, je pense que c'est un bon conseil.

 
SDC: Le typecasting entre différents types utilise-t-il beaucoup plus de CPU que l'utilisation du même type ?

Entre différentes tailles, cela utilise plus de CPU, mais pas beaucoup plus. Juste des instructions différentes comme les 32 bits mentionnés fetch, isolate, operate, place, write, lors de la modification d'un caractère dans une structure. Tout comme multiplier par 0,5 utilise un peu moins de CPU que diviser par 2,0.

Economiser 16 bits par élément de tableau n'a pas de sens sur les machines GB, je l'ai fait quand j'ai implémenté l'application, la base de données, l'interface graphique (vt100) en 8 KB (sic.) Passer à 64 bits par (pour tout) n'aura pas de sens tant que les plateformes 128 bits ne seront pas courantes.

Signé ou non signé, il n'y a pas de différence. Il s'agit simplement d'une affectation, aucun bit n'est modifié. La différence réside dans le code qui utilise la variable. Par exemple, A[index] fait Address(a) + index * sizeof(a[0]) où le plus est une addition signée ou non signée.

Pour la clarté du codage, j'utiliserais uint pour indexer les tableaux puisque A[-1] n'a pas de sens mais le décompte est problématique FOR(uint iA=n ; iA >= 0 ; iA--){} iA>=0 est toujours vrai.

Utilisez int (ou uint) sauf si vous devez le faire pour d'autres raisons.
123456
Nouveau commentaire
Raison: