Класс деструктор с ++ - PullRequest
0 голосов
/ 25 мая 2011

У меня есть вопрос о деструкторах в c ++.

У меня есть такой класс:

class X {  

private:
    string m_instanceName
    string m_path;
    ConnexionHashMap m_connexions;
    Module** m_moduleType;
    Powerdomain* m_powerDomain;
    Module ** m_father;
};  

Вот некоторая информация о ConnexionHashMap:

typedef hash_map<const string, Connexion, strptrhash, strptrequal> ConnexionHashMap;

struct Net{
     string name;
     vector<string> connectedPins;
     bool isPin;
};

typedef struct Net Net;

struct Connexion{
    string pin;
    Net* net;
};

typedef struct Connexion Connexion;

Если я не хочу удалять m_modulType m_powerDomain и m_father (потому что они могут быть вызваны другим объектом), должен ли я явно написать метод деструктора?

Я знаюэта строка является стандартным объектом и будет уничтожена его собственным деструктором, но будет ли ConnexionHashMap уничтожен стандартным деструктором шаблона hashmap или я должен каким-то образом удалить его вручную?способ посмотреть, как управляется моя память, когда моя программа работает на Eclipse cdt?)

Ответы [ 5 ]

2 голосов
/ 25 мая 2011

Если я не хочу удалять m_modulType, m_powerDomain и m_father (поскольку они могут ссылаться на другой объект, нужно ли явно писать метод деструктора?

m_powerDomain, m_father и m_modulType являются указателями, и объекты, на которые они указывают, не будут удалены, если вы не сделаете это явно. Поэтому вы должны написать деструктор, если хотите, чтобы они были удалены, в противном случае они нуждаются внет.

Я знаю, что строка является стандартным объектом и будет уничтожена его собственным деструктором, но будет ли ConnexionHashMap уничтожаться стандартным деструктором шаблона hashmap или я должен каким-то образом удалить его вручную?*

Дело не в том, что std::string - это стандартный объект, который автоматически удаляет их, а в том, что вы включаете std::string в свой класс в качестве члена, поэтому строка физически размещается внутрипамять вашего объекта и когда этот удален, первый также (без необходимости указывать что-либо в деструctor).

Все равно, m_connexions, который включен как элемент объекта, а не указатель, будет автоматически удален деструктором, не нужно ничего делать.

(такжена sidenote есть простой способ увидеть, как моя память управляется, когда моя программа работает на Eclipse cdt?)

вы можете использовать профилировщик, такой как valgrind или любой другой, который вы найдете в наличии ...

2 голосов
/ 25 мая 2011

Локальные переменные в классе будут удаляться автоматически при удалении класса (даже без явного деструктора).

Определяемый пользователем деструктор используется для удаления переменных, содержащих указатель, и свободных ресурсов, удерживаемых классом.

2 голосов
/ 25 мая 2011

hash_map удаляется, так как он является членом класса X. Объекты, адреса которых указываются, не удаляются, вам придется написать деструктор, если вам нужно удалить эти объекты.

2 голосов
/ 25 мая 2011

Вы можете избежать любых проблем, просто используя boost::shared_ptr (std::shared_ptr в C ++ 0x) для общих объектов. Он использует подсчет ссылок для отслеживания ссылок на объект и удаляет объекты после исчезновения последней ссылки.

Что касается ваших вопросов, все объекты-члены, которые не являются указателями или ссылками, будут уничтожены при уничтожении содержащего объекта. Это включает в себя вашу хэш-карту

1 голос
/ 25 мая 2011

Некоторые базовые принципы:

  • Деструкторы всех нестатических объектов-членов будут вызываться в деструкторе вашего объекта.Независимо от того, определяете ли вы деструктор или нет; нет способа изменить это.
  • Деструкторы базовых типов, типов указателей и ссылочных типов не имеют значения.Всегда.Если вы хотите, чтобы что-то произошло с ними, вы должны предоставить деструктор, определенный пользователем, и сделать так, чтобы это произошло.
  • Стандартные контейнеры (и все предстандартные hash_map) содержат значение;содержимое вашей ConnectionHashMap является копией того, что вы вставили, и будет уничтожено деструктором хэш-карты.(Я не уверен, имеет ли это отношение к вашему коду или насколько это важно. Многое зависит от времени жизни того, на что указывает net, и от того, как им управляют. В зависимости от приложения и дизайна это может имеет смысл сделать Connection::net a boost::shared_ptr. Могущество : это не предрешено, что это хорошая идея.)
...