Discussion :

[yvde01]

Merci koala01 pour tes préoccupations concernant mon programme.

Je crois que j'ai une certaine difficulté à m'expliquer.
Comme on dit, un dessin vaut mieux que mille explications.
Donc voici schématiquement ce que je cherche à faire.



Mon problème est les points 4) et 7).
mintho carmo me faisait remarquer le problème de l'espace mémoire non partagé.
Je confirme que l'espace mémoire est partagé et que mon tableau est utilisable des 2 côtés. C'est juste le transfert qui est quelque peu complexe.

Le transfert de mon tableau entre la partie1 et 2 ne peut se faire que par une variable double, je n'ai pas le choix.
Je rappelle que ce transfert passe par une variable globale déjà existante de type double, ce n'est pas moi qui la créée et je suis obligé de m'y adapter.
Malgré mes maigres connaissant d'informatique, je ne crois pas que je puisse rentrer un tableau dans une variable globale.
Donc je ne vois pas d'autre solution que de transférer un pointeur "décimal" dans cette variable globale.

Si mes transformations hexa->décimal et décimal->hexa sont correctes et que la valeur hexa de ma 2eme transformation est exactement identique à la valeur de départ (condition sine qua non) je ne vois pas ou est le problème pour la récupération de mon tableau par mon pointeur.

Merci de me dire si je me fourvoie complètement. Dans ce cas je cherche une autre solution. Mais, d'après mes autres recherches, je reste convaincu que ma solution est viable.

Avec mes remerciements et salutations.

[kaitlyn]

Salut tout le monde.

Ce que tu cherches à faire s'appelle un calembour de type, ou perversion de type (type punning en anglais).
Le C++ est très strict là-dessus et les risques de comportement indéfini nombreux.
C'est dommage d'en arriver là d'autant plus qu'une référence, techniquement, est un pointeur.
Donc oui, il existe assurément une meilleure solution.

Ne sachant pas dans quel sens se font tes échanges entres tes modules (tes DLLs, ton application), ni qui génère tes données, qui les utilise, le minimum vital quoi, même si j'ai ma petite idée là-dessus, je ne vais pas prendre le risque de faire une proposition pour lire ensuite que ce n'était pas le bon cas de figure. Comme ceci est mon seul message sur ce fil, je n'aurais pas répondu de toute façon.

Bref, voici la solution la plus simpliste et portable que je vois au problème de la solution Y que tu as imaginé pour résoudre X.
ET oui, encore le fameux "problème XY".

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream> //to print via  std::cout
 
int main()
{
    double number= 12345.6;
    std::cout << number<< '\n';
 
    double* address_of_number= &number;
    std::cout << address_of_number<< '\n';
 
    double dummy_address_of_number= 
        static_cast<double>(reinterpret_cast<unsigned long long>(&number));
    std::cout << dummy_address_of_number<< '\n';
 
    double* reinterpreted_address= 
        reinterpret_cast<double*>(static_cast<unsigned long long>(dummy_address_of_number));
    std::cout << reinterpreted_address<< '\n';
 
    std::cout << *reinterpreted_address<< '\n';
    std::cout << reinterpreted_address[0]<< '\n';
}

Pour ceux qui se posent la question, dans le code j'utilise un entier intermédiaire dont la taille minimale est garantie pour ne pas perdre de l'information.

Voici un exemple de sortie :

Code :

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

1
2
3
4
5
6
12345.6
0x7fff09f2d0b8
1.40733e+14
0x7fff09f2d0b8
12345.6
12345.6

[dalfab]

Merci koala01 pour tes préoccupations concernant mon programme.

Je crois que j'ai une certaine difficulté à m'expliquer.
Comme on dit, un dessin vaut mieux que mille explications.
Donc voici schématiquement ce que je cherche à faire.



Mon problème est les points 4) et 7).
mintho carmo me faisait remarquer le problème de l'espace mémoire non partagé.
Je confirme que l'espace mémoire est partagé et que mon tableau est utilisable des 2 côtés. C'est juste le transfert qui est quelque peu complexe.

Le transfert de mon tableau entre la partie1 et 2 ne peut se faire que par une variable double, je n'ai pas le choix.
Je rappelle que ce transfert passe par une variable globale déjà existante de type double, ce n'est pas moi qui la créée et je suis obligé de m'y adapter.
Malgré mes maigres connaissant d'informatique, je ne crois pas que je puisse rentrer un tableau dans une variable globale.
Donc je ne vois pas d'autre solution que de transférer un pointeur "décimal" dans cette variable globale.

Si mes transformations hexa->décimal et décimal->hexa sont correctes et que la valeur hexa de ma 2eme transformation est exactement identique à la valeur de départ (condition sine qua non) je ne vois pas ou est le problème pour la récupération de mon tableau par mon pointeur.

Merci de me dire si je me fourvoie complètement. Dans ce cas je cherche une autre solution. Mais, d'après mes autres recherches, je reste convaincu que ma solution est viable.

