Hi,

Lately I've been struggling a bit/ playing around with when to pass a const ref and when to pass by value, concercing XMFLOAT3/4's and XMFLOAT4X4 types. The advice I've got was to prevent doing it all by const ref, because the mentioned objects are quite 'small'. So I've thought of the following 'hand rule':

- when I retrieve a vector/ matrix I always return the class member by value

- when I have to pass a vector/ matrix to another object, I always do it as const ref

- always applying both rules should make it safe and prevent passing 'empty references'/ local adresses

Here's an example:

// INTERFACE

class objectTypeA
{
public:
	DirectX::XMFLOAT4 GetPosition() const;

private:
	DirectX::XMFLOAT4 mPositon;
};

// IMPLEMENTATION

XMFLOAT4 objectTypeA::GetPosition() const
{
	return mPosition;
}


// INTERFACE 2

class objectTypeB
{
public:
	void AdaptPosition(const DirectX::XMFLOAT4 &pPos);

private:
	DirectX::XMFLOAT4 mPosition;
};

// IMPLEMENTATION

void objectTypeB::AdaptPosition(const XMFLOAT4 &pPos)
{
	mPosition = pPos;
}


// CALLING THE FUNCTIONS

objectB.AdaptPosition(objectA.GetPosition());

?

?

?

?

When I have a mix of both, I get into situations where I always first have to create a local (scope) const variable, before I can pass it safe to another function that expects a const ref. Which I find makes my code not quite readable, here's an example:

// INTERFACE

class objectTypeA
{
public:
	DirectX::XMFLOAT4& GetPosition() const;

private:
	DirectX::XMFLOAT4 mPositon;
};

// IMPLEMENTATION

XMFLOAT4& objectTypeA::GetPosition() const
{
	return mPosition;
}


// INTERFACE 2

class objectTypeB
{
public:
	void AdaptPosition(const DirectX::XMFLOAT4 &pPos);

private:
	DirectX::XMFLOAT4 mPosition;
};

// IMPLEMENTATION

void objectTypeB::AdaptPosition(const XMFLOAT4 &pPos)
{
	mPosition = pPos;
}


// CALLING THE FUNCTIONS

const XMFLOAT4 localVec = objectA.GetPosition();
objectB.AdaptPosition(localVec);

I would appreciate your opinions and advice if this would be a good rule of thumb (or how you handle/ approach this).

It's basically the same for other relative small objects, like a XMFLOAT4X4 or a AABB/ OBB.

To be perfectly honest, I would design your return types around the access patterns that you want to provide to your users, rather than trying to determine if returning by reference is the more performance oriented technique. I would find it hard to believe that returning by const reference vs making a duplicate of the object and returning it on the stack is either better or worse in all situations...

Have you tried to profile either of these cases to see if there is an appreciable difference? Even if it is just a test case (i.e. not the actual use case in your engine) I think that will show that there isn't much difference between the two.

Have you tried out using a static code analyzer? There is one available in Visual Studio, which can most likely catch it if you try to return a reference to a temporary object. Other than using something like this to check your code, then you pretty much just have to make sure you don't return a reference unless the data is a member or (gasp) a global variable.

The arguments should be passed by constant reference if you don't plan to modify them. Like you said, the return value should be a value and not a reference, unless you intend for the returned data to be modified outside of the class.

Thanks. I believe I'm doing it now exactly as you're saying (gladly :))

- I do const return by valye only for members of my classes.

For example: XMFLOAT3 Cd3dcamera::GetPos() const { return mPos; }, where mPos is a class member

- I absolutely don't want to modify the class members from outside the class (especially because most of them are private), so that's a confirmation I should return by const ref, like: XMFLOAT& CD3dcamera::GetPos() const.

I'll look into the feature in Visual Studio, the last time I had an issue with this, I actually got a compiler error telling me that I was returning a local address.