'identifier undefined' in C++11 for-loop with USTRUCT - c++

I am implementing logging functionality in Unreal Engine 4.27 (in C++). A key part of my code is a function that is called once per game-tick. This function is responsible for iterating over an array of actors that I would like to log data for, checking whether a new log entry should be written at this point in time and calling the necessary functions to do that.
I am iterating over elements of a TArray of UStructs: LogObject->LoggingInfo = TArray<FActorLoggingInformation>. This array is defined as a UProperty of LogObject. In the loop I have to change the values of the elements so I want to work with the original items and "label" the current item as "ActorLoggingInfo". I have seen this done generally in cpp and also with TArrays. And yet my code does not work, there is no error message, but ActorLoggingInfo is undefined, thus the if-condition is never met.
This is the for-loop:
for (FActorLoggingInformation& ActorLoggingInfo : LogObject->LoggingInfo) {
if (ActorLoggingInfo.LogNextTick == true) {
ActorLoggingInfo.LogNextTick = false;
...
}
...
}
This is the definition of FActorLoggingInformation:
USTRUCT(BlueprintType)
struct FActorLoggingInformation
{
GENERATED_BODY()
public:
FActorLoggingInformation()
{
}
FActorLoggingInformation(int32 LogTimer, AActor* Actor, FString LogName)
{
this->LogTimer = LogTimer;
this->LogNextTick = false;
...
}
// Specifies Logging Frequency in ms
UPROPERTY(BlueprintReadOnly, VisibleAnywhere)
int32 LogTimer;
bool LogNextTick;
...
};
This is the debugger at run-time:
Additional Notes:
1. Something that consistently works for me is omitting the &, using:
for (FActorLoggingInformation ActorLoggingInfo : LogObject->LoggingInfo)
However, this is creating useless duplicates on a per-tick basis and complicates applying changes to the original objects from within in the for-loop, so it is not a viable option.
2. I have also tried auto& instead of FActorLoggingInformation& as used in the examples above, but I encountered the same issue, so I thought it would be best to be as explicit as possible.
I would be very thankful if you had any ideas how I can fix this :)
Thanks in advance!

Thanks to Avi Berger for helping me find my problem!
In fact, ActorLoggingInfo was actually never undefined and the code within the body of the if-clause was also executed (it just didn't do what it was intended to do).
When stepping through the code in the debugger it never showed the steps within the if-body and ActorLoggingInfo was shown as undefined so when no logs were written, I assumed it was something to do with that instead of my output function not working properly. So lesson learnt, do not blindly trust the debugger :)

Related

Initialization of wxColourDataBase while creating a new wxColourPickerCtrl

This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.

c++ best way to realise global switches/flags to control program behaviour without tying the classes to a common point

