vector <string> paramètre thread

bonjour ,

Etant débutant , je recherche des infos sur le passage de paramètres dans un thread . :ccool:

Et plus particulièrement avec des vecteurs string . :cry:

Voila un bout de code .

Code:

---

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

char PROG_RX (int NreDataArecevoir ,vector< string > &ChaineRecu) { ThreadHandle_receve_buffer=CreateThread(NULL,NULL,ThreadProc_receve_buffer,(LPVOID)&ChaineRecu,0,&ThreadID_receve_buffer); if ( WaitForSingleObject ( ThreadHandle_receve_buffer, 10000 ) == WAIT_TIMEOUT ) // anti blocage si pas de réponse ou manque de data { code_erreur = 6 ; } CloseHandle(ThreadHandle_receve_buffer); ThreadHandle_receve_buffer=NULL; delete ThreadHandle_receve_buffer ; } return code_erreur ; DWORD WINAPI ThreadProc_receve_buffer(LPVOID lparam) { if ( monClientTcp->Connected == true ) { vector <string> ChaineRecu= reinterpret_cast <vector <string>&>lparam); ChaineRecu [0] = "test" ; <---- ????:aie:

---

je pense avoir fait une erreur dans le cast . Surement une histoire de pointeurs ... J'avou les pointeurs c pas mon point fort !!!! :oops: :calim2:
Je voudrais limiter au maximum l’utilisation d'une variable globale dans cette Dll .:roll:


Merci beaucoup par avance .

est ce que mon cast est correct ?

Non, il n'est pas correct : tu cast un vector<string>* en void* puis un void* en vector<string>&.
vector<string>* -> void*
vector<string>& <- void*

Est-ce que tu vois le problème?

je vais être honnête : non !!! :cry:

Je sais que les pointeurs ne sont pas du tout mon truc . Mais là , je coule à pic !! :roll:
Si tu as des liens vers des tutos simples pour enfin comprendre les pointeurs dans tous les aspects , je suis preneur .

merci pour ton aide :ccool:

Bonsoir,

Peut être qu'avec les commentaires pour suivre le périple du vecteur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

char PROG_RX (int NreDataArecevoir ,vector< string > &ChaineRecu) { // ChaineRecu : référence sur le vecteur // (LPVOID)&ChaineRecu : pointeur sur la référence de vecteur, converti en void * ThreadHandle_receve_buffer=CreateThread(NULL,NULL,ThreadProc_receve_buffer,(LPVOID)&ChaineRecu,0,&ThreadID_receve_buffer); //... } return code_erreur ;   DWORD WINAPI ThreadProc_receve_buffer(LPVOID lparam) { //... lparam est un pointeur sur la référence du vecteur, pas une référence directement. vector <string> ChaineRecu= reinterpret_cast <vector <string>&>lparam); ChaineRecu [0] = "test" ; // Est-ce que le vecteur à déjà alloué la mémoire pour cette chaîne ? }

---

Rmq 1 : Lorsqu'on a un pointeur sur une référence, on a pas directement un poiteur sur l'objet, mais bien sur la référence. Donc si la mémoire où se trouve la référence est libéré ... Attention donc à l'utilisation de ce genre d'élément.

Rmq 2 : Avec le thread une des difficultés est la synchronisation. Une façon de synchroniser les threads est :
- de laisser des données dans le thread (c'est lui qui les crée, alloue, utilise ... de cette manière on évite les conflits d'accès.
- Lorsque les données sont dispos, on en envoi un message asynchrone au threat qui à besoin des données (ex : via un postmessage).
- le thread avec les données dispose d'une méthode pour passer par copie à un autre thread.(sauf besoin critique, la copie évitera les conflits d'accès à la suite).

faq sur les pointeurs : >>ici<<
faq sur les références : >>ici<<

merci pour les liens . Je vais les cogiter !!! :mouarf:

Mon but premier était au départ d'éviter les variables globales au maximum .
C un bon exercices pour la mnip des pointeur ref .. etc ....:ccool:

salut,

en gros une référence (à ne pas confondre avec l'opérateur & qui récupère l'adresse d'une variable) permet de définir un ALIAS d'une variable existante en c++...

si tu écris:

Code:

---

1 2 3 4 5 6 7 8 9 10

void truc(int& a, int b) { b=b/5; a=a+b; }   int c=5,d=5; truc(10,5); // erreur car 10 est un litéral truc(c,5); // c=5+5/5=6 truc(c,d); // c=5+5/5=6,d=5

---

l'idée est ici de forcer le contexte de passage des variables et de garantir un comportement de compilation:

• on attend comme premier paramètre de la fonction une variable (pas une constante) de type int dont on veut modifier la valeur même si elle est externe au contexte du corps de la fonction
• le deuxième paramètre est passé par valeur de type int, une copie locale au contexte du corps de la fonction est créé et initialisé et seul celui ci est modifié éventuellement

le pointeur ne fait lui que contenir une adresse typée et peut donc être casté vers un autre type de pointeur ou un entier (int sur 32 ou long sur 64bits)

rien ne t’empêche de définir plusieurs pointeurs avec la même adresse mais si tu utilises ceux-ci, en modifier un ne change pas la valeur des autres, c'est le premier danger
par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int a; void truc(int *b) { int *c=b; *c=5; b=new int; *b=8; delete b; }   truc(&a);// a=5 truc(null);// erreur d'accès à la mémoire car je ne teste pas si le pointeur b est valide dans truc

---

le pointeur ne garantie en rien que l'adresse qu'il contient est valide ou utilisable... la seule chose qui est admise est qu'un pointeur avec 0 comme adresse correspond à un pointeur vide

le pointeur ne permet pas de garantir non plus quel gestionnaire d'allocation mémoire (malloc/free, new/delete ou ceux spécifique à l'os considéré) est utilisé, sachant qu'ils sont incompatibles entre eux bien sur

:mrgreen:

c'est pour ça qu'une signature de fonction utilisant des références à la place de pointeurs permet une écriture plus sure où certaines erreurs sont vues à la compilation du coup en c++ par rapport au simple pointeur... du moins quand l'idée est de modifier une variable externe au contexte du corps d'une fonction...

pour l'allocation dynamique en c++, tu peux "cacher" les pointeurs par le mécanisme des itérateurs ou des pointeur managés... l'idée c'est de palier aux manque de contrôle sur le pointeur de type c qui permet presque tout et n'importe quoi... et donc oblige à beaucoup de rigueur

Windows propose des pointeurs (commençant par "LP")et des allocateurs spéciaux (qui te retourne un identifiant comme HRESULT, HINSTANCE, HMODULE, etc...)
l'idée est de te cacher les pointeurs internes et de ne te permettre de manipuler que des structures c pour paramétrer les ressources...
certains des types et de leur pointeurs servent à abstraire des type comme des chaines de caractères en fonction de choix de compilation
TCHAR depend de si on utilise ou non unicode par exemple...

Grand merci pour tes éclaircissement .
Je suis en train de repasser tous les tutos et forum afin de mieux apréander la gestion pointeur ref etc...
Merci