Q:

overlading assignment operator in c++ using return by value

Considering : 
    class MyObject{
    public:
     MyObject();
     MyObject(int,int);
     int x;
     int y;
     MyObject operator =(MyObject rhs);
    };
    MyObject::MyObject(int xp, int yp){
     x = xp;
     y = yp;
    }
    MyObject MyObject::operator =(MyObject rhs){
     MyObject temp;
     temp.x = rhs.x;
     temp.y = rhs.y;
     return temp;
    }

    int main(){
     MyObject one(1,1);
     MyObject two(2,2);
     MyObject three(3,3);
     one = two = three;
     cout << one.x << ", " << one.y;
     cout << two.x << ", " << two.y;
     cout << three.x << ", " << three.y;

    }

By doing this, the variables x and y in one,two and three are unchanged. I know that I should update the member variables for MyObject and use return by reference and return *this for proper behaviour. However, what actually happens to the return values in one = two = three ? Where does the return temp actually end up in the chain, like step by step ? 

A:

The call to the assignment operator in
two = three

returns a temporary object as rvalue. This is of type MyObject and is passed on to the next call of the assignment operator
one = t

(I use t to refer to the temporary object.)
Unfortunately, this won't compile because the assignment operator expects a reference MyObject&, and not an rvalue of type MyObject.
(Your code won't compile for various reasons, including uppercased Class and typos, too.)
However, if you were to define an assignment operator that takes an rvalue (i.e. takes the argument by value, const-reference, or indeed by rvalue reference MyObject&& if C++11 is used), the call would work and the temporary object would be copied into the function. Internally, assignments would be made and another temporary object would be returned.
The final temporary object would then go out of scope, i.e. cease to exist. There would be no way to access its contents.

Thanks for Joachim Pileborg and Benjamin Lindley for the helpful comments.

To answer the request for more details: MyObject is a class type, and the C++ Standard  includes an entire section on the life cycle of temporary objects of class type (Section 12.2). There are various complex situations that are detailed there in length, and I won't explain them all. But the basic concepts are as follows:

C++ has the notion of expressions. Expressions are, along with declarations and statements, the basic units the code of the program is composed of. For example, a function call f(a,b,c) is an expression, or an assignment like a = b. Expressions may contain other expressions: a = f(b,c), a function call nested in an assignment expression. C++ also introduces the concept of full-expressions. In the previous example, c is part of the expression f(b,c), but also of a = f(b,c), and if that is not nested in another expression, we say that a = f(b,c) is the full-expressions that lexically contains c.
The Standard defines a variety of situations where temporary objects may be created. One such situation is the returning of an object by value from a function call (aka returning a prvalue, §6.6.3).
The Standard states that the life time of such a temporary object ends when the full-expression that contains it has been fully evaluated:

[...] Temporary objects are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created. [...]

(Note. The Standard then goes on to define several exceptions to this rule. The case of the return value of your assignment operator, however, is not such an exception.)
Now, what does it mean that an object (of class type) is destroyed? It means, first and foremost, that its destructor is called (§12.2/3). It also means that the storage for that object can no longer be safely accessed. So if you somehow managed to store the address of the temporary object in a pointer before the evaluation of the full-expression has ended, then derefencing that pointer after the evaluation has ended generally causes undefined behaviour.
In practice, this may in many cases mean the following – I describe the entire life cycle of the temporary object in one possible scenario:

To provide for storage for the temporary, the compiler makes sure that sufficient stack space is allocated when the function that contains the full-expression is entered (this happens before the full-expression is actually evaluated).
During the evaluation of the assignment expression, the temporary is created. The compiler makes sure that its constructor is called to initialise the space that was allocated for it.
Then the contents of the temporary may be accessed or modified in the course of the evaluation of the full-expression it is part of.
When the expression has been fully evaluated (in your case, this moment corresponds to the end of the line that contains the assignment expression), the destructor for the temporary is called. After that it is no longer safe to access the memory that was allocated for it, although in reality that space will continue to be part of the current stack frame until the evaluation of the function in which all of this happens has finished.

But, again, this is only an example of what may happen. The creation of temporaries is in many situations not actually required. The compiler may perform optimizations that mean the temporary is never actually created. In this case, the compiler must nevertheless ensure that it could have been be created, e.g. it must ensure that the required constructors and destructors exist (they may never be called though).