Let me elaborate on the title:
I want to implement a system that would allow me to enable/disable/modify the general behavior of my program. Here are some examples:
I could switch off and on logging
I could change if my graphing program should use floating or pixel coordinates
I could change if my calculations should be based upon some method or some other method
I could enable/disable certain aspects like maybe a extension api
I could enable/disable some basic integrated profiler (if I had one)
These are some made-up examples.
Now I want to know what the most common solution for this sort of thing is.
I could imagine this working with some sort of singelton class that gets instanced globally or in some other globally available object. Another thing that would be possible would be just constexpr or other variables floating around in a namespace, again globally.
However doing something like that, globally, feels like bad practise.
second part of the question
This might sound like I cant decide what I want, but I want a way to modify all these switches/flags or whatever they are actually called in a single location, without tying any of my classes to it. I don't know if this is possible however.
Why don't I want to do that? Well I like to make my classes somewhat reusable and I don't like tying classes together, unless its required by the DRY principle and or inheritance. I basically couldn't get rid of the flags without modifying the possible hundreds of classes that used them.
What I have tried in the past
Having it all as compiler defines. This worked reasonably well, however I didnt like that I couldnt make it so if the flag file was gone there were some sort of default settings that would make the classes themselves still operational and changeable (through these default values)
Having it as a class and instancing it globally (system class). Worked ok, however I didnt like instancing anything globally. Also same problem as above
Instancing the system class locally and passing it to the classes on construction. This was kinda cool, since I could make multiple instruction sets. However at the same time that kinda ruined the point since it would lead to things that needed to have one flag set the same to have them set differently and therefore failing to properly work together. Also passing it on every construction was a pain.
A static class. This one worked ok for the longest time, however there is still the problem when there are missing dependencies.
Summary
Basically I am looking for a way to have a single "place" where I can mess with some values (bools, floats etc.) and that will change the behaviour of all classes using them for whatever, where said values either overwrite default values or get replaced by default values if said "place" isnt defined.
If a Singleton class does not work for you , maybe using a DI container may fit in your third approach? It may help with the construction and make the code more testable.
There are some DI frameworks for c++, like https://github.com/google/fruit/wiki or https://github.com/boost-experimental/di which you can use.
If you decide to use switch/flags, pay attention for "cyclometric complexity".
If you do not change the skeleton of your algorithm but only his behaviour according to the objets in parameter, have a look at "template design pattern". This method allow you to define a generic algorithm and specify particular step for a particular situation.
Here's an approach I found useful; I don't know if it's what you're looking for, but maybe it will give you some ideas.
First, I created a BehaviorFlags.h file that declares the following function:
// Returns true iff the given feature/behavior flag was specified for us to use
bool IsBehaviorFlagEnabled(const char * flagName);
The idea being that any code in any of your classes could call this function to find out if a particular behavior should be enabled or not. For example, you might put this code at the top of your ExtensionsAPI.cpp file:
#include "BehaviorFlags.h"
static const enableExtensionAPI = IsBehaviorFlagEnabled("enable_extensions_api");
[...]
void DoTheExtensionsAPIStuff()
{
if (enableExtensionsAPI == false) return;
[... otherwise do the extensions API stuff ...]
}
Note that the IsBehaviorFlagEnabled() call is only executed once at program startup, for best run-time efficiency; but you also have the option of calling IsBehaviorFlagEnabled() on every call to DoTheExtensionsAPIStuff(), if run-time efficiency is less important that being able to change your program's behavior without having to restart your program.
As far as how the IsBehaviorFlagEnabled() function itself is implemented, it looks something like this (simplified version for demonstration purposes):
bool IsBehaviorFlagEnabled(const char * fileName)
{
// Note: a real implementation would find the user's home directory
// using the proper API and not just rely on ~ to expand to the home-dir path
std::string filePath = "~/MyProgram_Settings/";
filePath += fileName;
FILE * fpIn = fopen(filePath.c_str(), "r"); // i.e. does the file exist?
bool ret = (fpIn != NULL);
fclose(fpIn);
return ret;
}
The idea being that if you want to change your program's behavior, you can do so by creating a file (or folder) in the ~/MyProgram_Settings directory with the appropriate name. E.g. if you want to enable your Extensions API, you could just do a
touch ~/MyProgram_Settings/enable_extensions_api
... and then re-start your program, and now IsBehaviorFlagEnabled("enable_extensions_api") returns true and so your Extensions API is enabled.
The benefits I see of doing it this way (as opposed to parsing a .ini file at startup or something like that) are:
There's no need to modify any "central header file" or "registry file" every time you add a new behavior-flag.
You don't have to put a ParseINIFile() function at the top of main() in order for your flags-functionality to work correctly.
You don't have to use a text editor or memorize a .ini syntax to change the program's behavior
In a pinch (e.g. no shell access) you can create/remove settings simply using the "New Folder" and "Delete" functionality of the desktop's window manager.
The settings are persistent across runs of the program (i.e. no need to specify the same command line arguments every time)
The settings are persistent across reboots of the computer
The flags can be easily modified by a script (via e.g. touch ~/MyProgram_Settings/blah or rm -f ~/MyProgram_Settings/blah) -- much easier than getting a shell script to correctly modify a .ini file
If you have code in multiple different .cpp files that needs to be controlled by the same flag-file, you can just call IsBehaviorFlagEnabled("that_file") from each of them; no need to have every call site refer to the same global boolean variable if you don't want them to.
Extra credit: If you're using a bug-tracker and therefore have bug/feature ticket numbers assigned to various issues, you can creep the elegance a little bit further by also adding a class like this one:
/** This class encapsulates a feature that can be selectively disabled/enabled by putting an
* "enable_behavior_xxxx" or "disable_behavior_xxxx" file into the ~/MyProgram_Settings folder.
*/
class ConditionalBehavior
{
public:
/** Constructor.
* #param bugNumber Bug-Tracker ID number associated with this bug/feature.
* #param defaultState If true, this beheavior will be enabled by default (i.e. if no corresponding
* file exists in ~/MyProgram_Settings). If false, it will be disabled by default.
* #param switchAtVersion If specified, this feature's default-enabled state will be inverted if
* GetMyProgramVersion() returns any version number greater than this.
*/
ConditionalBehavior(int bugNumber, bool defaultState, int switchAtVersion = -1)
{
if ((switchAtVersion >= 0)&&(GetMyProgramVersion() >= switchAtVersion)) _enabled = !_enabled;
std::string fn = defaultState ? "disable" : "enable";
fn += "_behavior_";
fn += to_string(bugNumber);
if ((IsBehaviorFlagEnabled(fn))
||(IsBehaviorFlagEnabled("enable_everything")))
{
_enabled = !_enabled;
printf("Note: %s Behavior #%i\n", _enabled?"Enabling":"Disabling", bugNumber);
}
}
/** Returns true iff this feature should be enabled. */
bool IsEnabled() const {return _enabled;}
private:
bool _enabled;
};
Then, in your ExtensionsAPI.cpp file, you might have something like this:
// Extensions API feature is tracker #4321; disabled by default for now
// but you can try it out via "touch ~/MyProgram_Settings/enable_feature_4321"
static const ConditionalBehavior _feature4321(4321, false);
// Also tracker #4222 is now enabled-by-default, but you can disable
// it manually via "touch ~/MyProgram_Settings/disable_feature_4222"
static const ConditionalBehavior _feature4222(4222, true);
[...]
void DoTheExtensionsAPIStuff()
{
if (_feature4321.IsEnabled() == false) return;
[... otherwise do the extensions API stuff ...]
}
... or if you know that you are planning to make your Extensions API enabled-by-default starting with version 4500 of your program, you can set it so that Extensions API will be enabled-by-default only if GetMyProgramVersion() returns 4500 or greater:
static ConditionalBehavior _feature4321(4321, false, 4500);
[...]
... also, if you wanted to get more elaborate, the API could be extended so that IsBehaviorFlagEnabled() can optionally return a string to the caller containing the contents of the file it found (if any), so that you could do shell commands like:
echo "opengl" > ~/MyProgram_Settings/graphics_renderer
... to tell your program to use OpenGL for its 3D graphics, or etc:
// In Renderer.cpp
std::string rendererType;
if (IsDebugFlagEnabled("graphics_renderer", &rendererType))
{
printf("The user wants me to use [%s] for rendering 3D graphics!\n", rendererType.c_str());
}
else printf("The user didn't specify what renderer to use.\n");

