Pourquoi la mémoire est toujours accessible après std::map::clear() est appelée?

J'observe un comportement étrange de std::map::clear(). Cette méthode est censée appeler l'élément destructeur lorsqu'il est appelé, cependant le souvenir est encore accessible après l'appel à clear().

Par exemple:

struct A
{
  ~A() { x = 0; }
  int x;
};

int main( void )
{
  std::map< int, A * > my_map;
  A *a = new A();
  a->x = 5;
  my_map.insert( std::make_pair< int, *A >( 0, a ) );

  //addresses will be the same, will print 5
  std::cout << a << " " << my_map[0] << " " << my_map[0]->x << std::endl;

  my_map.clear();

  //will be 0
  std::cout << a->x << std::endl;

  return 0;
}

La question est, pourquoi est variable a toujours accessible après son destructeur est appelé par carte::clear()? Dois-je écrire delete a; après l'appel de my_map.clear() ou est-il sûr d'écraser le contenu de a?

Merci d'avance pour votre aide,
sneg

  • Essayez d'utiliser à() pour y accéder ne vous permettront pas d'accéder à quelque chose qui n'existe pas pour l'exemple: ideone.com/ZeRTnd (si l'élément avec la touche "B" a été défini avant, après la carte.clear() pour accéder à la touche "B" vous permet de vous 'std::out_of_range' exception
InformationsquelleAutor sneg | 2009-02-20
  1. 20

    std::map ne gère pas la mémoire pointé par le pointeur valeurs - c'est à vous de le faire vous-même. Si vous ne voulez pas utiliser les pointeurs intelligents, vous pouvez écrire un usage général, libre & désactivez la fonction comme ceci:

    template <typename M> void FreeClear( M & amap ) 
    for ( typename M::iterator it = amap.begin(); it != amap.end(); ++it ) {
        delete it->second;
    }
    amap.clear();
}

    Et de l'utiliser:

    std::map< int, A * > my_map;
