Re: Violating abstractions
Quote:
Because it's assigning to itself. The first thing it does is to destroy itself, then it tries to recreate itself based on... the object that was just destroyed.
Which is really BAD, and definately Undefined Behavior.....but....
In many cases will appear to work :eek: :thumbd:
Re: Violating abstractions
no it will never work..
because it wont be itselve anymore becus its destroyed so u assigned a value to the class but isntead of resulting in that value it results in being a destroyed object
Re: Violating abstractions
If the constructor does not initialize any variables, and there are no other threads and the system does not pre-initialize memory, then the memory from the old instance will not have been written to.
Again BAD, and UNDEFINED
Re: Violating abstractions
Quote:
Originally Posted by exterminator
But the easiest one that you missed was - check for self assignment.. :)
Yes, I did miss that, but after seeing the object commit suicide ... self assignment was fairly irrelevant anyway.
:D
Re: Violating abstractions
Quote:
Originally Posted by Zaccheus
Yes, I did miss that, but after seeing the object commit suicide ... self assignment was fairly irrelevant anyway.
Objects do commit suicide sometimes and that can make sense.. but of course not in this case. I don't think it is irrelevant because usually ignoring self assignment is no trouble at all. All that it costs you is a few extra statements/instructions that can be done without. It saves you the time wasted upon various assignments that can be skipped using a simple check for the objects. That can be done here too but for that I would need to change the magnum opus.
Re: Violating abstractions
Quote:
I don't think it is irrelevant because usually ignoring self assignment is no trouble at all. All that it costs you is a few extra statements/instructions that can be done without.
[code]
class SubEntity
{
SubEntity(SubEntity const &src)
{
Sleep(1000); // Expensive operations
}
};
class Entity
{
SubEntity m_Member;
Entity & operator = (Entity const &rhs)
{
// NOT Checking for Self has a magor performance impact!
}
}
[code]
Plus even if you assignment operator is "safe" for self assigns (without the check today), there is no guarentee that something will not change in the class six months down the road, and break your code.
ALWAYS check for self assigment and "short-circuit".
}
Re: Violating abstractions
Quote:
Originally Posted by exterminator
Objects do commit suicide sometimes and that can make sense.. but of course not in this case.
Indeed.
Quote:
Originally Posted by exterminator
I don't think it is irrelevant because usually ignoring self assignment is no trouble at all. All that it costs you is a few extra statements/instructions that can be done without. It saves you the time wasted upon various assignments that can be skipped using a simple check for the objects. That can be done here too but for that I would need to change the magnum opus.
All I meant was that having seen how dangerous the code is, I did not look at it any further.
;)
I WAS NOT SAYING YOU DON'T HAVE TO CHECK FOR SELF ASSIGNMENT. ALWAYS CHECK FOR SELF ASSIGNMENT.
:wave: