Discussion :

[Guesset]

Bonjour CGI,

Tu as pris une phrase au milieu. Relis bien les lignes précédentes et suivante de ta citation dans ton lien. Ça concerne des applications ou on force la limitation avec une option de link.

Dont acte et merci.

Comme les adresses ne sont pas obligées de se suivre (elles sont virtuelles), alors le risque existe - vraisemblablement faible - d'une adresse nécessitant plus de 53 bits et le point soulevé par dalfab ne peut être négligé.

Salut

[yvde01]

Bonjour à tous et merci pour vos retours.

Guesset:
Ton idée de mappage en mémoire partagée serait intéressante. Après ton message j'ai regardé très rapidement si mql offrait une telle solution mais à première vue pas vraiment.
Il faudrait que je prenne le temps pour approfondir la chose.
Concernant la manipulation des couleurs mql offre un type color avec pas mal de fonctions.

kaitlyn:
Tu me parle de ArrayResize qui rend l'enregistrement d'un pointeur invalide. C'est l'idée que je voulais exprimer hier quand je disais <Je comprends bien que, une fois mon tableau créé et son adresse mémoire récupérée, je ne peux ni le déplacé, ni le supprimer ou réalloué la mémoire.>
Tu reviens sur le sujet des informations livrées au compte-goutte et projet top secret.
Ce n'était pas mon objectif premier. Seulement comme je ne programme pas en c++, si j'avais mis mes lignes de codes j'aurais du mettre des commentaires à profusion pour que vous puissiez comprendre quelque chose. J'avais peur de trop charger et que ça devienne trop lourd. Mql est très spécifique et possède une quantité innombrable d'objets, de classes et de fonctions de tout genre.
Je pensais que ma demande serait toute simple, qu'il existait une fonction déjà existante et qu'il n'y aurait pas autant de polémique.

bacelar:
Pour ta solution de sauvegarde dans un fichier, j'avais déjà émis cette idée au début.
Au vu de tout ce qui a été dit ici, je pense que je vais probablement m'orienter dans cette direction
De quel MQL on parle ? mql5. Je n'aime pas trop la vodka, surtout ces temps. Mais à mon avis c'est la meilleure plateforme.
Si je ne fais erreur, selon la doc, mql n'a que des pointeurs pour les objets et pas pour de simple variable. Et comme je viens de le dire, je pensais que mon idée présentée ici serait plus simple que de faire un objet juste pour un tableau. Mais à voir...

[koala01]

@yvde01:

Ce qu'il faut vraiment te mettre en tête, pour ta propre santé mentale, c'est que tu as déjà énormément de possibilités de te "tirer une balle dans le pied" avec le C++.

Rien que ce simple fait implique qu'il faut savoir exactement ce que l'on fait, pourquoi et dans quelles conditions afin de choisir la "bonne" manière de faire.

Si, lorsqu'il y a -- en plus -- des communications interprocess, ou qu'il est question de "mémoire partagée" entre différents éléments dont on a pas la parfaite maîtrise, on part à tous les coups au casse pipe.

On ne peut alors clairement plus se contenter d'approximations (qui sont, en soit, déjà bien plus dangereuses en C++ qu'en tout autre langage), de "je crois que", de "il me semble", "rapide recherche" ou de "a première vue" : Il faut être parfaitement sur de ce que l'on fait, car au sinon, ce n'est plus "seulement" notre propre programme qui risque de poser problème, mais aussi le programme tièrce auquel on fait appel que l'on risque de mettre à mal.

Toutes mes interventions sur cette discussion vont en ce sens : tu as beau être pressé par le temps -- et je peux le comprendre -- le meilleur moyen d'obtenir le résultat que tu souhaites est de ... commencer par te renseigner par les conditions indispensables pour que la communication mise en place entre les deux processus puisse se faire correctement.

Tu ne peux donc pas considérer les deux processus comme des éléments distincts parce qu'il se fait, en l'occurrence, qu'ils dépendent l'un de l'autre, et qu'ils ne sont donc, tout simplement, pas distincts

[kick54]

Bonjour,

Sur quel environnement utilise-tu MQL : Trading auto, MongoDB, Tivoli, ... ?
Cordialement

[henderson]

Si, lorsqu'il y a -- en plus -- des communications interprocess, ou qu'il est question de "mémoire partagée" entre différents éléments dont on a pas la parfaite maîtrise, on part à tous les coups au casse pipe.

Je suis d'accord avec toi koala01 !
Mais il y a pire, dans une même process.
Les adresses des données relèvent du monde du CPU alors que les doubles relèvent de la FPU.
Deux mondes différents !
En cas d'union forcée double et long int, on ne sait même pas comment la valeur est stockée dans un double :
1.000.0000 comme tel : bit à bit en binaire ou .... mantisse + exposant ?
Donc c'est osé de récupérer bit à bit le contenu d'un double !
Il faut donc récupérer une valeur entière sous la forme binaire.

Nb : est-ce que c'est le CPU qui construit un double ou est-ce le FPU qui renvoie un double après avoir reçu un entier de même renvoie en entier après avoir reçu un double ?

[Guesset]

Bonjour henderson,

J...Les adresses des données relèvent du monde du CPU alors que les doubles relèvent de la FPU. Deux mondes différents !
En cas d'union forcée double et long int, on ne sait même pas comment la valeur est stockée dans un double : 1.000.0000 comme tel : bit à bit en binaire ou .... mantisse + exposant ?