Avec mes remerciements et salutations.

Il y a des étapes qui n'ont aucun sens.

Etape 4) : Transformer de l'hexa en décimal!
Un nombre est un nombre, et un pointeur (ou une adresse) est aussi un nombre. On ne parle de base que quand on veut voir ce nombre, on le converti en un texte composé d'une séquence de "chiffres". Par exemple en base décimale, hexadécimale, octale ou binaire. Dans un programme il n'y a rien de décimal, pour les humains les nombres sont affichés le plus souvent en base décimale. En mémoire les nombres sont sous la forme des tableaux de bits.
Donc le pointeur qui est un nombre obtenu à l'étape 3, peut être directement passé à l'étape 5 qui attend un nombre.

Etape 5) : sauvegarder le valeur d'un pointeur dans un double!
La mémoire d'un pointeur nécessite 64 bits. Un double a lui aussi une taille de 64 bits, mais ne peut mémoriser que 53 bits. Toute conversion d'un pointeur en double ne se fait qu'avec perte d'information. Avec un artifice complexe, on peut faire qu'un double soit porteur sain de 63 bits, mais 64 bits c'est impossible!

Passage de l'étape 5 à l'étape 6.
Tu indiques que l'espace mémoire est partagé et tu parles de transfert! En es-tu vraiment sûr? Si l'espace est partagé c'est que la partie 2 peut voir les données de la partie 1 (on est donc dans une unique application, ou deux application qui ont une zone commune), et alors pourquoi la partie 2 pourrait voir le tableau mais pas un simple pointeur? Et pourquoi alors un seul double serait transférable?
Et tu supposes mal, un tableau peut tout à fait être mis dans une variable globale en C++.
Il nous faut plus d'explication.

Etape 7.
Même commentaire que pour l'étape 4. N'a pas de sens.

Et dans quels langages sont les parties 1 et 2?

[mintho carmo]

@kaitlyn On lui a deja conseillé les casts.

@dalfab Pour les étapes 4 et 7, je pense qu'il s'est juste mal exprimé et que la conversion dont il parle est le cast.

Pour le 5, a priori, je pense que tu as tort. Cf par exemple le code de kaitlyn

Par contre, pour la variable globale, tu as raison, aucune raison que ca ne soit pas utilisable.

@yvde01 kaitlyn a raison, mon code manquait un cast intermediaire. Je dirais plus d'utiliser un size_t plutot que unsigned long long mais c'est pareil

[koala01]

Merci koala01 pour tes préoccupations concernant mon programme.

Je crois que j'ai une certaine difficulté à m'expliquer.
Comme on dit, un dessin vaut mieux que mille explications.
Donc voici schématiquement ce que je cherche à faire.



Mon problème est les points 4) et 7).

Bien pire que cela!
Les étapes 3, 4 et 7 démontrent clairement que tu ne comprends absoluement pas ce qui se passe entre le binaire, l'hexadécimal et le décimal. Mais bon, ca, ce n'est même pas le plus embêtant.

Le véritable problème, c'est que tu te retrouve avec des pommes (ton pointeur) à l'étape 3, que tu veux le faire passer pour des potirons (le double) à l'étape 5, dans l'espoir d'obtenir ... de la soupe de potirons, sans doute, à l'étape 6 que tu t'empressera de faire passer pour ... de la compote de pommes à l'étapes 7 dont tu espères récupérer les pommes à l'étape 8.

Comment espère tu que cela puisse fonctionner sous cette forme

Si ce qui se passe entre l'étape 5 et l'étape 6 s'attend effectivement à manipuler des potirons, les étapes 3 et 4 doivent faire en sorte que ce soit bien ... des potirons qui seront transmis. Et les étapes 7 et suivantes doivent faire en sorte que les potirons obtenus en résultats soient utilisable par le reste du processus.

Mais si tu essaye de "truander" le système en lui disant que tes pommes sont des potirons, cela n'a absolument aucune chance de fonctionner. Cela peut compiler. Il se peut même que ton programme ne plante pas. Mais tu ne pourras pas apporter la moindre confiance au résultat parce que le système lui-même n'aurais pas du te faire confiance en acceptant ce que tu as "fait passer pour" des potirons.

mintho carmo me faisait remarquer le problème de l'espace mémoire non partagé.
Je confirme que l'espace mémoire est partagé et que mon tableau est utilisable des 2 côtés. C'est juste le transfert qui est quelque peu complexe.

En tout état de cause, partir du principe que la mémoire est partagée nous facilitera la tâche

Le transfert de mon tableau entre la partie1 et 2 ne peut se faire que par une variable double, je n'ai pas le choix.

Il n'y a donc rien à faire, tu dois définir la valeur de cette variable sous la forme d'un double. MAIS TU NE DOIS PAS ESSAYER DE TRUANDER le système en essayant de faire passer un pointeur pour un double.

