I cannot get a template function I have made to run in the debugger.
I have built in DebugGameEditor mode.
What is the actual error you get when you try to compile?
Your function is getting inlined and therefore has no code to step through.
A better question would be, why are you using a template function for this?
Also, why are you using a STL array of Unreal objects? You should be using a TArray<ABasePlayer*>.
@anonymous_user_dd7d789e
Organisation and DRY.
I’m using std::vector because the documentation is vast and I cannot know everything the Unreal engine has to offer straight away. Thanks for the tip, I will consider using the TArray if it supplies me with what I need.
Do you know how to get it to be debuggable?
@milliams
It’s not a compile error. It compiles and runs, but I cannot debug the line.
The code that is actually there (rather than the int a, int b stuff) seems to work, but I was wondering why I cannot debug it?
My original code was to do something like this… but the lack of debugging was making it hard:
Just to say, I have tried in a console application and the compiler does allow debugging inside templates… How can i give the compiler more information so it can debug succesfully?
FWIW, I didn’t mention TArray over std::vector just because I’m one of those die hard, old school programmers that refuse to use the STL in games. An important part of Unreal memory management is that UObjects will only be managed if they are stored in a member variable flagged as UPROPERTY(). You can’t use UPROPERTY with STL containers, but you can use it with TArray.
Because templates are figured out at compile time, there tends to be no code actually generated in the header file that the debugger can step through. You might have some luck moving the implementation to your CPP file, but that consistently caused compilation trouble for me in the past.
Seeing that code sample, I don’t believe you need templates. I do appreciate the power of templates but UE4 doesn’t play well with them. (Can’t have a template UObject, for instance.) I’m not sure what you do with the template argument inside ABasePlayer::Instantiate, but for UObjects, UE4 favours using its reflection system over templates. If you need to do something with the type, you can pass along your class type using UClasses:
// Get class statically
UClass* GameModeClass = AGeneralGameMode::StaticClass();
// Get class dynamically from inside a AGeneralGameMode
UClass* GameModeClass = this->GetClass();
You can statically restrict classes to certain subtypes using TSubclassOf:
// Get class dynamically from inside a AGeneralGameMode
TSubclassOf<ABaseGameMode> GameModeClass = this->GetClass();
1 Like
Thank you! Your answer is very helpful!
I’ve also noticed that debugging Unreal code is a bit wonky.
Here’s what I’ve seen so far:
-Unused variables are skipped. It’s almost as if they’ve been optimized away.
-The program counter seems to skip loading a variable into memory until it’s actually used elsewhere in the code.
This behavior seems familiar. It reminds me of debugging HLSL code, which is actually compiled and optimized for performance rather than debugging.
So, the same thing may be happening in UE4, right?
Well, there’s this handy little drop down menu right next to the debug menu which lets you toggle the build configuration. If you have the build configuration set to “development editor”, it will optimize your code for performance rather than debugging. If you switch your build configuration for DebugGame editor (or something like that), the code runs everything, whether its used or not, and it runs in sequential order. That’s my working theory anyways, don’t know if its true.
1 Like
That’s entirely normal and not unique to UE4.
Some IDEs are a bit more generous about stepping through optimized code, but the fact of the matter remains that in many cases, the optimized code simply has no equivalent to an unoptimized source line and therefore can’t stepped through.
As for values, a huge part of optimization is only using variables in CPU registers because memory accesses are more expensive. While a local variable in source code “lasts” for the duration of its scope, very often the underlying optimized code will stop storing it as soon as it no longer has any use in order to free up precious registers.
For these reasons, debugging through assembly code is a very useful skill to have when dealing with game development. Writing assembly is scary stuff nowadays, but reading it isn’t that bad with a decent IDE. Most IDEs have an option to show assembly code alongside source code, letting you roughly follow what the computer is actually doing for some lines of code. In some cases, it’s pretty surprising to see how much the optimized assembly instructions differ from the actual code. For Visual Studio, that assembly view can be found under Debug > Windows while the debugger is running, with the handy shortcut ALT+8.
1 Like
cmartel, I’ve taken that assembly part on board.
What i’ve decided to do is remove the template to test and get it working, and then slot the template in after when i know all is well… It’s a bit of an ordeal but it’s allowing me to go forward. Thanks for your input.
1 Like