How's memory usage with a variable like this?

I know globals are a bad thing

How much is this a “global”? I only need this variable in an other class that’s derived from the class this variable is declared in


UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Details)
    uint32 bDisabled : 1;

Not yet really familiar with the UE API but feel free to give me some pointers. I have +10 years C++ experience behind me. How much memory does this take compared to for example BlueprintReadOnly instead of BlueprintReadWrite or does it make any change, also with EditAnywhere ? Or is it just a matter of private: protected: and public: etc?

I did read wiki but there was no information about memory or performance usage on C++ variable “parameters”

I never noticed a difference between those, if there is any difference it is probably very small.

The EditAnywhere tag doesn’t make it a global variable. In fact, nothing that you do with UPROPERTY will change whether a variable is global or not, or public or private, etc.

UPROPERTY is, AFAIK, only for exposing variables to the Editor and Blueprints, and also some stuff related to networking(?). BlueprintReadWrite vs BlueprintReadOnly is the same as being able to edit the variable in Blueprints vs being able to only see the variable in Blueprints. In the same vein, EditAnywhere is the converse to VisibleAnywhere.

I believe the memory impact is either non-existent or totally negligible. I’m not wise in the ways of memory, but I do know it is standard and recommended practice to attach the UPROPERTY macro to all variables *except *those you explicitly don’t want being edited in Editor/Blueprint. I would assume that this holds true because there is no memory impact that would encourage otherwise.

Instead of using uint32, which is 4 bytes, why not just use bool which takes the space of just one byte?

Edit: can’t do simple math anymore, 4 bytes, not 8

Have a look into bitfields my friend :wink:

The hint lies within the “: 1”

Alright thanks for the replies, still getting familiar with the UE4’s API

And yeah I read that using uint32 for bools is better than using just bool

Hi Nuke,

This is big trade off, that ultimately might not make much difference in your performance.

The super low level view is that the compiler often assigns bools to a much larger memory space since it is “generally” faster on most processors architectures.

The thinking is then, since we know the extra memory is assigned anyway, its possible to just use a value type that allows us to use all that extra space, essentially for free in terms of actual memory usage.

If your trying to save every bit, say for network transfer, using bit masks are the way to go.
Using bit masks allows us to pack more True/False data into the same memory chunk.
Ref: c++ - How can I use a bitmask? - Stack Overflow

The big downside to this is the mental power needed to know what the bit masks are and how they are used.

in your example


uint32 bDisabled : 1;

your variable name is somewhat clear, I would assume the whole object is disabled if this value is false, but that could be completely wrong. Since the first b in bDisabled is Hungarian notation for bool, using bit flags would be even more unexpected.

As a rule of thumb: Avoid using magic numbers IE: int thisObjectsState = 41; // what is 41, do you know? will you remember after a month?



enum ActorStateFlags {
  DISABLED = 1 << 0, 2^0
  ONFIRE = 1 << 1, 2^1

  FLAGSupTooFor32uint32 = 1 <<31, 
}
uint32 ActorStates: DISABLED ;

uint32 ActorStates2: DISABLED | ONFIRE ;


But that is a whole lot of extra work when your code is probably good enough and fast enough, just using



bool isDisabled: true; // By limiting the choices for isDisabled to two values, the mental overhead is reduced.


There are a lot of ways to solve problems with code, if it works for you great. Coding speed can be better then code quality is some cases, actually completing a game vs giving up. But if your planning to invest significant time making a complex game, the investment in easy to understand code will pay itself back.

Thanks SilverB1rd that explanation helped a lot. The thing is now I’m using bDisabled for true or false and I have an other variable bIsOn which is also bool (uint32). I was thinking if I should use bDisabled or more likely bStatus or somesort to have 4 different states for that variable, disabled, not disabled, is on, is not on. Because my actor cannot have bIsOn of any state if bDisabled is true and bIsOn always “resets” when bDisabled changes to true or false

This would be a perfect example of why classes exist, and its right in your own code. Lets take a quick tour,

Classes are a way to group data, which can be thought of as state, and methods, which can be thought of as way to interact with the state.

Classes have both private and public data and methods.

in a lose view the public data and methods are what the big bad world see of your class. Its how you control what that world should be able to do with your object.



class MyClass
{
private:
  bool isDisabled: true;
  bool isOn: false;

public:
  bool IsEnabled();
  void Enable();
  void Disable();
  
  bool IsOn();
  void TurnOn();
  void TurnOff();
}


bool MyClass::IsEnable()
{
  return !isDisabled;
}

void MyClass::Enable()
{
  isOn = false;
  isDisabled = false;
}

void MyClass::Disable()
{
  isOn = false;
  isDisabled = true;
}


bool MyClass::IsOn()
{
  return isOn;
}

void MyClass::TurnOn()
{
  if(isDisabled)
  {
    return; // Maybe log error here?
  }
  isOn = true;
}

void MyClass::TurnOff()
{
  isOn = false;
}




By using the public methods to change the internal state, it keeps the outside would from being able to set your object to an invalid state.

This observation is hard to argue with, since only a few remarkable people exists who can tell they really understand how a compiler actually works; i’d like to add to it that usually the 8 bits structure is what can be considered an “atomic” level of building block, but it also gets a little blurry when you can open all sorts of memory views with variable sizes to a particular memory area. I’d like to believe that a uint8 bMyBoolean : 1 would be a better approach to define booleans, since it only will consume 1 byte of memory area to describe this given status the boolean is covering here.

Please update your answer to correct this information, since 32 bits are written as 4 bytes (4 * 8 bits = 32bits).

By using an uint32 you will actually have 3 unused byte of memory reserved for litterally nothing. How smart a compiler’s optimalization pipeline is up to the feature set it is built upon, it may or may not will translate this variable type to a smaller, eg 8 bit structure to store the boolean information.

Unfortunately unreal engine have no strict rules regarding this question, and if you take a closer look to this huge source code they provided, both uint8 and uint32 can be found to be used for representing boolean informations.

For instance an Actor, a very often used building block of the engine will define booleans as 8 bits (uint8) variables, possibly because on the long run you will conserve at least 3 bytes of ram if you reduce the lenght of their variable types to be 1 byte only. Values in Actor also gets accessed very frequently (multiple times in a frame) which also require fast evaluation speed to be allowed, and i like to believe that 8 bit is very fast to work with.

In case of World.h which also a core component of every game level, will use 32 bits long unit32 variable types, maybe because of the better compatibility with other variable types - but it’s hard to tell.

Either way, generally speaking the best practice i believe is to follow the programming paradigm of Unreal Engine and just implement your classes that match best to the parent classes provided to avoid most of the confusion that later will raise when you mixed up the variable types and naming conventions. It also can be better for the compilers to work with i suspect as much.

Cheers, had a brain fart there.