Un peu plus tôt, tu nous as dit que ton pointeur était l'adresse d'un tableau contenant des double. Peut-être y a-t-il quelque chose à faire à partir de là, par exemple:
copier le assigner la valeur du premier élément du tableau à cette variable, puis, pour chaque élément du tableau, en assigner la valeur "au double suivant". Cela pourrait se représenter sous une forme proche de

Code :

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

1
2
3
 Variable_globale | Globale+1 | Globale+2 |...
|-----------------|-----------|-----------|----------
|    tab[0]       |  tab[1]   | tab[2]

A l'extrême limite, ca, ca serait encore *** assez facile *** à faire...

Il suffirait en effet d'une code proche de

Code :

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

1
2
3
4
5
6
7
8
9
double * ptrGlobal = &VariableGlobale;
/* je considère que ton tableau est de type std::vector pour pouvoir
 * utiliser les "range based loops", mais une boucle pour toute simple ferait
 * parfaitement l'affaire  ;-)
 */
for( double d : tableau){ // pour chaque élément d du tableau
    *ptrGlobal=d; // on assigne la valeur de d à la variable pointée par le pointeur
    ++ptrGlobal ; // on passe à l'adresse suivante pour l'élément suivant
}

Et, de la même manière, la récupération des valeurs après traitement se ferait tout aussi simplement avec un code proche de

Code :

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

1
2
3
4
5
6
double * ptrGlobal = &VariableGlobale;
/* même remarque que plus haut */
for (double & d : tableau){ pour chaque élément d du tableau, pris par référence
    d=*ptrGlobal; // on assigne à l'élément la valeur trouvée à l'adresse pointée par le pointeur
    ++ptrGlobal; // on passe à l'adresse suivante pour l'élément suivant
}

MAIS, et c'est là que je coince: ce code part des prémisses que

1. la variable globale représente la première variable de type double qui sera utilisée (sous entendu, qu'elle est suivie par d'autres données qui seront utilisées dans le même but)
2. qu'il y a assez de mémoire réservée à l'usage qui en sera fait que pour me permettre de représenter toutes les valeurs de mon tableau, sans risquer d'écraser des données utilisées à une autre fin

Autrement dit, je m'en veux énormément de te proposer ce genre de solution parce que je sais que, avec de telles prémisses, il y a neuf chances sur dix pour que ces deux codes provoquent un plantage magistral de ton programme.

Je pourrais m'en foutre... Après tout, c'est toi qui demande une solution, et je te l'ai donnée... Et, surtout, c'est toi qui te fera taper sur les doigts quand ton programme aura provoqué la perte de millions de dollars ou la mort de centaines de personnes

Mais bon, quand on est développeur professionnel, et qu'on a un minimum d'éthique, on essaye quand même de proposer des solutions un minimum correctes à ceux qui viennent demander de l'aide

Je rappelle que ce transfert passe par une variable globale déjà existante de type double, ce n'est pas moi qui la créée et je suis obligé de m'y adapter.

Et je l'ai bien compris ...

Ce que toi, tu n'as pas l'air de comprendre, c'est que pour pouvoir t'adapter à ton environnement, il faut que tu aies une compréhension minimale de cet environnement; que tu ne peux pas agir, comme dans la nature, par essais et erreurs et risquer de faire cent fois une erreur avant de tomber "par hasard" sur la solution adéquate.

D'abord parce que tu n'as pas le temps à consacrer aux centaines d'essais infructueux
Ensuite, parce que chaque essais infructueux va couter de l'argent
Enfin, parce que ton employeur attend de toi que tu lui apporte une solution correcte, et qu'il n'appréciera sans doute pas trop de voir échouer une centaines de tentatives

Malgré mes maigres connaissant d'informatique, je ne crois pas que je puisse rentrer un tableau dans une variable globale.

Ca, nous sommes bien d'accord...

Ce n'est cependant pas une raison pour essayer d'y faire rentrer un pointeur, surtout si la variable globale en question est un double.

Simplement parce que, si on fait une différence entre les types double, entier et pointeur en informatique, c'est qu'il y a une bonne raison : ces types de données ne se manipulent absoluement pas de la même manière, et vouloir manipuler l'un d'eux "comme si c'était l'un des autres" ne mènera jamais qu'à un seul et unique résultat : une catastrophe annoncée.

Donc je ne vois pas d'autre solution que de transférer un pointeur "décimal" dans cette variable globale.

C'est surtout que tu dois en arriver à avoir une vue suffisamment vaste du problème que pour arriver à comprendre comment manipuler les données dont tu dispose pour qu'elles puissent correspondre à ce qu'attend "la partie tierce".

Tu es arrivé ici en étant persuadé que ta seule solution est de convertir un pointeur en double.

