Comment passer une map sur un named pipe windows ?

Bonjour tout le monde, :salut:

J'ai deux processus P1 et P2 qui tournent dans deux comptes différents sur le même pc (pour mon cas, l'un dans le compte SYSTEM et l'autre dans le compte user ) et qui veulent s'échanger des informations. un des deux récolte les informations qu'il a dans une map stl " std::map<string,vector<string>> ma_map", et veut envoyer ce contenu vers l'autre processus.

Alors j'aimerai bien savoir si la communication entre les deux peut se réduire à échanger une référence sur la map ou bien je vais m'acharner à encoder le contenu de la map sous format string puis la reconstruire de l'autre côté ?

Pour écrire sur le pipe les processus utilisent la fonction writefile, voici la doc msdn:

Citation:

---

BOOL WINAPI WriteFile(
__in HANDLE hFile,
__in LPCVOID lpBuffer,
__in DWORD nNumberOfBytesToWrite,
__out_opt LPDWORD lpNumberOfBytesWritten,
__inout_opt LPOVERLAPPED lpOverlapped
);
pBuffer [in]

A pointer to the buffer containing the data to be written to the file or device.

This buffer must remain valid for the duration of the write operation. The caller must not use this buffer until the write operation is completed.

---

Plus précisement, est ce que le type LPCVOID ici permettra de pointer une map stl pour la transmettre en entier à l'autre processus ? et si c'est vrai , comment je fais ça dans l'émission(je passe &ma_map ... ?) et dans la réception( casting vers map ..? )
Merci pour votre aide :)

Il faut "serialiser" la map dans le contexte de l'émetteur, puis écrire le résultat dans le fichier.
Puis Il faut "déserialiser" la map dans le contexte du récepteur.

Boost semble avoir ce qu'il faut pour sérialiser une map de la STL.
http://khayyam.developpez.com/articl...serialization/

Citation:

---

Envoyé par bacelar

Il faut "serialiser" la map dans le contexte de l'émetteur, puis écrire le résultat dans le fichier.
Puis Il faut "déserialiser" la map dans le contexte du récepteur.

Boost semble avoir ce qu'il faut pour sérialiser une map de la STL.
http://khayyam.developpez.com/articl...serialization/

---

J'ai précisé dans le titre de la question que la communication de fait à travers un pipe en utilisant la fonction writefile .. on est bien daccord que c'est la même chose ?
Je suis entrain de lire l'article ..

Sérialiser, c'est convertir un objet en chaîne de caractère donc pipe ou fichier c'est pareil.
Pour la portabilité, entre l'émetteur et le récepteur, il peut avoir des problèmes si boost n'utilise pas une représentation standard type XML.

Juste une remarque svp, j'aimerai bien que vous m'expliquiez le résultat de test que j'ai fait :
Dans le code de l'émetteur j'ai mis:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

// je remplie la map par un contenu de test map<CString,vector<CString>> ma_map; vector<CString> v; v.push_back("b");v.push_back("c"); ma_map["a"]=v; // j'essai de passer une référence sur la map( puisque la fonction writefile prend un LPVOID comme param en entrée BOOL bResult = WriteFile( hPipe, // handle to pipe &ma_map, // buffer to write from sizeof(ma_map)+1, // number of bytes to write, include the NULL &cbBytes, // number of bytes written NULL); // not overlapped I/O if ( (!bResult) || (sizeof(ma_map)+1 != cbBytes)) { printf("\nError occurred while writing to the server: %d", GetLastError()); CloseHandle(hPipe); return 1; //Error } else { printf("\nWriteFile() was successful."); }

---

Alors le résultat de débuggage m'écrit

Citation:

---

WriteFile() was successful.

---

Dans le code du récepteur , j'ai mis:
1er test)
******

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

// je déclare une map pour recevoir l'autre map qui va "venir" sur le pipe map<CString,vector<CString>> ma_map; BOOL bResult = ReadFile( // this function is gona wait until something is read from the pipe hPipe, // handle to pipe &ma_map, // buffer to receive data sizeof(ma_map), // size of buffer &cbBytes, // number of bytes read NULL); // not overlapped I/O if ( (!bResult) || (0 == cbBytes)) { printf("\nError occurred while reading from the client: %d", GetLastError()); CloseHandle(hPipe); return 1; //Error } else { printf("\nReadFile() was successful."); }

---

Le résultat du debogage me donne erreur de GetLastError() 234 ce qui signifie sur msdn

Citation:

---

ERROR_MORE_DATA
234 (0xEA) More data is available.

---

et quand j'ajoute 1 à la taille du buffer(car dans l'emetteur la taille écrite est sizeof(ma_map)+1),
2ème test)
******

Code:

---

1 2 3 4 5 6 7 8

// je déclare une map pour recevoir l'autre map qui va "venir" sur le pipe map<CString,vector<CString>> ma_map; BOOL bResult = ReadFile( // this function is gona wait until something is read from the pipe hPipe, // handle to pipe &ma_map, // buffer to receive data sizeof(ma_map)+1, // size of buffer &cbBytes, // number of bytes read NULL); // not overlapped I/O

---

La lecture réussit, car le retour de la fonction est non nul, le récepteur écrit le message de succès

Citation:

---

ReadFile() was successful.

---

et le nombre d'octects lus est non nul

Citation:

---

cbBytes=29

---

mais la map est "vide", pour être plus précis , elle n'est pas vide mais contient

Citation:

---

ma_map = [1](...)

---

puis quand je développe ça avec le debogueur de VS je trouve que cet élement est

Citation:

---

(error) = 0

