most tutorials for general C++ will focus on the standard library, and incorporating libraries where for Unreal you don’t necessarily need to deal with most of those. the syntax will look much the same, and through the Unreal Head Tool and Unreal Build Tool you get a lot closer to C# (at least in the Editor) while in C++ the Engine abstracts and simplifies a good portion of this as long as you are working with UObjects.
you can think of Unreal C++ as: C++ being moved in the direction of C#, with a tiny sprinkle of Visual-Basic naming conventions.
Similar to how C# is C++ being moved closer to Java
if your C# experience comes from Unity then this can help a bit (the section “Creating Gameplay in Unreal Engine” for C++ code examples with comparisons to Unity C#/mono)
some of the biggest differences for the languages specifically:
-in C++ we have header files (.h files that for Unreal will be found in the public directory) and “implementation” files (.cpp files that for Unreal will be found in the private directory), and we #include
headers in a defined order to get things to know of each other. (kind of similar to Using
) sometimes the reflection system doesn’t play well when creating the files without the Add C++ files in the Editor)
-C++ header/class/function does not know of anything until it is told to know about it again through the #include
not having these is the primary reason to get a linker error.
- for the
.generated.
files these are the things that are created by the Unreal Header Tool and Unreal Build Tool and make the reflection system work, the only thing you need to worry about is that they should be at the very least the last include in the .h
of the same name, and though you can include it in the .cpp it should be avoided if possible.
- things that have a UMacro will need a
GENERATED_BODY()
this is also a mechanism for the reflection system both of these the toolchain will complain at you about with reasonable clarity.
-if you get a LINK Error probably the most obtuse error you will see: just breath, and check your spelling of functions, then check your includes (if the LSP like IntelliSense of Visual Studio/VSCode doesn’t give you a hint to a function/member you are sure should be there you probably forward declared without #include
(the Linker Error will call out what it was told to look for, but couldn’t find)
- the output window in the full information the Error List is a “simplified list” of the output window often lacking details
-C++ gets direct memory management (in Unreal technically this doesn’t have that much of an impact as almost all the UObject derived things will have Garbage Collector oversight, but if you are going to be making your own non-UObjects then you are responsible to manage the memory).
-where in C# you could theoretically just be creating things and expect it will be deleted at some time when it is no longer needed (except when the Garbage Collector decides to run away with your important data-object and even the “Hints” don’t work.
- for UObjects don’t call
new T()
on them, use CreateDefaultSubObject<T>()
, also don’t use delete
call Destroy
(you might be able to get away with not calling Destory
but rather letter the GC take care of it, but if you really don’t need it then get rid of it)
-C++ doesn’t have Generics exactly, but instead the closest thing is Templates (you will be using these at some point if not consistently in Unreal)
-in C++ there is a difference between a reference
and a pointer
(C# does have pointers, but the CLR tries its hardest to hide them away) but this will mostly get into how you deal with them
- references usually a
Type&
is accessed using a “.”(dot) operator
- Pointer usually
Type*
is accessed using a “->”(arrow) operator
- Static members are accessed using “::”
-pointers could be null (check against nullptr
instead of just null
for platform consistency)
-“this” is a pointer (this
is usually not needed to test for null/nullptr because often times if it is null something has truly gone wrong, although for UObjects the engine will allow you to call into a function of a null pointer. personally I found this out by spelling error)
-when passing an argument you get to choose how it is passed, and technically everything can be an input and an output assuming it is not passed by value (when writing blueprint nodes you have to technically pick which are input pins, and which are output pins, but again technically unless it is const
it can be both) ref
still exist in Unreal for blueprint functions, and the C++ compiler might care if the signatures are not exactly the same though this has gotten better.
-be careful when passing larger data-Types without “Reference” or “pointer” because it will create a copy, if it is bigger then a double (64-bits) then it should probably be a reference or a pointer mostly depending on the likelihood of it to exist or not.
-in direct C++ class, struct, and interface are a semantic difference rather then an absolute enforced difference (a struct can have functions, and a interface can have data members, but the Editor and blueprints will mostly act in accordance to C#)
these are “is effectively the same”
C# string is C++ std::string
(Unreal FString or FText/TEXT)
C# List is a C++ std::Vector
(Unreal TArray)
C# Set is a C++ std::Set
(Unreal TSet)
C# dictionary → C++ Map (Unreal TMap this is technically a Hash-Map)
C++ doesn’t directly have foreach but it does have iterator based for-loops
for (Type TempVariable : Container)
C++ has operator overloading, this might come up rarely, so I will specify it for when it comes up.
verbose self commenting C# code will look similar to C++ and both outside of semantics will go into similar structured English.
if both C# and C++ were to hand you a gun, C# would make sure the Safety was On, and ask you each time you fire it if your sure. C++ won’t even blink as you fire at both your feet.
just because you can write raw C or ASM into your C++ for most things in Unreal you are probably over optimizing at that point, and could ignore it unless you are going to be directly modifying the Engine’s Source.
If you have more specific questions or want help converting something specific then you could post it here, or post another question on the forum.
the common programming suggestion is to “read code of the language and try to dissect it” copy a code block into a notepad, delete the comments and see if you can comment what it is doing.
Visual Studio if you installed the Unreal Engine Tool-chain will enable you to explore the Engines C++ Source code (you can right click any Type and pick “Go To Definition”). I would suggest looking at Actor.h (\Engine\Source\Runtime\Engine\Classes\GameFramework\Actor.h) and Actor.cpp (\Engine\Source\Runtime\Engine\Private\Actor.cpp) as this is the class you will probably be working with/inheriting the most.
you probably don’t need Visual Assist or Rider. the Visual Studio team are actively developing the IDE for Unreal, and it has improved greatly in the last several updates to near feature parity.