Je suis persuadé, et j'ai 99.999% de chance d'avoir raison (je suis généreux, je me laisse 0.001% d'incertitude ) que ce n'est pas ce que tu dois faire, et que seule une compréhesion de ce qui se fait "autour de tes données" pourra t'aider à savoir comment les manipuler correctement.

Si mes transformations hexa->décimal et décimal->hexa sont correctes et que la valeur hexa de ma 2eme transformation est exactement identique à la valeur de départ (condition sine qua non) je ne vois pas ou est le problème pour la récupération de mon tableau par mon pointeur.[/
Merci de me dire si je me fourvoie complètement. Dans ce cas je cherche une autre solution. Mais, d'après mes autres recherches, je reste convaincu que ma solution est viable.

Je vais passer sur le problème de la "transformation" pointeur ->hexa ->décimal et des manipulations inverse, Daflab ayant bien expliqué ce qu'il en est

Je viens par contre de t'expliquer pourquoi ta solution ne me semble pas fiable, et je pourrais sans doute encore argumenter d'avantage

Tout ce que je peux dire, c'est que si l'expérience m'a appris quelque chose -- et tu peux me croire sur parole: j'en ai un paquet -- c'est qu'on ne peut pas se permettre d'être optimiste en développement informatique. On ne peut pas simplement partir du principe que

A priori, ca marche

Au contraire, il faut partir du principe que

Tout ce qui peut foirer dans le code foirera forcément à un moment ou à un autre, et, de préférence, au pire moment qui soit

Car l'histoire regorge d'exemple où cela a effectivement été le cas

Et, de ce fait, il faut agir en conséquence, et partir du principe que ... si on n'a pas la certitude, si on n'a pas la preuve que ce que le code que l'on écrit ne posera aucun problème, c'est qu'il va -- forcément -- en poser un à un moment ou à un autre.

Dans le cas présent, il y a beaucoup trop d'inconnues, parce que l'on ne sait rien à propos de la "variable globale" dont tu nous parle, à propos de "l'autre langage" qui devra la manipuler, ou encore du genre de manipulations qui seront entreprises, que pour seulement oser espérer que ton code ne posera pas problème.

Il n'y a même pas besoin de savoir quel genre de problème il risque de poser! Le simple fait de n'avoir pas la garantie qu'il ne posera aucun problème implique qu'il va -- forcément -- en poser un à un moment ou à un autre, et cela nous suffit pour, à tout le moins, nous inciter à la prudence.

[yvde01]

Merci les gars, je crois qu'on arrive gentiment à la solution.

kaitlyn
je n'ai pas encore eu le temps de tester ton code mais il me semble que tu es en plein dans le tire.

dalfab
Le langage des parties 1 et 2 est MQL. J'ai un graphique dans la partie 1, un autre dans la partie 2 qui utilise des données de 1.
MQL est ainsi fait qu'il n'y a pas de liaison directe entre les graphiques. Seul des variables globales (type double) sont accessibles des 2 côtés. Et, comme je l'ai déjà formuler avant, il ne connait pas les pointeurs non plus. Incompréhensible pour moi, mais je n'y peux rien. Sinon je ne serait pas ici à m'empêtrer avec cette conversion. Donc j'essaye de contourner le problème avec c++.
Ta remarque étape 4): je ne savait pas que l'on pouvait passer une valeur hexadécimale dans une variable double directement, sans faire un cast. Je pense que mintho carmo est dans le juste. Quand je parle de conversion en fait c'est un cast.
Ta remarque étape 5): tu as certainement raison. Donc un cast est indispensable.

[yvde01]

koala01
Je crois que nos messages se sont croisés. Je n'avais pas vu le tient avant d'envoyer le mien.
Je ne suis pas sure d'avoir tout compris avec ton histoire de pommes et de potirons.
Si je résume:
j'ai un tableau en 1, j'aimerais récupérer ce tableau en 2. Le hic est que je ne peux pas passer ce tableau directement.
C'est comme si je crée un tableau dans une fonction et que j'aimerais utiliser ce tableau dans une autre fonction mais sans pouvoir le passer par référence parce que cette fonction n'accepte qu'une variable double.

Il me semble que mon tableau ne va pas changer d'adresse mémoire. Dit-moi si je me trompe?
Donc si je passe un pointeur de 1 à 2, ou d'une fonction à l'autre, je ne vois pas pourquoi je ne peux pas atteindre mon tableau par mon pointeur.
Maintenant comment je peux passer mon pointeur par l'intermédiaire d'une variable double? Toute la question est là.
Tu écris: <Il n'y a donc rien à faire, tu dois définir la valeur de cette variable sous la forme d'un double>.
Si je comprends bien c'est le cast qui te froisses. kaitlyn allait dans le même sens.

Tu reviens avec ta proposition de transférer élément par élément, comme tu me l'as déjà proposé auparavant.
Comme je l'ai déjà dit, c'était ma première idée mais elle me semblait difficilement réalisable. Nombre d'éléments à transférer (plus de 20000), temps de transfert, variables globales disponible, etc.
Je pensais que l'idée du pointeur était plus judicieuse. Mais je suis entrain de m'apercevoir que ce n'est pas forcément le cas.

[kaitlyn]

Salut tout le monde

Je dirais plus d'utiliser un size_t plutot que unsigned long long mais c'est pareil

