In this case is passing by reference faster?

Started by
17 comments, last by DigitalDelusion 18 years, 9 months ago
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?
[happy coding]
Advertisement
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.
HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats
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.
[happy coding]
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;
}
[happy coding]
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.
HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats
sorry a moment of confusion here that shouldn’t be

return Fixed16

but

return Fixed

Or are you talking about something else?
[happy coding]
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
HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats
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.
[happy coding]
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.
HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats
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;    } 
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!

This topic is closed to new replies.

Advertisement