Hi,

I'm currently 'implementing' correct usage of const function parameters and class member functions.

During this I'm running into the following:

- class 'MyClass' has several (unsigned) int variables, which are used throughout the member functions for for loops, counter etc.

- when I try to make one of these member functions 'const', which is logical looking at the functions itself, but this doesn't work, since the used counter variables are members of the class

The solution seems very simple, create local (unsigned) int variables for my loops within the member functions.

My question:

- would it be a bad idea, memory/ performance wise, to do this?

For example, my rendermesh and rendersubmesh functions have one or more for loops, using a class member for the for loop.

This would mean I 'make' a new integer in the local functions, for each submesh/ mesh I render in every frame.

Any input is really appreciated.

Example:

void CD3dmesh::RenderMesh(LPDIRECT3DDEVICE9 pD3ddev, D3DPRIMITIVETYPE pMethod) const
{
	for(sub=0;sub<mSubMeshSize;++sub)
	{
		pD3ddev->DrawIndexedPrimitive(pMethod, 
		 	  	  					  0,
								      mSubMeshTable[sub].VertexStart, 
								      mSubMeshTable[sub].VertexCount, 
								      mSubMeshTable[sub].FaceStart*3,
								      mSubMeshTable[sub].FaceCount); 
	}
}

Where 'sub' now is a class member. I could simply create a int sub (or something) locally in the function.

Maybe a stupid question, but will the memory of the int will be freed everytime the function finishes?

(would it be a good idea performance wise etc.).

Putting loop counters and other temporary variables into a class or struct is likely going to be more expensive than leaving it a local. As a local, the compiler will almost certainly not allocate any memory at all, but instead just reserve a register for the loop counter.

I'm not aware of modern compilers being smart enough to optimise away entire members in cases like this. If they can, then you're back to the above situation, more or less. If not, the extra memory consumed is not free, you'll pay that price every time such an object is loaded or saved between memory and the processor caches. The compiler will probably implement loops like the locals, but with an additional write to memory of the final loop counter value.

Finally, there is the last cost: bugs. A counter like that will be considered to be initialised outside the constructor, so you won't get compiler errors for code like the following:

void SomeObject::someMemberFunction()
{
    // Whoops, forgot to reset counter!
    while(counter < N) 
    {
        // Do some work
    }
}

Now, where things get less clear is when the "temporary" variable is not a native or simple type, but something complex like std::string or std::vector. In some cases, creating new instances of such types might become prohibitive if you need such functionality in core loops. Re-using existing values might be a valid optimisation here, assuming there are no higher level algorithmic or data structure based optimisations available to avoid such work.

Thanks all, my conclusions:

- making these variables mutable should work, but is tricky (as it is today akready), risk on faulty initializiation etc.
- since they're just simple ints and unsigned ints, no complex / higher level algorithms etc, I will create them all locally within the member functions and cleanup the ones in the class(es)

This also fits perfectly within the given principles.

Don't even look at it as if you have an option or choice there. Misusing a member variable for this purpose has many dire consequences:

1. It inhibits some optimisation because at the very least, the final value must needlessly be written back into the member variable, and worst case may even cause the compiler to not use a register where it otherwise could.
2. Stack allocation is cheap, very cheap. So cheap that adding an extra variable your stack frame normally has absolutely zero impact on performance.
3. As a member it increases the amount of memory your class occupies. With many instances, and/or on smaller objects, this could bump up RAM usage very significantly.
4. It simply will not work when you try to have nested functions using the same member variable as the for-loop variable.
5. Making it mutable requires that you also wear the added runtime cost of making it threadsafe.
6. Trying to use any functions which use the same member variable as a loop counter from multiple threads simply will not work.

Long story short, do not ever misuse use a member variable for the purpose of what should be a local loop variable.