Dans ce cas particulier, c'est important de le souligner, size_t ne convient pas mintho carmo. Pour au moins 2, 3, 4, 4 raisons, la plus importante étant que sa taille minimale garantit n'est que de 16 bits. Du coup on aurait un code plus complexe.

Je vais passer sur le problème de la "transformation" pointeur ->hexa ->décimal et des manipulations inverse, Daflab ayant bien expliqué ce qu'il en est

Non, il confond la représentation d'un double en mémoire avec son interprétation par l'unité de calcul dédiée.

[koala01]

koala01
Je crois que nos messages se sont croisés. Je n'avais pas vu le tient avant d'envoyer le mien.
Je ne suis pas sure d'avoir tout compris avec ton histoire de pommes et de potirons.

L'idée derrière cette histoire, c'est de te faire comprendre que la différence qui existe entre un pointeur et un double est ... sensiblement la même que celle qui existe entre une pomme et un potiron: les deux n'ont absolument rien à voir car on ne peut -- tout simplement -- pas les traiter de la même manière.

A partir de là, si on se dit qu'un pointeur est "la représentation informatique" d'une pomme et qu'un double est celle d'un potiron, les manipulations "correctes et cohérent" (on pourrait dire "attendues") qui seraient entreprises à partir de ces deux types (totalement différents) de donnée, reviendraient, en gros, à vouloir obtenir de la compote de pommes à partir de nos pommes (nos pointeurs) OU de la soupe de potirons à partir de nos potirons (nos double).

Or, toi, tu nous dis "je veux transmettre mon pointeur sous la forme d'un double", et ce, dans le but -- faut il quand même le signaler -- qu'il soit (a priori) manipulé comme ... un double.

Autrement dit, tu veux ... faire passer ta pomme (ton pointeur) pour un potiron (un double). Et la question est donc : mais qu'espères tu en obtenir, si ce n'est de la soupe de potiron?

Et, comme si cela ne suffisait pas (crois tu vraiment pouvoir obtenir de la soupe de potirons "simplement" en faisant passer des pommes pour des potirons ) tu nous dis que, après le traitement, tu espères bien utiliser le potiron (le double) --qui sera devenu soupe de potiron du fait du traitement -- pour en récupérer la pomme (le pointeur) alors que, du fait qu'il y a eu traitement, tu ne peux -- au mieux (en considérant que le traitement eut été adapté à des pommes) -- espérer obtenir de la compote.

J'espère que tu te rend compte que l'histoire que je viens de raconter à propos des pommes et des potirons n'a ... absolument aucune logique. Nous sommes d'accord sur ce point

Hé bien dis toi que, plutôt que de me lancer dans une diatribe -- comme je suis pourtant capable de le faire -- pour te faire comprendre la différence technique qui existe entre deux concepts finalement "très abstraits" que sont les notions de pointeurs et de double, j'ai choisi de faire la comparaison avec des notions finalement beaucoup plus concrètes, que tu peux toucher tous les jours : des pommes, des potirons et le résultat de leur transformation : la compote de pommes et la soupe de potirons.

Et comme l'histoire reste fondamentalement la même, j'espérait te faire comprendre que ce que tu voudrais faire avec ton pointeur et ton double est ... Tout aussi illogique que l'histoire de pommes et de potirons que je t'ai racontée.

Si je résume:
j'ai un tableau en 1, j'aimerais récupérer ce tableau en 2. Le hic est que je ne peux pas passer ce tableau directement.
C'est comme si je crée un tableau dans une fonction et que j'aimerais utiliser ce tableau dans une autre fonction mais sans pouvoir le passer par référence parce que cette fonction n'accepte qu'une variable double.

Et je résume encore une fois : c'est donc que ce n'est pas le tableau que tu dois transmettre, mais ... le résultat d'une transformation "logique" de celui-ci.

Ce que tu veux faire n'ayant aucune logique, ca ne peut en aucun cas être ta solution. C'est ... aussi simple que cela.

Tu pourras danser sur la tête en me jurant tes grands dieux que tu es sur que c'est ce que tu dois faire, tant que tu ne m'auras pas apporté la preuve par A + B que "l'autre partie" s'attend effectivement à obtenir sous la forme d'un double ce qui se rapproche le plus de la notion de pointeur dans le langage utilisé par cette partie, tu n'arriveras pas à m'en convaincre, parce que toute mon expérience me met en garde contre l'optimisme prématuré face à une confiance mal placée.

Il me semble que mon tableau ne va pas changer d'adresse mémoire.

Tout est dans ce mot : il TE SEMBLE ...

Cela signifie que tu ne peux absolument pas le jurer...

Dit-moi si je me trompe?

A partir du moment où tu n'as aucune certitude que ton tableau ne changera pas d'adresse, il y a de fortes chances pour que tu te trompes effectivement.

Donc si je passe un pointeur de 1 à 2, ou d'une fonction à l'autre, je ne vois pas pourquoi je ne peux pas atteindre mon tableau par mon pointeur.

