• Advertisement
Sign in to follow this  

return a vector vs argument vector

This topic is 2767 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

in a lot of my functions i return D3DXVECTOR3 so that they can be combined into bigger functions. ie


float rad = GetDot(facingVect(model1),vecttmp));


but which is faster returning a vect from a funtion or in out int the function argumnets

Share this post


Link to post
Share on other sites
Advertisement
The code you just showed apparently returns a float (i.e. scalar), not a D3DXVECTOR3 (i.e. vector). This makes sense; a dot product computes a scalar.

When you do implement the cross product, please just return a value. You are going to need to create scratch space anyway in order to calculate the value properly (without overwriting a vector component before using it for another part of the calculation). So it makes more sense to just write directly into the scratch space and return it. Plus it's much simpler, more sensible and easier to use.

You are going to waste huge amounts of your own time by designing more complicated interfaces because you think they'll let you write a function that runs faster. Even if you're right, you'll often have to sacrifice any gains anyway in order to massage the calling code into shape so it can use the weird interface. Plus, all the time you spend jumping through your own hoops is time you could spend running a profiler, figuring out what's actually slowing down your program and fixing it.

Share this post


Link to post
Share on other sites
Depends on how "flexible" you want your function to be.

E.g., if you want to calculate and store the facingVec, as well as use it in the GetDot function, you can use references for arguments, rather than D3DXVECTOR3 objects. You're going to do a facing vector calc in any case, so little time is lost storing the result in a reference rather than a local which you return.

That form mimics existing D3DXVec3 functions and may prove to be more compatible. Example:

D3DXVECTOR3& facingVect(D3DXVECTOR3& faceVec, Model& model)
{
facevec = some_calculation( model ); // this is done whatever the return type is
return facevec;
}
// ... USEAGE:
D3DXVECTOR saveFaceVec;
// GetDot must take a vector reference as first argument
float rad = GetDot(facingVect(saveFaceVec, model), vecttmp);
// rad is calculated and saveFaceVec is available


With facingVect of that form, you can use

rad = D3DXVec3Dot(facingVect(saveFaceVec,model),vecttmp);

The only time "lost" is pushing the local saveFaceVec onto the stack before you call facingVect.

Share this post


Link to post
Share on other sites
I am pretty sure the compiler will optimise out those returns so it makes no difference in performance. IIRC "Return Value Optimisation" and "Named Return Value Optimisation" are the relevant optimisations done by most modern compilers.

Share this post


Link to post
Share on other sites
Even without RVO/NRVO, any reasonable cross product implementation will be inlined, and any reasonable Vec3 implementation will have a trivial constructor and destructor, which along with keyhole optimizations will lead to everything but the math being optimized away.

Share this post


Link to post
Share on other sites
Sneftel speaks truth. Please do not make things harder for yourself (and probably for the compiler as well).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement