Le débogueur VS2008 conserve-t-il les objets hors champ?

Question

Donné ce bout de code:

// Get first key // 
int? keyEDISecurity = this.WorkQueue.GetNextWorkItem(); 

// Done? // 
while (keyEDISecurity != null) 
{ 
    try 
    { 

     ... 

     // Write changes // 
     List<ISNLEditableObject> changedRows = this.WorkQueue.GetChangedRows((int)keyEDISecurity); 
     this.Writer.Write(changedRows, WriteFlags.Transactional); 

     ... 
    } 
    catch (Exception ex) 
    { 
     // Exception handling/logging code 
    } 
    finally 
    { 
     // Remove all data for the KeyEDISecurity from work queue cache // 
     this.WorkQueue.RemoveData((int)keyEDISecurity); 
    } 

    // Get next work item // 
    keyEDISecurity = this.WorkQueue.GetNextWorkItem(); 
} 

Avant la ligne avec la déclaration Liste changedRows, changedRows est nul, comme cela devrait être. Il devient alors hors de portée, comme vous obtenez le prochain élément de travail. Vous revenez ensuite, et avant cette même ligne, si vous accédez à changedRows, il devrait être à nouveau nul, car il n'a pas été déclaré.

Si vous cassez et modifiez, comme prévu, vous ne pouvez pas accéder à changedRows, car il est hors de portée, et n'a pas encore été déclaré. Si vous l'évaluez (soit par le survol de la souris, soit en utilisant la fenêtre immédiate), vous avez accès aux changedRows de l'itération précédente de la boucle. WTH?

Vous avez vu ça? Il n'affecte pas le programme car il semble agir correctement dans le code, mais le problème du débogueur a causé une perte de temps car il ne se comportait pas comme prévu. Je me demandais si c'était un comportement attendu ou non, afin que je puisse savoir à l'avenir et ne pas perdre de temps avec elle.

Answer 1

Cette optimisation est spécifique à l'implémentation.

Lorsque la fonction est exécutée, toutes ses variables sont généralement créées sur la pile en même temps. Même si la langue ne permet pas encore d'y accéder, ils sont là. C'est pourquoi changedRows est null avant même d'avoir été déclaré.

Lorsque la variable est hors de portée, la langue ne permet pas de l'utiliser à nouveau, mais elle est toujours présente dans la pile. Sa valeur n'a pas besoin d'être changée en null, car elle ne sera utilisée nulle part. Ce sera le gaspillage du temps de processeur. C'est pourquoi la valeur de changedRows est conservée, même si, selon les règles du langage, elle doit être détruite (lorsqu'elle sort du cadre) et de nouveau créée (lorsqu'elle est déclarée). Le débogueur ne respecte pas toutes les règles de langage. En fait, il peut même être confondu par certaines constructions. Lorsque vous essayez d'obtenir la valeur d'une variable, le débogueur ne vérifie pas s'il est dans la portée, etc.