Frederick said:
Noah Roberts posted:
I don't know where you're getting that from.
Think about it. Your code was something like this:
Obj & Obj:
perator = (Obj const & other)
{
assert (this != &other);
do copy stuff...
return *this;
}
Now, an assert will only catch the cases you test during debugging. It
will not catch anything that happens under release. Therefor, when you
are in release the check doesn't happen and the assigment op goes
straight into "do copy stuff". If this is a self assignment "do copy
stuff" probably explodes or reacts in some peculiar way. In order to
keep this from affecting the user (through a crash or worse, bad
results) the check has to be there anyway:
Obj & Obj:
perator = (Obj const & other)
{
assert (this != &other);
if (this == &other) return *this;
do copy stuff...
return *this;
}
So your argument that using an assert is more efficient doesn't hold
water when you take care in the release build and acknowledge the FACT
that some bugs will get through no matter what precautions you take.
I still don't see why you think it's invalid.
It's pointless. It also causes numerous problems by breaking the
standard operation of operator =.
I don't need to do testing -- I know that there's a thing called "time",
the basic unit of which is the second. I also know that there's a thing
called "memory", the basic unit of which is the bit.
Statements of performance should always be backed up by real numbers.
What you are advocating is known as premature optimization. Not only
that but it is a *micro* optimization and under almost all situations
is utterly without merrit and won't have any affect on the speed of
execution or memory footprint.
The "Third Party" is the person who wrote the reusable code.
Your method of clipping makes it difficult to follow the conversation.
Is that on purpose?
The person who wrote the reusable code is the person under discussion
so it isn't a *third* person, they are the *first* person. Code like
that shouldn't be written.
This figure varies from system to system, compiler to compiler, and is
influenced by numerous other things...
As I've argued, there is no difference given considerations of real
world problems and the optimization you are trying to make will likely
never be worth the problems. When it is, operator = should be disabled
by making it private and the copy code should be in a function so as to
advertize that this isn't a normal copy operator.
Let's say that we're writing fast code. Let's say that, for some reason, it
takes a long time to compare one hand to another, so we want to speed up
the process as much as we can. Someone comes up with the idea of writing:
if(this==&rhs)return*this;
This will speed up considerably any self-comparison, but will slow down any
proper comparison between different objects. Let's go on to say that, if a
Hand is compared to itself (or perhaps assigned to itself) then that
comparison algorithm will invoke undefined behaviour. An "assert" would
work nicely to catch programming errors.
Are we talking about comparison or assignment??? You keep using one
where it appears you may need the other.
if (this == &other) comparison == equal!
if (this == &other) copy == noop.
Now, you are asserting that doing those tests will somehow impact the
performance of a given, highly theoretical program. Ok, let's assume
that you are right. For some program somewhere, a very unique program,
you need to optimize comparison and assignment so much that you cannot
allow the normal safety checks to make it into release code. First,
you damn well better have some real numbers to reach that conclusion.
Second, such a micro optimization (three or four machine code
operations at most) is the LAST thing to look at doing. Finally, you
would certainly want to advertize the problem more clearly by disabling
these operators and creating new ones so that nobody is confused about
the fact that these are not the operators they are expecting.
And there is no possibily for UB here.
The behaviour is undefined if you compare two pointers which don't point
into the same array. The following invokes UB:
int array1[5], array2[5], *p1 = array1+3, *p2 = array2+2;
p2 > p1; /* UB! */
I don't really even know what you are talking about here as your
clipping has completely removed context but I can see right off that
there is no undefined behavior in the above code. I can't imagine why
you think there is.