Discussion :

[Snake-Eyes]

Bonjour � tous et merci de prendre du temps pour mon probl�me

En fait j'aimerais savoir si il est n�cessaire de faire un delete sur une variable du type :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
static char* aa = new char[256]

Cette variable est d�finie au d�but du programme et est utilis�e dans tous le programme.

Si il est n�cessaire de faire un delete, comment dois je le faire et ou dans le programme??

Merci de vos r�ponse

[hiura]

Comme elle est static �a ne sert effectivement � rien. Mais attention, si c'est une classe qui est allou�e dynamiquement tu vas devoir faire en sorte que le destructeur soit appel�.

Mais dans ton cas, pourquoi faire une alloc' dynamique ? Un simple static char aa[256]; aurait suffit.

[white_tentacle]

un delete, certainement pas, mais un delete[], oui, par principe .

Cela dit, pourquoi une allocation dynamique ?

[koala01]

Salut,

A l'instar de white_tentacle, je me pose r�ellement la question de la raison qui te pousse � recourir � l'allocation dynamique (sans compter le fait que l'on puisse se poser la question de la raison qui te pousse � cr�er une variable globale statique... mais c'est peut etre un autre d�bat )

Tout comme lui, j'estime, par principe que tout new ou new[] doit avoir son delete ou delete[] �quivalent.

Celui permettant de lib�rer la m�moire r�serv�e � ta variable statique devrait donc prendre place le plus pr�s possible du return final (celui de main()), mais bien �videmment avant qu'il (le return final) ne survienne.

Ceci dit, il est effectivement vrai que toutes les ressources (y compris celles pour lesquelles on a allou� dynamiquement de la m�moire) sont (sens�es �tre) lib�r�es automatiquement par le syst�me lorsque l'application se ferme, mais voil�, il y a un mais (deux mais m�me)...

le premier mais prend la forme de

Mais tous les syst�mes ne le font pas ou pas forc�ment correctement:

Qui n'a en effet jamais subit le probl�me d'un fichier "verrouill�" par une application qui s'est termin�e (plus ou moins correctement) il y a d�j� un temps ceertain

Le deuxi�me mais a d�j� �t� abord�: par principe, tout ph�nom�ne d'allocation dynamique doit �tre contrebalanc� par le ph�nom�ne ad�quat de lib�ration de la m�moire...

Ne pas le faire pour une variable statique sous pr�texte que le syst�me est sens� s'en occuper a de quoi heurter ce principe

[JolyLoic]

Tout comme lui, j'estime, par principe que tout new ou new[] doit avoir son delete ou delete[] �quivalent.

Je suis globalement en accord avec cette r�gle.

La seule exception que j'ai pu y trouver, et elle est rare, c'est quand on fait un petit utilitaire en ligne de commande, destin� � �tre appel� de nombreuses fois par un script, et pour lequel il s'agit d'optimiser le temps de descente du processus en faisant tout d�sallouer en bloc � l'OS, plut�t que de d�sallouer soi m�me petits bouts par petits bouts (apr�s mesure bien entendu que du temps est pass� � �a).

[Snake-Eyes]

Youpi, j'ai tout plein de r�ponse. Tout d'abord merci beaucoup pour ses r�ponses.

Donc j'ai bien pris note de vos conseils et je vais donc abandonner l'allocation dynamique et faire un :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

static char aa[256]

Tant que j'y suis, je sais pas si cette question peut �tre pos�e ici mais je tente. Dans mon programme que je code avec "visual c++", j'utilise des gcnew par exemple comme ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
String^ nom_matiere;
string keyvalue;
nom_matiere = gcnew String(keyvalue.c_str());

Ce que j'aimerais savoir c'est est ce qu'il est utile de lib�rer la m�moire lorsque l'on fait ceci et si oui qu'elle est la marche � suivre????
Merci pour vos r�ponse....

[white_tentacle]

Manifestement, tu fais du C++/CLI. Je n'en ai jamais fait, mais je suppose que gcnew signifie garbage collected new, et que donc, tu n'as pas besoin de faire de delete explicite.

Par contre, m�fie-toi, tu ne sauras pas quand est appel� le destructeur dans ce cas (c'est le runtime qui s'en occupe). Pas g�nant pour un std::string, mais pour d'autres objets...