Parce que tu n'a aucune garantie quant à ce que font les différentes fonctions...

Avec "un peu de chance", elles ne toucheront pas à ton tableau en tant que tel.

Seulement, comme tu ne peux pas me le garantir, il se peut "tout aussi bien" que la deuxième fonction décide de libérer la mémoire du tableau ou ... de la réallouer "ailleurs", pour quelque raison que ce soit.

Ce qui implique que, si tu essaye d'accéder à l'adresse mémoire à laquelle se trouvait le tableau avant que la deuxieme fonction ne s'exécute, tu as de très fortes chances de faire planter ton programme.

Maintenant comment je peux passer mon pointeur par l'intermédiaire d'une variable double? Toute la question est là.

Tu ne dois pas le faire...

Et pire encore : la question n'est absolument pas là!

Les véritables questions sont :

1. quel type de donnée se trouve à l'adresse indiquée par mon pointeur
2. combien de ces données composent le tableau
3. comment puis-je transmettre ces données sous forme de double (si les données composant le tableau ne sont déjà pas des double)
4. combien de ces données puis-je transmettre en une fois

Et, comme je te l'ai déjà dit : le seul moyen d'apporter une réponse à ces questions est ... d'avoir un apperçu minimal de ce qui va se passer dans "l'autre partie".

Tu écris: <Il n'y a donc rien à faire, tu dois définir la valeur de cette variable sous la forme d'un double>.
Si je comprends bien c'est le cast qui te froisses. kaitlyn allait dans le même sens.

Soyons clairs : il y a énormément à dire au sujet du cast ... Je vais cependant résumer l'estime dans laquelle je tiens cette notion en trois points:

1. n'utilises jamais cette technique !
2. Si tu crois ne pas avoir d'autre choix, n'utilises quand même jamais cette technique!
3. En cas de doute, réfères toi aux règles 1 et 2

Ca va Cela te permet il de te faire une idée précise de ce que je pense du cast

Et pourtant, ce n'est pas l'idée de recourir au cast qui m'ennuie le plus.

Ce qui m'ennuie le plus dans ton histoire, c'est que tu n'as absolument aucune idée de ce qui va arriver au double lorsqu'il sera traité par l'autre partie.

Cela implique que tu ne sais absolument pas s'il y a des "valeurs limites" à ne pas dépasser dans un sens ou un autre

Cela implique que tu ne sais absolument pas s'il y a des valeurs totalement invalides qui pourrait faire exploser le système

cela impllique que tu n'as absoulement aucune idée du résultat auquel tu dois t'attendre après que la deuxième partie ait fini son traitement.

Ajoute à cela l'idée même d'avoir recours à une technique dont l'usage est (je crois avoir été clair là dessus ) grandement réprouvé, et tu te rendras compte (ou du moins, tu devrais te rendre compte) qu'il y a décidément beaucoup trop de questions qui attendent une réponse avant de pouvoir espérer aller plus loin.

Tu reviens avec ta proposition de transférer élément par élément, comme tu me l'as déjà proposé auparavant.
Comme je l'ai déjà dit, c'était ma première idée mais elle me semblait difficilement réalisable. Nombre d'éléments à transférer (plus de 20000), temps de transfert, variables globales disponible, etc.

Je te l'ai dit plus haut : il faut que tu nous aides à t'aider, car tu es le seul, sur ce forum, à espérer être en mesure de te faire une idée précise du problème.

Nous, les autres membres du forum, ne disposons que d'informations beaucoup trop fragmentaires, et que toi seul a peut être une chance de compléter.

Toutes les propositions que nous pourrions envisager de te faire ne peuvent se baser que sur les informations dont on dispose. Et donc, plus nous disposerons d'informations, plus nos propositions deviendront cohérentes et pourront avoir une chance d'être judicieuses.

[yvde01]

Koala01,
Ok j'ai bien compris ton image de pomme et potiron.
Je sais pertinemment que je ne peux pas utiliser et traiter un double à la place d'un pointeur et que je vais aux devants de gros problèmes.

Tu écris:
Ce qui m'ennuie le plus dans ton histoire, c'est que tu n'as absolument aucune idée de ce qui va arriver au double lorsqu'il sera traité par l'autre partie.

Je code la partie 2 entièrement (idem pour la 1), donc je sais ce qu'il se passe et que ma valeur double ne sera pas traitée comme telle puisque je la retransforme en pointeur et utilisé comme un vrai pointeur et pas comme un double.

Maintenant, si je te comprends bien, mon tableau pourrait changé d'adresse sans que je le veuille. Effectivement ceci serait très embêtant.
Windows peut-il faire une telle chose?
Dans ce cas à quoi servent les pointeurs si les variables concernées peuvent changés d'adresse. Le pointeur sera forcément faux à chaque fois.