WTL CListViewCtrl getSelectedItem is causing an Assertion fail for me

This is my code in order to get the name of the item which has been selected in my CListViewCtrl:
LVITEM item = { LVIF_PARAM };
CString itemText;
clistViewCtrl.GetSelectedItem(&item);
clistViewCtrl.GetItemText(item.iItem, item.iSubItem, itemText);
Note that this code is working. I recently did another project, where I grabbed the name in exactly this way, however, I had no problems there with any assertion fails.
When I execute this with my current project, I always get a debug assertion:
"File: ... atlctrls.h"
Line: 3242
Expression: (GetStyle() & 0x0004) != 0
Even though the expression already states it pretty much, here is the line causing the failure:
ATLASSERT((GetStyle() & LVS_SINGLESEL) != 0);
I have barely any idea what the problem is. As I said, the exact same code worked on my other project, and I just went through both, trying to find any differences which could cause this behaviour, but nothing caught my eye.
Honestly, I don't even know if this is related to my code at all, considering the two compared elements seem to be predefined.
My first guess would have been that this part is being called before the items are created, but all items in the listview are created at the point I try to call this code passage.
Can anyone point me to a solution?
Your control is not created with style flag LVS_SINGLESEL. So calling GetSelectedItem is causing an assert. In case of multi selection use GetFirstSelectedItem and GetNextSelectedItem instead of GetSelectedItem. For single selection you can continue useing GetSelectedItem, but you have to add LVS_SINGLESEL style flag to your control.

