Discussion :

[adaneels]

Bonjour,

Je me pose des questions sur la libération correcte de la mémoire. (VS 2008, ici sur une appli WCF)


Sur cet exemple, comment faire pour être sûr que la mémoire est totalement libérée ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
using System.IO;
[...]
  /// <summary>
  /// Renvoie la date de dernière modification du fichier
  /// </summary>
  public DateTime LastModif
  {
    get
    {
        return new FileInfo(FilePathName).LastWriteTime;
    }
  }
[...]

Est-ce que ce code serait mieux ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  public DateTime LastModif
  {
    get
    {
      FileInfo fi = new FileInfo(FilePathName);
      try
      {
        return fi.LastWriteTime;
      }
      finally
      {
        fi = null;
      }
    }

[Chubyone]

Sur cet exemple, comment faire pour être sûr que la mémoire est totalement libérée ?

En faisant confiance au Garbage collector :-)
Sachant que DateTime est en + un type valeur, tu ne conserveras aucune référence à FileInfo par la suite => GC 0 direct.

Il faut faire attention à tout objet héritant de IDisposable, et éviter certaines boucles qui bourrinent dans le GC inutilement. Pour la libération mémoire des IDisposable, il est convenu d'utiliser le
using(IDisposable){ ... }


Le Try finally est ici + qu'inutile, ce qui importe par contre dans cet exemple ce sont les possibles exceptions du à un mauvais Path :

Exceptions:
System.ArgumentNullException: fileName is null.
System.Security.SecurityException: The caller does not have the required permission.
System.ArgumentException: The file name is empty, contains only white spaces, or contains invalid characters.
System.UnauthorizedAccessException: Access to fileName is denied.
System.IO.PathTooLongException: The specified path, file name, or both exceed the system-defined maximum length. For example, on Windows-based platforms, paths must be less than 248 characters, and file names must be less than 260 characters.
System.NotSupportedException: fileName contains a colon ( in the middle of the string.

Si ton Path est un membre privé, il serait préférable de directement conservé une référence à FileInfo, ou alors de le créer au Set de FilePathName. Enfin, tout est question de choix.

Cela dit, si une exception pète, il y a un problème : il faut le traiter d'une façon ou d'une autre...

[Guulh]

Yep, comme le dit Chubyone, FileInfo n'implémente pas IDisposable : c'est donc qu'il ne détient aucune ressource non managée, et que donc qu'il n'y à rien à faire.

La mémoire est une ressource managée, donc on y touche pas (plus précisement, on peut pas ), et on laisse le GC nettoyer les objets morts quand il en a envie.

[adaneels]

OK.
Je me posais la question parce qu'il y avait un new et venant de Delphi, j'ai l'habitude de penser "Tout Create doit avoir son Free.".

Pour les using et dispose, oui oui, je fais gaffe

Lorsque je regarde tout ce qu'il se dit sur Internet sur "comment éviter les fuites de mémoire" ou "comment bien libérer la mémoire utilisée", je vois beaucoup "mettez vos variables à null" !

Hors, à moins d'avoir un type nullable, il n'y a que les string, object et les collections que l'on peut mettre à null (à ma connaissance mais je n'ai pas testé tous les types ).
Mais ça me paraît bizarre de mettre à null tous mes strings avant de sortir d'une fonction...
Ces objets sont pourtant bien managés et ils sont bien libérés (en supposant qu'il n'y ait que des variables locales) au prochain passage du GC après que la fonction ait été exécutée, non ?

Arnaud DANEELS
un développeur qui se pose des questions sur la gestion de mémoire en C# alors que c'était plus simple en Delphi ou en C : on alloue et on désalloue soi-même.

[Pol63]

http://www.developpez.net/forums/m4408229-5/

[Chubyone]

Il y a deux "types" en .Net : les types valeurs, int, float, DateTime, ou Struct plus généralement, et les types références : tout le reste.

