2010-04-01 8 views
3

Question rapide: Je suis un gars C# debugging une application C++ donc je ne suis pas habitué à la gestion de la mémoire.Pointeurs dans les boucles For

Dans le code suivant:

for(int i = 0; i < TlmMsgDB.CMTGetTelemMsgDBCount(); i++) 
    { 
    CMTTelemetryMsgCls* telm = TlmMsgDB.CMTGetTelemetryMsg(i); 
    CMT_SINT32_Tdef id = telm->CMTGetPackingMapID(); 

    ManualScheduleTables.SetManualMsg(i,id); 
    ManualScheduleTables.SetManExec(i,false); 
    } 

Suis-je une fuite de mémoire chaque itération b/c de CMTTelemetryMsgCls* telm = TlmMsgDB.CMTGetTelemetryMsg(i);? La méthode "CMTGetTelemetryMsg (int)" renvoie un pointeur.

Dois-je "delete telm;" à la fin de chaque itération?

+2

Dépend de la bibliothèque. Vraiment. Lisez le manuel convivial. – kennytm

+0

Est-ce que 'TlmMsgDB.CMTGetTelemetryMsg (i)' alloue de la mémoire pour une instance? –

+0

Donc, il semble que j'ai besoin de lire la documentation lol. Je ferai ça. Merci tout le monde! – Blade3

Répondre

4

Il n'y a pas de réponse globale à cette question.

Cela dépend vraiment de la façon dont la personne a implémenté la fonction avec la valeur de retour.

  • Il peut retourner une variable allouée sur le tas et vous attendre à le supprimer
  • Il peut renvoyer un membre pointeur de variable même pas sur le tas
  • Si la valeur de retour est sur le tas, TlmMsgDB peut faire sa propre gestion de la mémoire

vous devez regarder la mise en œuvre de la fonction que vous appelez: TlmMsgDB.CMTGetTelemetryMsg

+5

... ou la documentation. – Juliano

+0

@Juliano: droit. –

+0

la bibliothèque renvoie l'adresse des données comme suit: return & TelemetryMsgDB [i]; Dois-je supprimer le pointeur dans ce cas? – Blade3

2

cela dépend. Si cette méthode TlmMsgDB.CMTGetTelemetryMsg alloue de la mémoire alors vous devez le libérer. Si elle renvoie simplement le pointeur sur quelque chose d'existant, alors

1

Si TlmMsgDB.CMTGetTelemetryMsg(i) alloue et renvoie un pointeur vers un nouvel objet CMTTelemetryMsgCls, alors oui. Vous devriez probablement delete l'objecter lorsque vous en avez terminé, en supposant que vous pouvez le faire en toute sécurité. La bibliothèque avec laquelle vous travaillez peut également effectuer une sorte de ramasse-miettes, alors lisez la documentation.

1

Dépend. Le problème avec l'utilisation de pointeurs de ce type est que si vous ne lisez pas la documentation de la fonction CMTGetTelemetryMsg, vous ne savez pas s'il a créé un nouveau pointeur et vous en a donné la propriété ou s'il vous donne un contrôle sur les données internes. c'est une mauvaise pratique. Si les docs disent que vous possédez maintenant le pointeur, alors oui vous devez supprimer sur chaque boucle. Si le pointeur est détenu et géré par TlmMsgDB, alors tout va bien.

1

Pas nécessairement. Cela dépend des internes de TlmMsgDB.CMTGetTelemetryMsg (i).

S'il retourne un nouvel objet à chaque fois ("new Something()"), alors oui, il fuit la mémoire, sans gestion de la mémoire. Cependant, le fait qu'il s'appelle "get" -quelque chose indique qu'il peut créer l'objet une fois, puis retourner le même pointeur lorsqu'il est appelé à nouveau. C'est probablement ce que ça fait, je suppose.

Espérons que cela éclaircira un peu les choses. :) Ces choses sont un peu étranges au début. ;)

1

Tout le monde a raison, ça dépend. Cependant, cela ne vous aide pas vraiment à déterminer si vous devez ou non appeler la suppression, à part quelqu'un ou quelque chose qui vous dit quel est le comportement. 1) Dans votre débogueur, cassez avant que la boucle ne commence, puis faites un arrêt dans n'importe quelle fonction alloue de la mémoire (par exemple malloc, mmap, brk) et voyez si ça s'arrête.Il ne s'agit pas d'une preuve infaillible, mais vous pouvez essayer de faire un pas pour voir l'adresse retournée, puis vérifier l'adresse finalement retournée par la fonction CMTGetPackingMapID. 2) Une façon moins précise mais plus simple de dire «y a-t-il une allocation à l'intérieur de cette fonction?» Est d'utiliser la version de strace/ltrace de votre système. peut-être dormir juste avant la boucle pour le rendre facile de dire où vous êtes dans la trace.

3) Regardez l'équivalent de votre système de haut pour voir si vous êtes leeking

Notez que C++ est un langage mal et rien ne peut vraiment vous dire avec certitude à l'exception du code. Par exemple, il n'y a rien qui empêche le comportement réellement correct d'avoir à supprimer certains niveaux de membre 10 profondément dans l'objet que vous avez un pointeur. Ou même que Dieu lui interdise d'avoir à le libérer parce que la classe appelle réellement malloc quelque part au plus profond de ses profondeurs.

0

Essayez d'utiliser le profileur. Il peut vous fournir des informations utiles sur la gestion de la mémoire exécutée dans le processus en cours de profilage. Ou, mieux encore, vous pouvez utiliser quelque chose comme SoftICE, il vous permet de définir un point d'arrêt à toute fonction qui alloue de la mémoire, par exemple HeapAllocEx. En utilisant un tel outil, vous déterminerez certainement le comportement réel du code de partie 3-rt, même sans les sources.

Questions connexes