Je peux aussi confirmer que la portée de mon tableau est dans l'entier de la partie 1 et qu'il existe toujours en mémoire dans la partie 2.
Ceci est un postulat, mql est ainsi fait. Et j'ai pu le vérifier mainte fois. Habituellement il n'est pas nécessaire de passer des infos de 1 à 2 mais cette fois j'ai un cas particulier.
Existe-t-il à la même adresse mémoire tout au long de sa vie? J'attends tes commentaires concernant le paragraphe précédent.

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.

Merci pour tes remarques.

[Guesset]

Bonjour dalfab,

...
Etape 5) : sauvegarder le valeur d'un pointeur dans un double!
La mémoire d'un pointeur nécessite 64 bits. Un double a lui aussi une taille de 64 bits, mais ne peut mémoriser que 53 bits. Toute conversion d'un pointeur en double ne se fait qu'avec perte d'information. Avec un artifice complexe, on peut faire qu'un double soit porteur sain de 63 bits, mais 64 bits c'est impossible!

Au sens stricte de la conversion, c'est effectivement impossible. Mais au sens du simple transport de 64 bits sans s'occuper de quoi ce soit à l'intérieur, il est possible d'utiliser une union qui permet de marier carpe et lapin.

Code :

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

1
2
3
4
5
union double_pint
{
    double as_double;
    int   *as_pint;
};

Tout ceci parce que l'union n'alloue qu'un seul espace mémoire (le plus grand des types déclarés à l'intérieur) dans lequel tout le monde se superpose. C'est souvent utilisé dans la manipulation de couleurs tantôt sous forme d'entiers uint32_t, tantôt sous forme de composantes élémentaires uint8_t, (R,V,B,a) par exemple. Cela évite l'usage des décalages multiples en laissant le compilateur se dépatouiller avec cela.

Salut

[Guesset]

Bonjour,

Il y a une autre approche possible sous Windows : les fichiers mappés en mémoire. C'est un espace nommé demandé à l'OS. Or tout objet nommé créé par l'OS est unique. Si l'autre langage est capable d'y accéder (mais je ne connait pas MQL) il n'y a plus à se préoccuper de lui transférer des adresses.

Les fichiers mappés permettent à des applications qui ne partagent pas le même espace mémoire d'avoir malgré tout un espace en commun.

C'est un peu lourd à mettre en place (je ne le fais que sous la contrainte ) mais ça marche.

Salutations

[koala01]

Bonjour dalfab,



Au sens stricte de la conversion, c'est effectivement impossible. Mais au sens du simple transport de 64 bits sans s'occuper de quoi ce soit à l'intérieur, il est possible d'utiliser une union qui permet de marier carpe et lapin.

Code :

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

1
2
3
4
5
union double_pint
{
    double as_double;
    int   *as_pint;
};

Tout ceci parce que l'union n'alloue qu'un seul espace mémoire (le plus grand des types déclarés à l'intérieur) dans lequel tout le monde se superpose. C'est souvent utilisé dans la manipulation de couleurs tantôt sous forme d'entiers uint32_t, tantôt sous forme de composantes élémentaires uint8_t, (R,V,B,a) par exemple. Cela évite l'usage des décalages multiples en laissant le compilateur se dépatouiller avec cela.

Salut

Avec un fantastique comportement indéfini si tu essaye d'accéder à la valeur de as_double alors que tu as défini la valeur en tant que as_pint (ou inversement)...

