|
Hey George, wait a moment, throw out your book, that's recursive junk!!!!!!!!!!!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Why CPallini? More information please?
regards,
George
|
|
|
|
|
George you're a quite smart guy: I think you'll soon reckon than calling the equal operator inside its very definition causes a theoretical endless function call loop and a practical stack overflow.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I agree and I think it depends on how swap is implemented. If swap is implemented by assignments of POD types, I think it is safe.
regards,
George
|
|
|
|
|
Nope, my friend, the line
temp = a;
causes infinite recursion no matter how swap is implemented.
BTW could you please post the original B. Stroustrup's sample (toxcct told me about...  )?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
This is not Bjarne's sample.
This question is what I learned that swap could be used to design and implement an exception safe assignment operator. Yes, there is some issues in my code.
I think you are well known about how to use swap to implement exception safe assignment opeator from your replies. Could you help to correct my code please?
regards,
George
|
|
|
|
|
George_George wrote: This question is what I learned that swap could be used to design and implement an exception safe assignment operator.
Well, I think you learned about reading any book (or article). Please reference it, if you can.
George_George wrote: I think you are well known about how to use swap to implement exception safe assignment opeator from your replies. Could you help to correct my code please?
In fact, no. I've grasped the main idea from your sample code, but I wasn't aware of that technique, hence I cannot try to fix the code simply guessing about (if it is a well established pattern, then we need a state-of-art example)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks for your comment, CPallini!
Let us wait for other MVP's reply.
regards,
George
|
|
|
|
|
George_George wrote: Let us wait for other MVP's reply.
And, of course, for replies of any other member.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Yes. but I believe that the state of the parameter only may throw an exception, if its state is corrupted.
that's why we do a temporary assignement (temp = a) to check first if assigning a to something else would not crash.
so if a is OK, then swapping it with this would be OK too...
|
|
|
|
|
Well, even ignoring the recursion madness of George sample code, I think that swap may take care about, since it will perhaps be coded in a way similar to the following:
A temp;
temp = a;
a = *this;
*this = temp;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
that's how swap is normally designed.
however, there's a lack in this design, because having a A::operator=() calling a A::swap() function, which itself calls A::operator=() 3 more times is recursive for sure, with no possibility to stop the loop.
so I think swap is not coded like this in B. Stroustrup's example...
|
|
|
|
|
toxcct wrote: that's how swap is normally designed.
The above I was suggesting: hence no need to create a temporary assignment before it.
toxcct wrote: however, there's a lack in this design, because having a A::operator=() calling a A::swap() function, which itself calls A::operator=() 3 more times is recursive for sure, with no possibility to stop the loop.
so I think swap is not coded like this in B. Stroustrup's example...
I agree that there is recursion in the sample code (after all I was the first pointing out it...) and I was not suggesting to take that code as it stands, suppose, for instance, that method name was foo, instead of operator==.
BTW I think that swap should rely on the assignment operator and not the opposite (but I've not Stroustrup's example, that of course I suppose correct, at hand, I think George is not a diligent poster recently... )
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
I agree that there is some issue in my code. It is appreciated if you could provide some pseudo code to correct my code to implement the using swap technique to implement a exception safe assignment operator.
regards,
George
|
|
|
|
|
George_George wrote: I agree that there is some issue in my code.
Some issue? Some issue? Some issue?
I won't call 'some issue' going into infinite recursion while aiming to provide an 'exception safe' operator.
Just kidding... ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
George_George wrote: It is appreciated if you could provide some pseudo code to correct my code to implement the using swap technique to implement a exception safe assignment operator.
Oh no, you made the original post: that's your side of the game.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I have searched some answers, but I do not think it works. Because either copy constructor or swap will potentially call assignment operator again.
Any ideas?
A& A::operator=(const A& other)
{
A temp(other);
swap(temp);
return *this;
}
regards,
George
|
|
|
|
|
hey, you want an exception safe copy ?
backup your object, then assign it the new object, and if it fails, restore its backup !
|
|
|
|
|
Thanks toxcct,
I agree with the general rule. But how to avoid the recursive invocation of assignment operator in your comments? Could you provide some code please?
regards,
George
|
|
|
|
|
toxcct wrote: hey, you want an exception safe copy ?
backup your object,
or take a picture of it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi toxcct,
I think in such pattern, swap should be implemented to a list of assignments of POD types, right?
BTW: if I am wrong, please help to correct code in your senses.
regards,
George
|
|
|
|
|
Thanks toxcct,
I agree that there is some issue in my code. It is appreciated if you could provide some pseudo code to correct my code to implement the using swap technique to implement a exception safe assignment operator.
regards,
George
|
|
|
|
|
Hi CPallini,
The code will cause recursive to invoke assignment operator?
regards,
George
|
|
|
|
|
Hi toxcct,
Two more comments.
1.
We are talking about the state of current object instance (this object), why you are talking about the state of parameter?
toxcct wrote: Yes. but I believe that the state of the parameter only may throw an exception, if its state is corrupted.
2.
I do not 100% agree. Since swap will create another new temporary object used to do swap. The creation of new temporary object may cause bad_alloc exception.
toxcct wrote: so if a is OK, then swapping it with this would be OK too...
regards,
George
|
|
|
|
|
George_George wrote: We are talking about the state of current object instance (this object), why you are talking about the state of parameter?
1) because : if the state of the parameter is corrupted, the state of the current object could have been corrupted too. but as long as we're assigning a temporary object first, the current object's assignment is exception-safe !
2) not sure for this one. isn't bad_alloc sent only when allocating memory on the heap (using new) ? here, temp is on the stack though !
|
|
|
|
|
Thanks toxcct,
In which step do you think the state of the input parameter will be corrupted? Could you provide some pseudo code please?
toxcct wrote: 1) because : if the state of the parameter is corrupted, the state of the current object could have been corrupted too. but as long as we're assigning a temporary object first, the current object's assignment is exception-safe !
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
