4.6 Transition Guide

Anyone having problems with TMap? My project worked fine in the previous version but in 4.6 it crashes inexplicably…

Any assistance greatly appreciated.

Consider this post a “I think TMap has changed” :stuck_out_tongue:

I replied to your answer hub :slight_smile:

You’re welcome Jeff!


BlueprintImplementable Const Reference

In 4.6 I have to change this

virtual void BP_Event_SolusFootStepOccurred(FVector Location,TEnumAsByte<EPhysicalSurface> SurfaceType);

to this

virtual void BP_Event_SolusFootStepOccurred(FVector Location,**const **TEnumAsByte<EPhysicalSurface>**&** SurfaceType);

or it will not compile

I seem to recall a time when I could pass TEnumAsByte by value to a BP implementable event, but not any more.

It gives a very vague compile error now, saying the function “was not found”

So if you have any issues with this, try using const reference!


Er, or just pass the enum directly by value:

virtual void BP_Event_SolusFootStepOccurred(FVector Location, EPhysicalSurface SurfaceType);

TEnumAsByte is a storage construct. Its main use is to restrict size of an enum to a single byte, making the managed code able to predict the size of a stored enum as it otherwise varies by compiler.

You also get type safety as an added bonus, but if you care for that you really should be using either the namespace enum idiom or an enum class.


Yup that does work too!

For consistency with the code base I tend to use TEnumAsByte since it is required for UPROPERTY()


it is not required anymore if you use the new recommended way of declaring enums, which is the c++11 good style.

ie use enum class

Did the upgrade from 4.5.1 to 4.6 here in the office today. This guide was handy, thanks!

oooooh thanks for that info!

I updated my Enum wiki accordingly.

EDIT: oh wooow, I’m loving the new C++11 enum, so much easier to work with :slight_smile:

Did the upgrade from 4.5.1 to 4.6 here in the office today. This guide was handy, thanks!

Great to hear from you Ambershee!



Hi all, thank you Rama for your efforts, very useful thread !

I too have problems with updating my project to 4.6,
I managed to fix everything else pretty fast, except that I can’t seem to spawn a blueprint.
I asked a question on answer hub last weekhere:
I spent some more time on that and made several tests including struct FConstructorStatics way,
no luck so far, even if it compiled it didn’t work in the game.
Anyway I feel I’m getting close, will try to figure it out soon as I’ll have time.


Talking about the new enum style.

How do you compare or use enum (like for a array index) without casting? It was transparent in the old way, but not with the new way.
ex: MyArray[MyEnumValue], now you have to do: MyArray(int32)MyEnumValue].
you can’t do that also : GetDisplayNameText(EnumValue). you must cast.

More how do you get the enum from a number?

Did I miss something?


Nor should it ever have been. C style enums are not type safe, and implicit conversions thereof have been a recurrent source of errors. People have come up with workarounds like namespace enums to try and guarantee some sort of type safety, but it’s still imperfect because of those implicit conversions.

Just static_cast to/from enum class, it spells out what you mean to do and helps make sure you’re not implicitly casting the wrong thing by accident.


I replied to your Answerhub :slight_smile:


If you are going to do that you should definitely use


Because the enum is really a byte as you can see here:

UENUM(BlueprintType)		//"BlueprintType" to expose to Blueprints
enum class EVictoryEnum : **uint8**
        VE_Dance 	UMETA(DisplayName="Dance"),
        VE_Rain 	UMETA(DisplayName="Rain"),
	VE_Song	UMETA(DisplayName="Song")

It is of course not entirely recommended way of doing things, but int32 is simply out of the question under any circumstances :slight_smile:

G**etting Value**

You mentioned wanting to get an exact value of an enum, you can get exact value even like this if you want!


SCREENMSG2("bytecast", **uint8**(EVictoryKeyModifiers::Shift));


Again, I am not suggesting this is an ideal way to do things, I'm just answering the question :)



bumping this for anyone still doing 4.6 transition

Why was TSubObjectPtr deprecated? I read on their Answers page that it’s used in internal GC process, where the engine would be aware of the fact when the data was cleared and therefore automatically set the pointer to NULL, essentially making it easier on programmer to keep track of pointers. Do traditional C++ pointers now act the same way as TSubObjectPtr used to?

To paraphrase Epic’s own statement, TSubObjectPtr was clunky and weird, and using regular pointers is so much cleaner and simpler!

As long as you use UPROPERTY() with your pointer, it will follow normal garbage collections rules.

I have a full wiki on UE4 Garbage Collection and UPROPERTY() here:

Garbage Collection in UE4


Seriously, I get all my C++ info from Rama, Epic should hire you because like others said, this board is nothing without your help.

Can this get a sticky please?

I think it’s safe to say I love you Rama.

Oh, I didn’t know about all these awesome C++ tutorial, thanks a lot !

Hee hee!

Hee hee!! * Blushes *

you’re welcome!