Suggested flow-control structure for order-dependant operations

I've run into the following issue which is not difficult to solve by any stretch of the imagination but I would like to know what the best / most elegant solution is.
I have the following method that the prototype of looks like this:
bool Team::isEveryoneDead(int teamOnTurn);
There are two teams available and depending on what instance of the team is currently on turn, I would like to check whether every Character in the team is dead in this very particular order:
Loop trough all the Characters in the team that's not on turn first. Should there be any character that's alive, stop looping (and goto step 2.). Should there be noone alive, terminate the function and return.
Now that I know that the team that's not on turn contains at least one character that's alive, loop trough the team that's currently on turn and check for the same thing. Should I find someone alive, stop looping and terminate / return.
The argument int teamOnTurn allows me to resolve the instance of Team that's currently on turn. The order in which i evaluate the "alive condition" is of great importance here.
Now, there are several approaches that can be taken, say hardcoding the order (since there are only 2 possible orders) and resolving the order by checking who's on turn and then executing the branch that already has the specific order like this:
bool Team::isEveryoneDead(int teamOnTurn) {
if (Team::Blue == teamOnTurn) {
checkThis();
checkThat();
} else {
checkThat();
checkThis();
}
}
This solution however wouldn't quite work for say 5! permutations for specific call-ordering for more items. What technique should one deploy to solve this with the utmost elegance :) ?
Thanks in advance, Scarlet.
Try creating another internal method that actually does the checking, and let the isEveryoneDead() method orchestrate the order in which the teams are checked, maybe something like this:
bool Team::isEveryoneDead(int teamOnTurn) {
bool isFound = isEveryoneDeadInternal( /* params for team not on turn */ );
if(isFound) {
isFound = isEveryoneDeadInternal( /* params for team on turn */ );
}
return isFound;
}
// This method know nothing about on turn or off turn
bool Team:isEveryoneDeadInternal() {
// Loop through all characters in the team, checking if any are alive
// When the first live character is found, return true
// else return false
}
This is a concept called DRY : Dont Repeat Yourself

Error while calling member function

Hi I have just started using C++ today, and I am working on checkboxes. I have tried using CheckBox1->Checked in an if statement or whatever, but it isn't working.
The error is:
Error 2 error C2227: left of '->Checked' must point to class/struct/union/generic type
EDIT: The Code is:
void function ()
{
if (1001->Checked)
{
Sleep(2000);
}
}
Without seeing some of your code, it's very difficult to offer targeted assistance.
However, that error message usually comes about because the item you're de-referencing is not a pointer.
Check to ensure it's of the correct type. It should be something along the lines of:
tCheckBox *CheckBox1;
One possibility is that you've declared it not as a pointer to the checkbox but as a checkbox itself:
tCheckBox CheckBox1;
Note the lack of the asterisk there that would otherwise mark it as a pointer. In that case, you would use CheckBox1.Checked rather than CheckBox1->Checked, if it's allowed by the framework (this isn't standard C++ since that beast has no concept of GUI libraries).
If that doesn't help, please post the code so we can offer better suggestions.
Update:
if (1001->Checked) ?????
1001 is not a pointer - it's not a variable of any description, it's an integer constant.
You need to declare and use a variable of some description. First step is, I think, to read up on the documentation for your framework and/or get some sample code that does compile and work, basing your initial work of that.
Use CButton::GetCheck() to determine the state of the checkbox - like so...
CButton* pButton = (CButton*) GetDlgItem(IDC_CHECKBOX_RESOURCE_ID);
if ( BST_CHECKED == pButton->GetCheck() )
{
// button is checked
}