//populate
FreeClear( my_map )

    ;

    InformationsquelleAutor
  2. 22

    Si vous stocker des pointeurs sur une carte (ou une liste, ou quelque chose comme ça) VOUS sont responsables de la suppression de l'pointeurs, puisque la carte ne sais pas si ils ont été créés avec le nouveau, ou pas. La fonction clear seulement invoque les destructeurs si vous n'utilisez pas les pointeurs.

    Oh, et encore une chose: en invoquant un destructeur (ou même l'appel de supprimer) ne signifie pas que la mémoire ne peut pas être plus accessible. Cela signifie seulement que vous aurez accès à ordures si vous n'.

    • Il ne menas que vous peut accéder à ordures, mais parfois, vous avez accès à une zone qui n'est pas devenu ordures pourtant, il semble donc à travailler pendant un certain temps. C'est pourquoi "mais ça fonctionne, donc je peux sortir avec elle" est totalement faux.
    InformationsquelleAutor Marc
  3. 4

    C'est parce que map.clear() appels destructeurs des données contenues dans la carte, dans votre cas, le pointeur de a. Et ce n'est rien.

    Vous pourriez mettre une sorte de pointeur intelligent dans la carte de la mémoire occupée par a être automatiquement récupéré.

    BTW, pourquoi mettez-vous le modèle arguments dans l'appel à make_pair? L'argument de modèle déduction doit faire assez bien ici.

    • Donc, si je ne l'utilise pas n'importe quelle sorte de pointeur intelligent classes, ai-je besoin d'aller à travers la carte manuellement delete chaque élément? Comment puis-je effacer la carte après que? Je veux dire, clear() essaiera d'appeler les destructeurs des éléments qui ont déjà été supprimés.
    • Il suffit de supprimer tous vos pointeurs, et ensuite appeler clear(). Comme jpalecek vous l'a dit, appeler le destructeur d'un pointeur (ce qui est totalement différent de l'appel de la desructor de l'objet qu'il désigne) ne fait rien.
    • Juste pour clarifier: si vous stockez des objets réels dans une carte, son destructeur sera appelé. Mais si vous stocker des pointeurs (n'importe quel type de pointeur), la carte savons seulement qu'il a un tas de sens pointeurs, et de les traiter comme ce qu'ils sont essentiellement: les entiers représentant les adresses mémoire.
    • Merci, Marc. Je comprends maintenant. Dans mon extrait de code ci-dessus destructeur de struct A t appelée. I. e. élément x est mis à 0. Je craignais que si je supprime cette instance de struct A carte.clear() essaie d'appeler le destructeur de nouveau.
    • sneg-vx: C'est étrange. Je l'ai essayé avec gcc 4.3 et a obtenu 5 deux fois dans la sortie, afin que le destructeur n'était pas appelé (comme le standard dit).
    • Effectivement, vous avez raison. C'était quelque chose d'étrange, j'ai rencontré. Je viens de testé sur des VS2008 et gcc 4.1.1 et le destructeur n'est pas appelé. Merci encore pour votre aide.

    InformationsquelleAutor jpalecek
  4. 1

    Lorsque vous libre un morceau de mémoire dans la mémoire, son contenu n'obtenez pas remis à zéro. Ils sont seulement disponible pour l'attribution de nouveau. Bien sûr, vous devriez envisager la mémoire non accessible, parce que les effets de l'accès à la mémoire non ne sont pas définis.

    Effectivement empêcher l'accès à une page de la mémoire qui se passe à un niveau inférieur, et les mst bibliothèques ne pas le faire.

    Lorsque vous allouer de la mémoire à nouveau, vous devez les supprimer vous-même, sauf si vous utilisez un pointeur intelligent.

    InformationsquelleAutor John Smith
  5. 0

    Tout conteneur des magasins de votre Type d'objet et l'appel correspondant constructeurs: code interne de chaque nœud peut ressembler à:

    __NodePtr
{
    *next;
    __Ty    Val;
}

    Lorsque vous allouez il se passe par la construction de la val basés sur le type et puis de la liaison. Quelque chose de similaire à:

    _Ty _Val = _Ty();
_Myhead = _Buynode();
_Construct_n(_Count, _Val);

    Lorsque vous supprimer des appels correspondant destructeurs.

    Lorsque vous stockez des références (pointeurs), cela n'appelle pas de tout constructeur, ni qu'il va détruire.

    InformationsquelleAutor FL4SOF
  6. 0

    Avoir passé les 2 derniers mois, l'alimentation, le sommeil, la respiration et les cartes, j'ai une recommandation. Laissez la carte d'allouer ses propres données chaque fois que possible. C'est beaucoup plus propre, pour exactement le genre de raisons pour lesquelles vous êtes mettant en évidence ici.

    Il y a aussi quelques subtiles avantages, comme si vous copiez des données à partir d'un fichier ou d'un socket de la carte de données, le stockage de données existe dès que le nœud existe parce que quand la carte des appels à malloc() pour allouer le nœud, il alloue de la mémoire pour à la fois la clé et les données. (AKA carte[key].la première et la carte[key].la seconde)

    Cela vous permet d'utiliser l'opérateur d'affectation au lieu de memcpy(), et nécessite 1 moins appel à malloc() - celui que vous faites.

    IC_CDR CDR, *pThisCDRLeafData;  //a large struct{}

    while(1 == fread(CDR, sizeof(CDR), 1, fp))  {
    if(feof(fp)) {
        printf("\nfread() failure in %s at line %i", __FILE__, __LINE__);
    }
    cdrMap[CDR.iGUID] = CDR; //no need for a malloc() and memcpy() here    
    pThisCDRLeafData  = &cdrMap[CDR.iGUID]; //pointer to tree node's data

    Quelques mises en garde d'être au courant de l'méritent d'être soulignés ici.

    1. ne PAS appeler malloc() ou nouveau dans la ligne de code qui ajoute le nœud de l'arborescence de votre appel à malloc() renvoie un pointeur AVANT de la carte de l'appel à malloc() a alloué un lieu de votre retour de malloc().
    2. en mode Debug, attendez-vous à avoir des problèmes similaires lors de la tentative de free() de votre mémoire. Deux de ceux-ci semblent comme compilateur de problèmes pour moi, mais au moins dans MSVC 2012, ils existent et sont un grave problème.

    3. donner une certaine pensée de l'endroit où le "point d'ancrage" de vos cartes. C'est à dire: où elles sont déclarées. Vous ne voulez pas aller en dehors de la portée par erreur. main{} est toujours en sécurité.

      INT _tmain(INT argc, char* argv[])    {
IC_CDR      CDR, *pThisCDRLeafData=NULL;
CDR_MAP     cdrMap;
CUST_MAP    custMap;
KCI_MAP     kciMap;

    4. J'ai eu de très bonne chance, et je suis très heureux d'avoir une critique de la carte d'allouer une structure du nœud de données, et d'avoir cette structure de "point d'ancrage" une carte. Alors que les anonymes, les structures ont été abandonnés par le C++ (un horrible, horrible décision qui devait être renversée), les cartes sont la 1ère struct membre fonctionnent de la même façon anonyme des structures. Très lisse et propre avec une taille de zéro effets. En passant un pointeur vers la feuille appartenant struct, ou une copie de la structure par valeur dans un appel de fonction, les deux fonctionnent très bien. Fortement recommandé.

    5. vous pouvez intercepter les valeurs de retour .insert pour déterminer si elle a trouvé un nœud existant sur cette touche, ou créé un nouveau. (voir n ° 12 pour le code) à l'Aide de l'indice de notation ne permet pas ceci. Il pourrait être préférable de s'installer sur .insérer et coller avec elle, surtout parce que le [] de notation ne fonctionne pas avec multimaps. (il n'aurait aucun sens de le faire, comme il n'y a pas la touche "a", mais une série de touches avec les mêmes valeurs dans une multimap)
    6. vous pouvez, et devez, également piéger les retours pour .effacer et .empty() (OUI, c'est ennuyeux que certaines de ces choses sont des fonctions, et ont besoin de la () et certains, comme .effacer, ne le font pas)
    7. vous pouvez obtenir à la fois la valeur de la clé et la valeur des données pour n'importe quelle carte nœud à l'aide .premier et .la seconde, qui a toutes les cartes, par convention, l'utilisation de retourner la clé et les données respectivement

    8. vous sauver vous-même une quantité ÉNORME de la confusion et de la dactylographie, et l'utilisation typedefs pour vos cartes, comme si.

      typedef map<ULLNG, IC_CDR>      CDR_MAP;    
typedef map<ULLNG, pIC_CDR>     CALL_MAP;   
typedef struct {
    CALL_MAP    callMap;
    ULNG        Knt;         
    DBL         BurnRateSec; 
    DBL         DeciCents;   
    ULLNG       tThen;       
    DBL         OldKCIKey;   
} CUST_SUM, *pCUST_SUM;
typedef map<ULNG,CUST_SUM>  CUST_MAP, CUST_MAP;  
typedef map<DBL,pCUST_SUM>  KCI_MAP;

    9. passer des références de cartes à l'aide de la définition de type et & opérateur comme dans

      ULNG DestroyCustomer_callMap(CUST_SUM Summary, CDR_MAP& cdrMap, KCI_MAP& kciMap)

    10. utiliser la fonction "auto" type de variable pour les itérateurs. Le compilateur va déterminer le type spécifié dans le reste de la boucle for() organisme de ce type de carte typedef à utiliser. C'est très propre, c'est presque de la magie!

      for(auto itr = Summary.callMap.begin(); itr!= Summary.callMap.end(); ++itr) {

    11. définir certains manifeste constantes pour améliorer le rendement .effacer et .empty() plus significatif.

      if(ERASE_SUCCESSFUL == cdrMap.erase (itr->second->iGUID)) {

    12. étant donné que les "pointeurs intelligents" sont vraiment juste de garder un nombre de références, n'oubliez pas que vous pouvez toujours garder votre propre compte de référence, un probablement dans un nettoyant, et de manière plus nette. En combinant ceci avec le n ° 5 et n ° 10 ci-dessus, vous pouvez écrire quelques belles nettoyer le code comme ceci.

      #define Pear(x,y) std::make_pair(x,y) // some macro magic

auto res = pSumStruct->callMap.insert(Pear(pCDR->iGUID,pCDR));
if ( ! res.second ) {
    pCDR->RefKnt=2;
} else {
    pCDR->RefKnt=1;
    pSumStruct->Knt += 1;
}

    13. l'aide d'un pointeur à accrocher sur une carte nœud qui alloue tout pour lui-même, c'est à dire: aucun utilisateur pointeurs pointant vers l'utilisateur malloc()é objets de, fonctionne bien, est potentiellement plus efficace, et la et la être utilisés pour muter les données d'un nœud sans effets secondaires dans mon expérience.

    14. sur le même thème, par exemple un pointeur peut être utilisé très efficacement pour préserver l'état d'un nœud, comme dans pThisCDRLeafData ci-dessus. En la passant à une fonction qui mute/changements particulier du nœud de données est plus propre que de passer une référence à la carte et la clé nécessaire pour revenir au nœud pThisCDRLeafData pointe.

    15. les itérateurs sont pas de la magie. Ils sont coûteux et lent, comme vous vous naviguez sur la carte pour obtenir les valeurs. Pour un plan de la tenue d'un million de valeurs, vous pouvez lire un nœud selon une clé à environ 20 millions de dollars par seconde. Avec les itérateurs c'est probablement ~ 1000 fois plus lent.

    Je pense que sur le couvre pour l'instant. Sera mise à jour si l'une de ces modifications ou il y a d'autres points de vue à partager. Je suis appréciant tout particulièrement l'aide de la STL avec du code C. C'est à dire: pas une classe en vue de n'importe où. Ils n'ont tout simplement pas de sens dans le contexte, je suis en train de travailler dans, et il n'est pas un problème. Bonne chance.

    • Alors qu'un peu d'un compromis, d'avoir la Carte d'allouer ses propres données au lieu d'un pointeur pour contenir le retour de votre malloc() peut aussi être plus efficace en terme de mémoire, depuis votre malloc() et la Carte malloc nécessaire pour stocker vos données seront de la même taille, l'enregistrement de la mémoire requise pour la redondants pointeur. Les pointeurs 64 bits ajouter jusqu'à un lot de stockage. C'est échangée contre intérieure nœuds de la Carte/Arbre allocation d'espace pour stocker des choses qu'ils ne pourront jamais en magasin même si il garde le tas de fragmentation, puisque tous les malloc()s sont de la même taille quand les nœuds sont ajoutés ou supprimés.
    • Vous pourriez ajouter, est d'utiliser malloc() à la place de new(), comme il n'a pas de sens d'allouer et de memset() de la mémoire avec new() lorsque vous êtes dans le processus de memcpy()ing données dans ce nouveau stockage. C'est une totale et complète des déchets de tout le temps nécessaire pour initialiser le stockage. Si vous voulez faire cela pour des fins de débogage, utiliser calloc(). La STL utilise malloc() et free() en interne, afin de prendre que de repère et de courir avec lui.
    InformationsquelleAutor user2548100