Question

i m trying to make a simple program ( & yes , it is a homework ) that can generate Dates , & like most of normal people : i made my Class attributes private , i tried to send the same type that i m working on to the constructor but the complier have not accept it , i did some research & i found out that in cases like that people generously send a const “type” reference to the constructor witch meant to me that have not understand OOP well
so why do we have to send the const ” type ” reference instead of just the types name to the constructor ? & please give me some links or websites for beginners
here is a peace of my Code :

 class Date {  
     int d ;   
     int m ;   
     int y ;   
 public :   
      Date();   
      Date(int , int , int);   
      Date(const Date &);// my question is : why do we have to write this instead of Date( Date )   
 };

PS : sorry for my English

Answer 1

To paraphrase our question:

why do we have to write Date(const Date &) instead of Date(Date)?

I’m going to split this into two parts, the first answering why a copy constructor needs to take its argument per reference, the second why this needs to be a const reference.

---

The reason a copy constructor needs to take its argument per reference is that, for a function that’s taking an argument per copy void f(T arg), when you call it f(obj), obj is copied into arg using T‘s copy constructor. So if you want to implement the copy constructor, you’d better not take the argument by copy, because this would call the copy constructor while invoking it, leading to an endless recursion. You can easily try this yourself:

struct tester {
  tester(tester) {std::cout << "inside of erroneous copy ctor\n";}
};

int main()
{
  tester t1;
  std::cout << "about to call erroneous copy ctor\n";
  tester t2(t1);
  std::cout << "done with call erroneous copy ctor\n";
  return 0;
}

That program should only ever write one line and then blow the stack.
Note: As Dennis points out in his comment, actually this program is not guaranteed to compile, so, depending on your compiler, you might not really be able to try it.

Bottom line: A copy constructor should take its argument by reference, because taking it per copy would require the copy constructor.

---

That leaves the question of why it is const T& and not simply T&? In fact, there are two reasons for that.
The logical reason is that, when you invoke the copy constructor, you do not expect the object copied from to change. In C++, if you want to express that something is immutable, you use const. This tells users that they can safely pass their precious objects to your copy constructor, because it won’t do anything with it except read from it. As a nice side effect, if you implement the copy constructor and accidentally try to write to the object, the compiler throws an error message at you, reminding you of the promise made to the caller.
The other reason is that you cannot bind temporary objects to non-const references, you can only bind them to const references. A temporary object is, for example, what a function might return:

struct tester {
  tester(tester& rhs) {std::cout << "inside of erroneous copy ctor\n";}
};

tester void f()
{
   tester t;
   return t;
}

When f() is called, a tester object is created inside, and a copy of it is then returned to the caller, which might then put it into another copy:

tester my_t = f(); // won't compile

The problem is that f() returns a temporary object, and in order to call the copy constructor, this temporary would need to bind to the rhs argument of tester‘s copy constructor, which is a non-const reference. But you cannot bind a temporary object to a non-const reference, so that code won’t compile.
While you can work around this if you want (just don’t copy the temporary, but bind it to a const reference instead, which extends the temporary’s lifetime to the end of the reference’s lifetime: const tester& my_t = f()), people expect to be able to copy temporaries of your type.

Bottom line: A copy constructor should take its argument by const reference, because otherwise users might not be willing or able to use it.

---

Here’s one more fact: In the next C++ standard, you can overload functions for temporary objects, so-called rvalues. So you can have a special copy constructor that takes temporary objects overloading the “normal” copy constructor. If you have a compiler that already supports this new feature, you can try it out:

struct tester {
  tester(const tester&  rhs) { std::cout << "common copy ctor\n"; }
  tester(      tester&& rhs) { std::cout << "copy ctor for rvalues\n"; }
};

When you use the above code to invoke our f()

tester my_t = f();

the new copy constructor for rvalues should be called when the temporary object returned by the call to f() is copied to my_t and the regular copy constructor might be called in order to copy the t object from inside of f() to the returned temporary. (Note: you might have to disable your compiler’s optimization in order to see this, as the compiler is allowed to optimize away all the copying.)
So what can you with this? Well, when you copy an rvalue, you know that the object copied from is going to be destroyed after the call to the copy constructor, so the copy constructor taking an rvalue (T&&) could just steal the values from the argument instead of copying them. Since the object is going to be destroyed anyway, nobody is going to notice.
For some classes (for example, for string classes), moving the value from one object to another could be much cheaper than copying them.