Class destructor c++

I've got a question about destructors in c++.

I've got a class like this :

class X {  

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

Here are some information concerning 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;

If I don't want to delete the m_modulType the m_powerDomain and m_father (becaus开发者_运维问答e they are likely to be referred to by another object), do I have to explicitely write a destructor method ?

I know that string is a standard object and will be destroy by its own destructor, but will the ConnexionHashMap be destroyed by the standard hashmap template destructor or should i delete it manually somehow ?

(also on a sidenote is there an easy way to see how my memory is managed while my program is running on Eclipse cdt ? )

If I don't want to delete the m_modulType the m_powerDomain and m_father (because they are likely to be referred to by another object, do I have to explicitely write a destructor method?

m_powerDomain, m_father, and m_modulType are pointers and the objects they point to will not be deleted unless you do so explicitly. So, you should write a destructor if you want them to be deleted, otherwise they need not.

I know that string is a standard object and will be destroy by its own destructor, but will the ConnexionHashMap be destroyed by the standard hashmap template destructor or should i delete it manually somehow ?

It is not that std::string are standard object that will make them deleted automatically, but the fact that you are including a std::string in your class as a member, so the string is physically allocated inside of your object memory and when this one is deleted the former is also (without need of specifying anything in the destructor).

All the same, m_connexions, which is included as an object member, not pointer, will be automatically deleted by the destructor, no need to do anything.

(also on a sidenote is there an easy way to see how my memory is managed while my program is running on Eclipse cdt ? )

you can use a profiler like valgrind or any other you find available...

The hash_map is deleted since it is a member of the class X. The objects that are addressed with pointers are not deleted, you will have to write a destructor, if you need to delete these objects.

Local variables in a class will be deleted automatically when the class is deleted (even without an explicit destructor).

A user-defined destructor is used to delete pointer-held variables, and free resources held by the class.

You can avoid any problems here by just using boost::shared_ptr (std::shared_ptr in C++0x) for objects that are shared. It uses reference counting to keep track of references to the object, and deletes the objects once the last reference is gone.

As for your questions, all member objects that are not pointers or references will be destroyed when the containing object is destroyed. That includes your hash-map

Some basic principles:

• The destructors of all non-static member objects will be called in the destructor of your object. Regardless of whether you define a destructor or not; there is no way of changing this.
• Destructors of the basic types, pointer types and reference types are no-ops. Always. If you want something to happen on them, you must provide a user defined destructor, and make it happen there.
• Standard containers (and all of the pre-standard hash_map) contain by value; the contents of your ConnectionHashMap are copies of whatever you inserted, and will be destructed by the destructor of the hash map. (I'm not sure whether or how this is relevant to your code. A lot depends on the lifetime of what net points to, and how that is managed. Depending on the application and the design, it might make sense to make Connection::net a boost::shared_ptr. Might: it's not a foregone conclusion that this is a good idea.)