Un double est un format standard qui est définit indépendamment du langage, de l'OS et des unités de traitements (IEEE85 - Std754). Seul l'endianness perturbe un peu cette belle unité (voir https://en.wikipedia.org/wiki/Double...g-point_format)

Il y a bien longtemps que, pour les PC, les doubles ne relèvent plus seulement de la FPU et qu'on les retrouve dans les SSE, AVX et autres. Il s'avère même que, souvent, l'usage de ces instructions vectorielles soit préféré même pour un double isolé car elles sont un peu plus performantes.

Les adresses ne sont pas l'apanage du CPU (enfin ALU & unité logique puisque tout ce qui est flottant et vectoriel semble exclus). La FPU peut très bien charger des doubles directement depuis la mémoire (i.e. avec l'adresse) avec, entre autres, l'instruction FLD. De même, les instructions vectorielles (SSE, AVX...) avec par exemple l'instruction MOVAPD pour charger des Doubles depuis la mémoire.

Enfin il existe une union en hard dans nos processeurs entre FPU et MMX qui se partagent les mêmes registres pour des flottants et des vecteurs essentiellement d'entiers. De même les instructions vectorielles accueillent dans les mêmes registre des vecteur de byte, word, double word, quad word mais aussi de flottants simples ou doubles.

Je crois que ce qui perturbe est l'assimilation entre contenant et contenu. Le contenant peut être typé mais recevoir sans conversion un contenu d'un autre type (il faut juste qu'il soit assez grand). Bien sûr on ne peut utiliser ce contenu selon le type du contenant mais ce n'est pas fondamental pour du simple stockage. Qui n'a jamais rangé dans une vielle boite de chaussures autre chose, des photos par exemple ? C'est juste du stockage, pas question de marcher avec.

Dans l'union simple que je propose, on stocke et on déstocke toujours avec le bon type, en c/c++ cela pourrait donner cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
...
union double_pint
{
    double   as_double;
    int64_t *as_pint;
} dpCpp, dpMQL;
...
   int64_t u = 123456789;
   dpCPP.as_pint = &u;
   dpMQL.as_double = dpCPP.as_double;    // Simulation de l'appel de la fonction de transfert de l'adresse sous une apparence de double à MQL
   cout << *dpMQL.as_pint << endl;       // Simulation de la récupération de l'adresse de l'entier par MQL
...

Au lieu de se torturer, le plus simple est de tester.

Salut

[henderson]

Tout à fait d'accord avec toi guesset !
Mais dans l'union bit à bit, est-ce qu'on est certain de récupérer les chaussures et non pas la photo des chaussures ?
0xF4240 ou 10^6 ?

[Guesset]

Bonjour henderson,

...Mais dans l'union bit à bit, est-ce qu'on est certain de récupérer les chaussures et non pas la photo des chaussures ? 0xF4240 ou 10^6 ?

Le terme union fait penser à une opération logique "ou" mais en fait c'est simplement un espace mémoire qui accepte différents types de donnée. Il n'y a ni mélange ni partage, c'est la dernière affectation qui impose le contenu. C'est du reste le problème avec l'union : savoir ce qui a été mis en dernier. Utiliser ce contenu sous un type différent de celui du stockage est en général casse-gueule avec le contre-exemple des couleurs sous forme d'entier non signé de 32 bit et ses composantes

Pour ta question sur les photos, si tu as déjà mis une photo de paysage dans une boite de chaussure et que tu y as retrouvé la photo d'une paire de chaussures, tu es le profil d'exception qui ne pourra pas utiliser l'union

Dec, Hex, Double : 1000000 <=> 0x00000000000F4240 <=> 4.94065645841247E-318 (dans les deux sens bien sûr car la même représentation binaire))
Double, Hex, Dec : 1000000.0 <=> 0x412E848000000000 <=> 4696837146684686336

Salut

[Médinoc]

Le gros problème de union-cast un pointeur en double, c'est que si la valeur du pointeur un beau jour est un signaling NaN, le seul fait de charger cette valeur pour la transporter peut causer un crash.

@yvde01 Au strict minimum, d'après ce lien posté plus tôt, MQL semble être capable d'échanger des chaînes de caractères. Transmettre la représentation en texte de (uintptr_t)monPointeur, bien que loin d'être optimal, permet déjà d'éviter les pires écueils du passage sous forme de double.

[Guesset]

Bonjour Médinoc,

Le gros problème de union-cast un pointeur en double, c'est que si la valeur du pointeur un beau jour est un signaling NaN, le seul fait de charger cette valeur pour la transporter peut causer un crash...

L'expression même "union-cast" ne convient pas car il n'y a pas de cast. Il n'est pas question ici d'utiliser un contenu mis sous une déclaration dans le cadre d'une autre déclaration. Or c'est que qui est fait quand on suppose qu'un NaN (double) est utilisé comme adresse.

Par ailleurs NaN ne correspond pas a une seule configuration binaire. Il faut que l'exposant soit à sa valeur maximale 0x7FF (soit 2¹¹-1 pour 0x400 = 1024) ) et que la partie décimale de la mantisse diffère de 0.

Petit programme d'illustration : Nombre_64_bits.zip

Les hexadécimaux s'y expriment en notation Pascal ($ en lieu et place de 0x).

Sauf erreur, seule la valeur 0 à la même représentation en double et entier.

Salut