Renseignes toi sur la MSDN il y a pas mal d'explications la dessus

Puisque tu en parles il y a une précision importante a BIEN retenir : le type string est IMMUTABLE : toute modification entraine une nouvelle instance. De cette connaissance, à toi de savoir quoi faire, et surtout NE PAS faire
La dessus aussi la MSDN a de quoi t'offrir pleins d'explications

[adaneels]

http://www.developpez.net/forums/m4408229-5/

Merci pour le lien .

Ca me rassure

[Guulh]

Lorsque je regarde tout ce qu'il se dit sur Internet sur "comment éviter les fuites de mémoire" ou "comment bien libérer la mémoire utilisée", je vois beaucoup "mettez vos variables à null" !

Ce qui ne sert à rien, à par pourrir le code de lignes inutiles
Mettre à null, ce n'est que couper le lien entre une référence et l'objet qu'elle référençait. Ca ne libère pas l'objet.
Pourquoi ne peut on pas libérer la mémoire à la main ? Ben c'est simple : un objet peut être référencé par un paquet d'objets vivants. Si on pouvait le libérer (via un "delete uneDesRéférences"), ça voudrait dire que toutes ces références seraient invalides. Et en C#, t'as l'assurance que toute référence est valide.

Donc, répète après moi, comme un mantra : j'oublie tout ce que je sais de la gestion de la mémoire en C ou Delphi, et je ne m'occupe que des autres ressources (connexion réseau, handle, etc.) en C# avec le pattern IDisposable

[adaneels]

Donc, répète après moi, comme un mantra : j'oublie tout ce que je sais de la gestion de la mémoire en C ou Delphi, et je ne m'occupe que des autres ressources (connexion réseau, handle, etc.) en C# avec le pattern IDisposable

OK OK lol
je suis repasser dans les lignes que j'ai modifié hier pour enlever ces nulls . J'avais fait ça pour voir si ça améliorer quelquechose mais ça me plaît bien mieux sans ces null partout


Deux autres questions :
- les collections : je suppose que l'on n'a pas besoin de les vider sauf si le type de données dérive de IDisposable. j'ai juste ?
- Si j'ai bien compris la politique en C# : ce type-ci n'a pas besoin d'avoir son Dispose :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
public class TOCLogItem : INotifyPropertyChanged
{
  private DateTime _Dt;
  private TOCLogGravity _Gravity;
  private string _Message;
 
  public DateTime Dt
  {
    get { return _Dt; }
    set
    {
      _Dt = value;
      if (PropertyChanged != null)
        PropertyChanged(this, new PropertyChangedEventArgs("Dt"));
    }
  }
  public TOCLogGravity Gravity
  {
    get { return _Gravity; }
    set
    {
      _Gravity = value;
      if (PropertyChanged != null)
        PropertyChanged(this, new PropertyChangedEventArgs("Gravity"));
    }
  }
  public string Message
  {
    get { return _Message; }
    set
    {
      _Message = value;
      if (PropertyChanged != null)
        PropertyChanged(this, new PropertyChangedEventArgs("Message"));
    }
  }
 
  public TOCLogItem(DateTime dt, TOCLogGravity gravity, string message)
  {
    this.Dt = dt;
    this.Gravity = gravity;
    this.Message = message;
  }
 
  public event PropertyChangedEventHandler PropertyChanged;
}

j'ai juste ?

[adaneels]

Le Try finally est ici + qu'inutile

Ca me rassure grandement de ne pas avoir à pourrir mon code

Si ton Path est un membre privé, il serait préférable de directement conservé une référence à FileInfo, ou alors de le créer au Set de FilePathName. Enfin, tout est question de choix.

Bien deviné, c'est une propriété privée.
Dans le cas présent, le Path est utilisé pour d'autres choses et ne sert dans un FileInfo que pour cette méthode.
Merci pour le conseil tout de même, tout conseil est le bienvenue.