La norme le dit elle même : on ne peut pas déterminer ce qui va se passer dans ce genre de situation. *** Avec un peu de chance *** il n'y aura ni problème d'alignement (du à des tailles différentes utilisées pour représenter les données en mémoire), ni problème de "boutisme" (d'endianness) et, mieux encore, les valeurs que l'on retrouveras au niveau de l'exposant et de la fraction du double seront "cohérentes", mais il n'y a absolument aucune garantie sur ce point.

Encore une fois, il suffirait de changer de compilateur, de version de compilaeur ou simpelement une option de compilation pour que ce qui semblait fonctionner (sur base de ce comportement indéfini) se mette à planter lamentablement...

[kaitlyn]

Salut tout le monde,

Existe-t-il à la même adresse mémoire tout au long de sa vie?

Tant que tu te réfères à ton objet tableau en lui-même et dans un même processus, tu n'auras pas de souci, parce qu'il sait à tout instant où sont les données brutes. Par contre si tu enregistres l'emplacement de ces données et que tu fais un ArrayResize(), ton enregistrement devient invalide.

Bref, le problème XY, je rappelle ce que c'est,

Le problème XY est un problème de communication rencontré lors d’une demande d’assistance. La personne ayant un problème X imagine une solution Y, et au lieu de demander de l’aide pour X, cette personne demande de l’aide pour mettre en place la solution Y. Cependant, il arrive que résoudre le problème Y ne résolve que de manière partielle ou bancale le problème X. Ainsi, ne pas présenter le problème original et introduire un problème autre peut conduire à des difficultés de communication et à des solutions insatisfaisantes.

plus des informations délivrées au compte-goutte, genre projet top secret... force est de constater que si j'avais voulu troller, je n'aurais pas fait mieux.
Allez, bon courage pour la suite.

[bacelar]

Heu, pas tout compris.

Mais pourquoi la partie 1 ne sauve les données dans un fichier, qui sera lu par la partie 2 ?

[Guesset]

Bonjour koala01,

Avec un fantastique comportement indéfini si tu essaye d'accéder à la valeur de as_double alors que tu as défini la valeur en tant que as_pint (ou inversement)...

Le risque est d'utiliser un double pour transporter (et non convertir) un pointeur, pas la manière dont on s'y prend. Le comportement n'est pas indéfini (reproductibilité), l'accès ne pose aucun problème, mais on ne peut utiliser l'un pour l'autre. Ca tombe bien, l'union ne sert pas à faire de la conversion.

La norme le dit elle même : on ne peut pas déterminer ce qui va se passer dans ce genre de situation.

Quelle norme ?

*** Avec un peu de chance *** il n'y aura ni problème d'alignement (du à des tailles différentes utilisées pour représenter les données en mémoire), ni problème de "boutisme" (d'endianness) et, mieux encore, les valeurs que l'on retrouveras au niveau de l'exposant et de la fraction du double seront "cohérentes", mais il n'y a absolument aucune garantie sur ce point.
Encore une fois, il suffirait de changer de compilateur, de version de compilaeur ou simpelement une option de compilation pour que ce qui semblait fonctionner (sur base de ce comportement indéfini) se mette à planter lamentablement...

En l'occurrence, il ne peut y avoir ni problème d'alignement ni d'endianness :

• Il n'y a pas de problème d'alignement car ce sont deux types simples de même taille. Il pourrait y avoir des problèmes d'alignement dans le cas d'union de structures complexes non "packed" car le bourrage d'un unpacked peut varier d'un système à l'autre.
• Il ne peut y avoir de problème d'endianness sur ces types simples car ils subissent de facto le même boutisme (l'ordre des octets ne va pas changer d'un type à l'autre). Le même code fonctionnera identiquement avec un boutisme ou l'autre. Cependant, dans l'exemple des couleurs, plus complexe, le boutisme pourra affecter l'ordre des composantes.

Un peu de maîtrise évite de recourir à la chance. Pas convaincu ? A tester sous divers compilateurs et OS.

Salut

[bacelar]

De quel MQL on parle ?

Parce que si c'est MQL4 de "MetaQuotes Software Corp." (ça sent la vodka). (first hit on Google)

C'est pas les pointeurs et les objets qui manquent :
https://docs.mql4.com/common/getpointer
https://docs.mql4.com/objects

C'est quand même très proche du C++ "traditionnel", avec des pointeurs nus dans les exemples de code.

Qui a parler de "problème XY" ?

[henderson]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
// pour l'affichage
char Text[256];
char Buffer[256];
 
// le code :
char Tab[8];
char *p = &Tab[0]; // pointe sur ... p contient l'adresse du premier char du tableau
double d = (int)p; // d contient l'adresse (valeur contenue dans p)
 
int dp = (int)d; // dp contient la valeur stockée dans d ... qui est l'adresse sur le premier char du tableau.
char *dpstr = (char*)dp; //dpstr contient la valeur de dp
 
sprintf(Text, "%d", p); // affiche en decimal
strcat(Text, "\n"); //saut d'une ligne
sprintf(Buffer, "%d", dp);
strcat(Text, Buffer);
strcat(Text, "\n"); //saut d'une ligne
sprintf(Buffer, "%d", dpstr);
strcat(Text, Buffer);
MessageBox(NULL, Text, "Test", MB_OK);

[Guesset]

Bonjour,

Le code de henderson fonctionne car il ne se heurte pas à l'écueil identifié par dalfab des 53 bits utilisables pour un entier dans un double. Certes, 53 bits sur 64 sont largement suffisants pour une adresse (voir ci-après), mais cela reste une conversion limitée.

Sur la page MS Espace d'adressage virtuel (https://learn.microsoft.com/fr-fr/wi...-address-space) : "Tous les pointeurs sont toujours des pointeurs 64 bits, mais le système garantit que chaque allocation de mémoire se produit en dessous de la limite de 2 Go, de sorte que si l’application tronque un pointeur, aucune donnée significative n’est perdue. Les pointeurs peuvent être tronqués vers des valeurs 32 bits, puis étendus à des valeurs 64 bits par extension de signe ou par extension zéro."

C'est donc un choix entre esthétique et pratique.

Mais comme bacelar le signale, les pointeurs de MQL existent et semblent très proches de ceux de C/C++. Le besoin de transport masqué ou de conversion n'est donc pas avéré.

Salutations

[CGi]

"Tous les pointeurs sont toujours des pointeurs 64 bits, mais le système garantit que chaque allocation de mémoire se produit en dessous de la limite de 2 Go, de sorte que si l’application tronque un pointeur, aucune donnée significative n’est perdue. Les pointeurs peuvent être tronqués vers des valeurs 32 bits, puis étendus à des valeurs 64 bits par extension de signe ou par extension zéro."

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.