Discussion :

[deck_bsd]

Bonjour,

Je me posais la question de savoir si ce code est valide dans le cas d'une application en C win32 avec Interface graphique :

Code :

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

1
2
3
4
5
6
7
char * p;
p = (char*) malloc (10+1);

strcpy(p,"test");
SetWindowText(hWnd,p);
free(p);

Parce que étant donné que p est alloué par malloc cet espace ne sera pas libéré sans un free (règle de base en C ^^). Mais dans ce cas, si on cherche à afficher le text d'une chaine de caractère allouée dynamiquement. Le second paramètre de SetWindowText est un pointeur de chaine de chaîne de caracètre (LPTSTR). Donc on passe l'adresse de notre buffer.

Ma question est , est ce que ce code est valide ? car dans l'absolu cela fonctionne, mais il se peut très bien que l'espace de p soit ré-écrit et donc du coup le texte affiché dans le contrôle ne serait plus le bon. Du coup je pense que cette méthode de faire est pas très safe, si ?

Le mieux ne serait-il pas de :

- Si le text ne doit pas être récupéré , ne pas faire de free et l'espace sera donc libéré à la fin du programme.
- Si le text doit être récupéré , faire le free lorsque l'on récupère le pointeur via GetWindowText.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
p = (char*) malloc (10+1);

strcpy(p,"test");
SetWindowText(hWnd,p);

...... Quelque pars dans le programme

char * b;
GetWindowText(hWnd,b,10+1);
free(b);

Est-ce que j'ai juste ?

Ou alors la fonction SetWindowText derrière fais une copie de notre chaine de caractère et on peut donc en toute sécurité faire un free de notre pointeur ?

PS : Le code est écris à la vas vite, je ne sais pas si il compile, mais la question ne porte pas sur la synthaxe de celui-ci

[Médinoc]

À ma connaissance, SetWindowText() recopie le contenu du pointeur que tu lui passes vers un buffer propre à la fenêtre, donc il n'y a aucun problème à libérer le buffer une fois que la fonction a retourné.

En d'autres termes, la fonction SetWindowText() n'a pas d'incidence sur la durée de vie du buffer passé en paramètre, si sur sa possession.

[deck_bsd]

Cool

Merci Médinoc, je reprend le C depuis plus de 5 ans sans y toucher :'( et je sais que c'était une question que je m'étais déjà posée à l'époque (et d'ailleur tu étais déjà très actif :p ). Juste une dernière chose avant de passer le fil en résolu.

Comment sais-tu ça, en fait comment as-tu fait pour connaitre le comportement de SetWindowText par exemple.

Car je n'ai pas trouvé cela sur la MSDN ou autre (à moin de l'avoir loupé bien sur). Car si tu as une source qui contient pas mal de doc sur l'API win32 (autre que MSDN et juste la définition des fonctions) je suis carrément preneur

[Médinoc]

C'est surtout que c'est un comportement "habituel" des fonctions Win32, et c'est ce qui a le plus de sens (c'est aussi testable: tu ne fais pas de free et tu fais un strcpy d'autre chose). Surtout quand tu regardes GetWindowText(), qui lui aussi fait une copie (et là, c'est évident et il ne peut en être autrement, vu le prototype de GetWindowText()).

[deck_bsd]

Je suis d'accord, c'est effectivement ce qui serait logique de faire et c'est effectivement testable.

Par contre je ne te suis pas sur le "c'est évident vu le prototype de GetWindowText" ? je dois manquer quelque chose, ormis le fait qu'il soit _out_ cela reste un pointeur de chaine qui pourrait très bien (si ce n'était pas une copie) te renvoyer l'adresse que tu as passée à SetWindowText(). Mais on est d'accord que ce serait un gros bordel

[Médinoc]

Ben non, GetWindowText() ne peut pas renvoyer de pointeur, regarde mieux son prototype.

GetWindowText() ne fait qu'accepter un pointeur et une longueur, et donc pour respecter les types doit forcément copier ses données vers le buffer donné. Aucun des types du prototype ne permet à la fonction de retourner un pointeur sans faire un cast.

[deck_bsd]

Non tu as tout à fait raison, gosh j'ai quitté ce monde depuis trop longtemps :s Désolé du dérangement