How heavy is uenum?

Development Programming & Scripting
1

Hi guys,

I am writing a core functionality to an item system in the game, which includes a lot of enums that will not be exposed to Blueprints (all the stuff will be happening in the code). I am thinking to use UENUMs, as I got used to their notation, and TEnumAsByte for storing them in my classes (most of those classes are not even UObject-inheriting). Does it make sense to use UENUMs vs native cpp enums/class enums? Are UENUMs in general and TEnumAsByte heavier then native enums, which are basically just ints?

2

They’re not ints in C++11 :slight_smile:

UENUM is just a macro for UE reflection system, it does not magically make enums heavy on performance.

TEnumAsByte is just a wrapper, that allows to display enum inside editor, if you’re not going to expose enums to the editor, you don’t want to use UENUM and TEnumAsByte.

However, access to reflect data might induce some performance hit, since it’s another layer on top of the code, in other words, it would be faster without reflection, AFAIK.

Hope this helps somehow.

3

Ok, thanks.

4

Biggest Smiles answer is great!

To add my own contribution to this discussion: your question answers itself right here:

"I am writing a core functionality to an item system in the game,"

Core functionality = very very important

= you need to think long term

= you need to maximize the flexibility of your system 2 years down the line

= you should leverage UE4’s awesome available systems

= expect to need future compatibility for display / editing / saving in blueprints

= you should leverage all the hard work UE4 engineers have done with UEnum because they obviously felt it is very useful in real game projects

= unless there’s some extreme cost to UEnum, which there isn’t, there is no point in dropping all of the above advantages for the sake of… well I am not sure really, since we are really talking about a uint8 = a byte, = a very very small amount of data even in network code :slight_smile:

But think big!

Core game code functionality should be as flexible as possible for all future possible needs!

You are not losing anything by using UEnum, and you are gaining the ability to leverage all the work Epic engineers have done, and might do in the future with UEnum to make it even more powerful than it already is!

And in 4.3, we have switch on enum built into the output of every node!

You can just return your EnumAsByte and there will be option to expand all of the values for the enum = every node has switch on enum now!

:slight_smile:

Rama

PS: and when you save data for your game to compressed binary files, UEnum is tiny

5

Thanks :slight_smile: I will see how this is happening, the thing is - I will have to overwrite a lot of my code now, as I made a lot of things in native classes and structs, without BP exposure. However you are absolutely right, and it will be a lot more easy to edit those things in BP, so later on I will probably have to expose at least parts of those enums and systems to blueprints. The thing is, I don’t want to make uobjects out of everything and thus let unreal manage my memory, as I would want to do it myself with shared pointers etc.