---

Bon à vrai dire, j'avoue que le sizeof(ma_map)+1 chez le récepteur n'est pas la même que chez l'émetteur car chez l'émetteur elle est pleine et chez le récepteur elle est "vide" initialement..
Bon, voilà j'ai essayé de donner le maximum de détails pour voir la possiblité de faire un petit réglage pour arriver au but. Sinon, si vous m'affirmez que y'a pas possiblité de réaliser mon but de cette façon, je vais faire comme a cité bacelar et me plonger dans la sérisalisation :aie:

C'est marqué où qu'une map est un objet contenue dans un bloc CONTINU en mémoire, et qu'il n'y a pas de pointeurs (éminent non transférable entre processus) et que les objets contenus dans la map sont dans ce bloc mémoire ?

masterx_goldman encore une fois c'est un problème de persistence des objets.
Quand tu fais par exemple :

Code:

---

1 2	vector<CString> v; v.push_back("b");v.push_back("c");

---

le vecteur v effectue une copie d'instance de type CString.
Elle n'est locale qu'à ton processus A !

Citation:

---

Envoyé par masterx_goldman

Plus précisement, est ce que le type LPCVOID ici permettra de pointer une map stl pour la transmettre en entier à l'autre processus ?

---

N'utilise pas des variables allouées localement sur la pile mais plutot des pointeurs ; donc tu dois allouer un pointeur de type std::map * avec un new et pareil pour les types contenus par le std::map.
Si tu passes des pointeurs au pipe de communication tu passeras des objets et zones mémoires valides puisqu'elles pointeront sur des variables allouées.

Code:

---

1 2 3 4 5

map<CString,vector<CString>> ma_map; vector<CString> v; v.push_back("b");v.push_back("c"); ma_map["a"]=v; // j'essai de passer une référence sur la map( puisque la fonction writefile prend un LPVOID comme param en entrée

---

C'est normal que dans le processus tu ne recoives rien !
WriteFile va fonctionner et donner un code de retour de succès.
Mais tu ne recevras rien parce que tu alloues localement un std::map dans une fonction ce que l'on appelle allouer sur la pile.
Donc lorsque ta fonction est terminée là ou tu alloues la std::map la std::map n'est plus valide.
Seule solution que tu alloues des pointeurs globalement avec des new.
Ou bien en static

Citation:

---

Envoyé par Mat.M

Seule solution que tu alloues des pointeurs globalement avec des new.
Ou bien en static

---

L'instance d'une map utilise en interne des pointeurs, qui n'ont aucune signification dans le processus receveur.
Il faut SERIALISER la map.

Citation:

---

Envoyé par bacelar

L'instance d'une map utilise en interne des pointeurs, qui n'ont aucune signification dans le processus receveur.
Il faut SERIALISER la map.

---

Oui mais de toute façon passer des pointeurs à un pipe de communication n'est pas une bonne chose non plus...sinon le processus receveur risque de pointer sur des zones invalides.
Quant à sérialiser c'est possible mais je trouve un peu lourd cette méthode parce que c'est une méthode intermédiaire un peu inutile, tu vas rajouter une étape supplémentaire.
Si tu as une centaine max d'entrées dans la std::map ça va; si tu en as des milliers c'est pas une bonne méthode parce que le disque dur va être sollicité ce sera des opérations I/O supplémentaires.
La solution la plus simple et la plus triviale c'est bêtement de parcourir la std::map dans le processus A , envoyer les entrées via le pipe et reconstituer une autre std::map dans le processus B.

Citation:

---

Envoyé par bacelar

Sérialiser, c'est convertir un objet en chaîne de caractère donc pipe ou fichier c'est pareil.

---

je ne suis pas du tout d'accord ; un pipe c'est une sorte de zone mémoire d'intercommunication et la persistence n'est pas la même que pour un fichier texte sur disque.
Les OS gèrent de manière différente les blocs de zone mémoire pas comme les fichiers sur disque.
Maintenant masterx_goldman n'a qu'à tenter différentes choses..

et puis peux-tu m'expliquer comment tu fais pour sérialiser les données et puis les envoyer dans le pipe ? :roll:.

Citation:

---

Envoyé par Mat.M

Quant à sérialiser c'est possible mais je trouve un peu lourd cette méthode parce que c'est une méthode intermédiaire un peu inutile, tu vas rajouter une étape supplémentaire.
Si tu as une centaine max d'entrées dans la std::map ça va; si tu en as des milliers c'est pas une bonne méthode parce que le disque dur va être sollicité ce sera des opérations I/O supplémentaires.
La solution la plus simple et la plus triviale c'est bêtement de parcourir la std::map dans le processus A , envoyer les entrées via le pipe et reconstituer une autre std::map dans le processus B.

---

Citation:

---

Envoyé par Mat.M

je ne suis pas du tout d'accord ; un pipe c'est une sorte de zone mémoire d'intercommunication et la persistence n'est pas la même que pour un fichier texte sur disque.
Les OS gèrent de manière différente les blocs de zone mémoire pas comme les fichiers sur disque.
Maintenant masterx_goldman n'a qu'à tenter différentes choses..

---

Sérialisation n'a rien à voir avec les I/O. Cela est fait uniquement en mémoire. C’est tellement commun comme tâche que des librairies comme Boost ont des fonctionnalités qui convertissent un objet de la STL en chaîne de caractère. Tout le code de parcour est donc inutile puisque Boost sans charge. La sérialisation n’est pas lourde, bien au contraire.
On a une chaine de caractères, un tableau de char, que l’on donne directement au pipe d’un coup.