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...