Questions d'un "mannequin - page 14

Nouveau commentaire
 

Voici une autre chose à laquelle vous pouvez penser. Faites-le !// Rapporter les résultats. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

Je suis honnêtement déconcerté, les gars. Vous vous amusez juste sur un terrain de jeu égal. Absolument pas.

Je voulais juste m'excuser et m'immiscer dans cette conversation "sérieuse". Mais pendant que j'allais chercher des cigarettes, j'ai été battu.

Et ce n'est pas comme si nous étions des "idiots", n'est-ce pas ? Et ce "boo-boo-boo" a été fait à partir de rien.

Dans la classe CExpert, je le corrigerai en ulong.

 
Renat:

Vous avez tort.

Oui, j'ai oublié la conversion de type.

 
uncleVic:

Et ce n'est pas "les nuls", n'est-ce pas ?

Je suis un imbécile à bien des égards. Je ne comprends donc pas comment les fonctions destinées à renvoyer un long renvoient ULONG_MAX-1. Les pièges d'une manipulation superficielle des types d'entiers sont décrits presque dans le manuel lui-même. sergeev a bien saisi la raison de la question: le contrôle des ordres. Si je donne à request.magic le type ulong, je m'attends à ce que les fonctions HistoryDealGetInteger(), PositionGetInteger() et OrderGetInteger() renvoient également le type ulong. Sans aucune conversion de type explicite-implicite.

Cependant, sises exemples expliquent que les conversions de type long<->ulong n'entraînent pas de perte de valeurs (contrairement à double -> int, par exemple), alors la suite de la réflexion devient claire.

oncleVic:

Et un tel "bobo" a été créé sur un espace vide.

En fait, le fil "Questions de Dummie" a été choisi pour obtenir des explications, pas des remontrances.

 
Yedelkin:

Je suis un imbécile pour beaucoup de choses. Je ne comprends donc pas comment les fonctions censées renvoyer un long renvoient ULONG_MAX-1. Les pièges d'une manipulation superficielle des types d'entiers sont décrits presque dans le manuel lui-même. sergeev a bien saisi la raison de la question: le contrôle des ordres. Si je précise que request.magic est de type ulong, je m'attends à ce que les fonctions HistoryDealGetInteger(), PositionGetInteger() et OrderGetInteger() renvoient également un type ulong. Sans aucune conversion de type explicite-implicite.

Cependant, sises exemples expliquent que les conversions de type long<->ulong n'entraînent pas de perte de valeurs (contrairement, par exemple, à double -> int), alors la suite de la réflexion devient claire.

En fait, le fil de discussion "Questions de Dummie" a été choisi dans un but d'élucidation, et non de réprimande.

Offensé ? Désolé, je n'ai pas pu m'en empêcher.
 
uncleVic:
Êtes-vous offensé ? Désolé, je n'ai pas pu m'en empêcher.
Non, je ne le suis pas. J'ai eu ma part de batailles sur internet. J'essaie toujours d'orienter la discussion dans une direction constructive, pour ainsi dire.
 
sergeev:

En fait, ce n'est pas 64 mais seulement 63 bits (c'est-à-dire 8 octets incomplets). 8 octets le seraient si toute la gamme longue était utilisée.

Mais malheureusement...

D'une part, un ulong magique est passé dans la structure MqlTradeRequest. Cela signifie que seules des valeurs positives peuvent être définies.

En revanche, lesfonctions PositionGetInteger/OrderGetInteger renvoient le type long. Cela signifie que la moitié de la gamme ulong est coupée.

Au total, nous avons 63 bits au lieu des 64 bits décrits ci-dessus. En fait, ce n'est pas tant une mauvaise chose qu'un grand inconvénient pour les principes du contrôle des ordres.

Il serait beaucoup plus confortable d'utiliser le même système que dans MT4 - autoriser les magiciens avec un signe. Étant donné que de nombreux systèmes de trading reposent sur un principe simple utilisant le symbole même d'un magicien. Il est en effet beaucoup plus facile de diviser un système en deux et de filtrer vos ordres à l'aide de la fonction habituelle MathAbs( OrderMagicNumber() ).

tous les 64. En fait. Ne vous accrochez pas à un type signé ou non signé. Cela permet au compilateur de s'assurer que les opérations arithmétiques sont correctes (et qu'il y a un décalage du bit droit vers la logique ou l'arithmétique, selon les valeurs signées).

Aucune information n'est perdue lors du transfert (affectation) et des moulages sans signe de données de même taille. Essayez de faire rebondir ULONG_MAX d'avant en arrière. Essayez l'affectation long-ulong et retour. Essayez de copier la structure.

La meilleure chose à faire est de s'en assurer soi-même. La question sera alors résolue une fois pour toutes.

 
MetaDriver:

Voici une autre chose à laquelle vous pouvez penser. Faites-le !// Rapporter les résultats. ;)

C'est fait ! Remplacez la ligne 14 du code par L.l = 4548887299649496524.

Il ressort de la description de la structure MqlTradeRequest que la magie est de type ulong, c'est-à-dire qu'on peut lui attribuer des valeurs supérieures à la valeur constante LONG_MAX. Cependant, les fonctions du ... Les fonctionsGetInteger() sont conçues pour fonctionner avec le type long, les valeurs magiques seront donc implicitement converties en type long par ces fonctions. Mais comme il existe une correspondance biunivoque entre les variables de type long et ulong, lorsqu'on compare la valeur magique avec le résultat renvoyé par les fonctions de type ...GetInteger() ,nous pouvons utiliser en toute sécurité une conversion de type explicite (par exemple : magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Merci d'avoir montré à plusieurs reprises des exemples.

 

stringo:

Lors du transfert (assignation) de données, ainsi que lors du coulage sans signe de données de même taille, aucune information n'est perdue nulle part. Essayez de faire rebondir ULONG_MAX d'avant en arrière. Essayez l'affectation long-ulong et retour. Essayez de copier la structure. Convainquez-vous et ne répandez pas de mythes.

Je l'ai déjà essayé et il renvoie le résultat nécessaire en forçant le type (bon, peut-être qu'il faudra encore faire une "danse avec les diamants" en plus). Mais ce n'est pas si important).

oncleVic:

Je vais changer la classe CExpert en ulong.

Je pense que c'est une bonne idée, ceux qui utilisent des valeurs négatives en magie devront obligatoirement spécifier ce qu'ils doivent retourner/régler.

Il serait également très agréable que la documentation n'indique pas seulement long ou ulong, mais les deux types (par exemple "long / ulong").

 
stringo:

Aucune information n'est perdue au cours du transfert de données (affectation), ou au cours des castings de données demême taille sans affectation de caractères.

Une question supplémentaire : existe-t-il un moyen élégant de préserver les informations lors du transfert double -> long ?
1...789101112131415161718192021...277
Nouveau commentaire