In this case is passing by reference faster?
Hi,
Ive got a fixed point wrapper class that ive been using for a while now.
The class is simply
Class Fixed
{
int value;
//all overloaded methods etc.
}
Now my question is, is it quicker to pass this class by reference or by value?
If its by reference then the pointer must be dereferenced , but if its by value then a temp object must be constructed.
As the data is only 32 bits wide im having trouble working out what is actually faster, any ideas?
basicly anything that has trival copyctor/assignment ops and has the same size as any built in type usually for highest efficency should be passed by value.
Ok thanks!
I was kinda leaning towards that as it didn’t seem to make sense to pass over the pointer value then have to dereference it when the data needed could be there already if passed by value.
I was kinda leaning towards that as it didn’t seem to make sense to pass over the pointer value then have to dereference it when the data needed could be there already if passed by value.
What about in the case of the = operator?
Is this
inline Fixed Fixed::operator=(const Fixed x)
{
return Fixed16(x);
}
Or this faster?
inline Fixed& Fixed::operator=(const Fixed x)
{
m_v = x.m_v;
return *this;
}
Is this
inline Fixed Fixed::operator=(const Fixed x)
{
return Fixed16(x);
}
Or this faster?
inline Fixed& Fixed::operator=(const Fixed x)
{
m_v = x.m_v;
return *this;
}
The first one will confuse people since it won't assign to the assigned object
but both will probably be optimized away to a singe mov in relase bulid.
but both will probably be optimized away to a singe mov in relase bulid.
sorry a moment of confusion here that shouldn’t be
return Fixed16
but
return Fixed
Or are you talking about something else?
return Fixed16
but
return Fixed
Or are you talking about something else?
Quote:
inline Fixed Fixed::operator=(const Fixed x)
{
return Fixed16(x);
}
that will never change the object you're assigning to so if you did:
a = b;//a will still hav its old value!
that's what Im saying is a tad confusing
Ahh really…
I think I have a misconception on how that works then.
Why does the operator need to return a value at all then? I thought it was the returned value that was assigned.
I think I have a misconception on how that works then.
Why does the operator need to return a value at all then? I thought it was the returned value that was assigned.
Quote:Original post by Structure
Ahh really…
I think I have a misconception on how that works then.
Why does the operator need to return a value at all then? I thought it was the returned value that was assigned.
It doesn't, any assignment work should be done *inside* op=, the reason for returning *this is so that you easily can chain calls i.e. to enable:
a = b = c; to work as expected.
Quote:Original post by Structure
Or are you talking about something else?
He's saying that the first example is "broken" since it doesn't actually do an assignment. Also, neither checks for self assignment, though I guess it wouldn't matter in this case and the compiler would optimize it away anyway.
As far as speed in this case, both functions (once the first once is fixed) will probably be optimized into exactly the same result.
One more thing. Here is the canonical form of operator=():
Fixed & Fixed::operator=( Fixed const & x ) { if ( this != &x ) { ... } return *this; }
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement