Class basic operators

Is it necessary to have a copy constructor, destructor and operator= in a class that have only static data member, no pointer

class myClass{
    int dm;
public:
     myClass(){
         dm = 1;
     }
     ~myClass(){ } // Is this line usefull ?
     myClass(const myClass& myObj){    // and that operator?
         this->dm = myObj.dm;
     }
     myClass& operator=(const myClass& myObj){    // and that one?
         if(this != &myObj){
             this->dm = myObj.dm;
         }
         return *this;
     }
};

I read that the compiler build one for us, so it is b开发者_Go百科etter to not have one (when we add a data member we have to update the operators)

---

If you can't think of anything for the destructor to do, you almost certainly don't need to define it, with the exception of a virtual destructor in a base class. And if you don't need a destructor, you almost certainly don't need to define the copy constructor and assignment operator, and should not do so, as it's easy to get them wrong.

---

No. The compiler will automatically copy-construct, destruct, and assign all data members automatically. This means that if you have a class where they're all provided, you don't need to write these. I think it's better design to write operators on a per-member basis anyway.

---

The compiler would provide those itself. By default the copy constructor / assignment operator would copy / assign all members (and base parts of the object if the class is derived), and the destructor does nothing (invokes the destructor of all members / bases, but this is something you can't change even if you provide your own - that happens after the body of the user-defined destructor is exited).

So in this case it is completely unnecessary. All you can achieve is to introduce bugs in the code (e.g you add another member, but forget to update the copy constructor to copy that as well).

---

 myClass& operator=(const myClass& myObj){    // and that one?
     if(this != &myObj){
         this->dm = myObj.dm;
     }
     return *this;
 }

I don't think you should take "check for self-assignment" dogmatically. Does anything bad happen when you assign an int to itself (even indirectly)?

int a = 10;
int& ref = a;
a = ref;

Avoiding self-assignment is only relevant if the assignment operator first destroys the resources currently held and then creates new ones from the object on the right-hand side. Then it would be a disaster to find out that you have actually indirectly destroyed the right-hand object too.

But even in that case, it would be better to first create the copy of the right-hand side and then destroy the contents of the left-hand side, in which case self-assignment is no problem (except potentially inefficient). For a good way to implement this, Google for copy and swap idiom.