C++ Code Optimisation errors

Uisng UE5
I have simple loop back counter for counting way points on patrol

This code does not work unless i turn off optimisation with pragma as shown below

Whose responsible for optimisation settings for UE5 project is it epic or MS

I wasted a lot of time debugging before i figured it was code optimiser messing with my code.
Is it time for epic to review the settings they use to create VS projects, cause online search reveals there is lot of people getting errors in coder as result of VS code optimiser

Even without using the pragma to turn off optimisation, switching to Debug Build of UE5 project had better result. But still had issues.

Changing all ints in the code to floats too meant something closer to expectation was executed but still with errors

Maybe its time to tame the code optimsation, cause it seems to be causing more problems than its solving.

For example in current situation , i no longer trust the development build of ue5 , instead think am gona use debug build for development , simple due to avoiding hard to spot optimisation bugs.

Unless am missing something , maybe its time for someone to take hard look at use of code optimisation in unreal c++ project setups

#pragma optimize( "", off )
int UC_LoopbackCounter::mfo_GetCurrentCount()
{
	int retCount;
	if (mvo_iCurrentCount < mvo_iMaxCount)
	{
		retCount = mvo_iCurrentCount;		
	}
	else
	{
		retCount = mvo_iCurrentCount =  0;		
	}

	mvo_iCurrentCount++;
	return retCount;
}
#pragma optimize( "", on )

If a compiler generates wrong code from correct yet obfuscated source - it is a problem of a compiler. Try to complain to VS forum :grinning:

And BTW, why not

int UC_LoopbackCounter::mfo_GetCurrentCount()
{
	if (mvo_iCurrentCount >= mvo_iMaxCount)
	{
		mvo_iCurrentCount = 0;		
	}
	return mvo_iCurrentCount++;		
}
3 Likes
int32 UC_LoopbackCounter::mfo_GetCurrentCount()
{
    return mvo_iCurrentCount >= mvo_iMaxCount ? 0 : mvo_iCurrentCount + 1;		
}

even smaller and does same job.

Also why is a function called GetCurrentCount returning an incremented number? Very weird naming.

Should it not be called GetNextNumber? or something similar?

2 Likes

Yeah very obfuscated. Named GET but actually works as GetCurrentCountAndIncrement.

int32 UC_LoopbackCounter::mfo_GetCurrentCount()
{
    return mvo_iCurrentCount >= mvo_iMaxCount ? mvo_iCurrentCount = 0 : mvo_iCurrentCount++;		
}

thanks for the contribution to you all

int UC_LoopbackCounter::mfo_GetCurrentCount()
{
	if (mvo_iCurrentCount >= mvo_iMaxCount)
	{
		mvo_iCurrentCount = 0;		
	}
	return mvo_iCurrentCount++;		
}

must admit i like this code best cause its easier to follow and debug should optimiser have other ideas. Partly why my original code is so spread out to debug the issue i was having.

But its official and totally new to me, that VS code optimiser is well known for breaking code.

Hi!

I’m very familiar with the behavior you mention. Visual studio will absolutely lie to you about things when breaking through code if running in development mode. Lots of things tend to get optimized away and it isn’t generally clear what changes have been made. However - and I have a lot of time around this behavior - it won’t actually change the end result of what your code does or how it behaves. At least, I’ve never seen it change the actual functionality in my years programming in unreal and VS. But you cant trust your break points or watches or your breaking through code. So I personally never run in development mode. I always run DebugGame Editor. That way I know that my code is not being optimized away. However, even in DebugGame Editor, the engine code will be optimized away. Running in Debug Editor is too slow for me so if I have to debug engine code, I always add the pragma deoptimize around the engine code so VS doesn’t lie to me.

Related reading about the different build configurations: Build Configurations Reference | Unreal Engine Documentation

thanks very much for the insight on that, this is why i was shocked cause in my case it actually broke the code, that’s why i use the pragma directive around the function to stop optimisation and the difference is night and day, cause the code worked as expected when pragma is in to stop optimisation.

Thanks for the idea of using debugGame build.

Thats why i suggest maybe unreal look at how they auto generate VS projects maybe to lower the setting on optimisation. Cause as am aware there are levels to optimisation.

I have never had issues with the optimization level, never had code “not do what its supposed to do”, and if it was a big issue, it would be addressed by now as the engine would break.

Thats a fair point, but i cant speak for engine code.

But i emphasize what i was not expecting, and was totally new to me on this occasion is the fact that i had to put pragma to turn off optimisation around my function to get it work as expected.
That is new to me

And then did some google search on Visual studio optimiser o find other have issues with it also, that too was surprise to me, cause i thought optimiser would never touch code it cant optimise correctly .

So the aim of this post is to let others know , and share ideas on best way to avoid pitfalls in this area.