Why C++ for Unreal 4?

[DWORD]

I wouldn't necessarily say that they went wrong with UnrealScript. It was a language that was a bit more straight forward than quite a few languages. Also because of UnrealScript, I was able to jump right into the C++ code quite comfortably. I would be quite lost if I didn't practice UnrealScript before UE4 came out.

UnrealScript was the wrong choice indeed. It's slow (20x slower than C++) and C# is way more powerful. I wound't say that C# is the future of game programming, but its very good. I prefer C/C++ as a programming language, C# is the second best.

The "easy" transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.

[iniside]

The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.

I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it's a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)

Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol

Well, there is garbage collection for Unreal C++, which essentially solves memory management issues. Or at least doesn't make it any harder than any of other languages with garbage collection.

Most daunting thing in C++ are pointers. It's sometimes wery hard to decide whether something should access trough pointer or just directly (whatever it is properly called). I guess for seasoned C++ programmers is no brainer. But for everyone else, even if they understand concept, it still might be hard call to make, which can lead to issues like "why it compiles and does not provide results I expected".

Other than that I don't really consider C++ to be much harder than any other language. I would call some of it's elements to be annoying to say at least. Like headers or macros.

UPROPERTY() could be solved in more elegant way in C# by using attributes [Attribute], but to make C# implementation on pair you would need ability to compile C# to native code. Which... Was shown on BUILD recently .NET Native. Though it is not multi platform, so it is not solution either.

I honestly don't see a reason to use managed languages or worse dynamic interpreted languages.
What we need is native language with manual memory management and garbage collection. Which... As matter of fact exists. Like D, or M# (this is bit of convoluted by Microsoft worked on something that should replace C++, for native programming).

The "easy" transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.

Well nothing really wrong with that. If you tried to code game in CryEngine, where they don't use macros, custom compilation tool-chain and rely on STL, you would now build altar, temple and shrine to Epic Coders who invented this entire thing, and you would make sacrifices every day to thank them .

[DWORD]

...

Well nothing really wrong with that. If you tried to code game in CryEngine, where they don't use macros, custom compilation tool-chain and rely on STL, you would now build altar, temple and shrine to Epic Coders who invented this entire thing, and you would make sacrifices every day to thank them .

I never said that there is a problem with macros, I was just point out the reason for the easy transition from UnrealScript. I'm fundamentally a C/C++ programmer, so none of that scares me.

[smallB]

Average studio these days utilize C# for Tools at the very least.

We are talking games here not tools. It does no harm for word editor to be written in C# (although Office is C++). On the other hand it does damage for game. And as I've said previously. C# isn't even good for IDE. Visual Studio since they went with C++ is slow and very hard to work with large code bases.
Anyhow...
I definitely stick with C++.

[sandboxgod]

Like many, I've worked with C# in Unity in my spare time. Memory leaks is not something you find discussed on their forums. Was never an issue for my game there (I've been registered at Unity forums quite awhile under this same handle)

[edit] I just searched their forums right fast and all the posts under that topic appear to be many years old

[Cod3rChick]

C++ has been one of the best low-level coding languages for a long, long time. The compiled code runs efficiently and performance is hard to beat. Since it has been around longer than C#, C++ has been the core language for serious pro coders for a long time. With that said, what Epic is doing is catering to the upper echelon of serious programmers who probably have deeper skillsets and experience than do those who only code in C# or Javascript. That's not to say that the latter two are bad, they're fantastic languages, but C++ is the king of the pack. I've coded in all of them, and many others, and for serious game development, I'd do all my core game coding in C++.

Just my $.02.

[Solid Snake]

I don't think Unrealscript was ever the wrong choice because it originated from Unreal Engine 1. It wasn't a system designed for Unreal Engine 3...

[sandboxgod]

UnrealScript was rough back then too. Sure it gave us a nice 'sandbox' environment. But we couldn't debug. Couldn't rapid prototype. Took quite awhile to compile

I see these threads complaining about 2 min compiles and intellisense not working. Really? We had no IDE period back then and I am pretty sure compiling Unrealscript took awhile back then. And oh yeah, restarting UnrealEd....

* State based programming and replication blocks were very nice tho. So were delegates, etc when they were added. Nice language it was.

[OmniOwl]

Coming from a Java/C# background a lot of these posts seems misinformed on how programmers who never Learned C++ looks at this monolith of a language.

C++, while technically not that much harder to learn syntax-wise than the above-mentioned gives you SO MUCH POWER that it's intimidating like crazy.
I've tried to do C++ from time to time but every single time I run into the problem of Pointers. I understand what a pointer is. I understand what a pointer is supposed to do. But I have no idea when to use one and I have yet to find a definitive explanation that says "These are the scenarios dum dum".

All they do is tell you what a pointer is, how to access the data from a pointer and also how to get the address of a pointer. But other than that? Good luck!
I have no idea where to start or where to end when I start on a C++ file. I have the header file which is an infuriating system to begin with (function prototyping? Seriously?) and then I have to match my cpp file with the header file and even if you manage that, good luck trying to understand any of the garbage debugging message it spits out at you which might even be a downright lie. I realize that other languages can lie to you as well during errors but at least most managed languages seems to remember that it's humans who code these programs and not electric engineers.

And then there is the issue of mixed C and C++. Half the time I can't tell when it goes between the two, but even following books to the letter and posting about it on Stackoverflow reveals that even those books lie to you and have the approach of mixed C and C++ syntax.
I would love to see D get the spotlight over C++ because in D it's at least build from the ground up as language that supports Objects and Data instead of a tagged on addition that is C++, the superset of C.

Also in D you can write in-line assembly code, use all previous C code still and even in the memory management department you have options.

* Garbage Collector
* Partially Garbage Collector / Partially Manual
* Completely manual
* Define Blocks in Memory that are off-limits to the Garbage Collector

You can have the best of all worlds.
I love C# and Java languages. They are so d@mn easy to comprehend and the talk about memory leaks is absurd. I have not found anything on that other than age old articles . I don't say switching to C++ was a bad choice as I am convinced it was going to happen regardless, but I find it quite upsetting that there are not other options (Yes Blueprint but lets face it that gets tedious very fast).

[ufna]

C++ is great language for epic things like UE4. And the whole engine is now extandable. You can use even V8 now, if you want to write a code so much. If you're not familiar with cpp you can possible create the whole game using blueprints, and that's really cool


P.S. - Unreal Script was "easier", but not so flexible. And we have to use it because of old Kismet limits, now we can make games, not code.

[Rama]

Coming from a Java/C# background a lot of these posts seems misinformed on how programmers who never Learned C++ looks at this monolith of a language.

C++, while technically not that much harder to learn syntax-wise than the above-mentioned gives you SO MUCH POWER that it's intimidating like crazy.
I've tried to do C++ from time to time but every single time I run into the problem of Pointers. I understand what a pointer is. I understand what a pointer is supposed to do. But I have no idea when to use one and I have yet to find a definitive explanation that says "These are the scenarios dum dum".

All they do is tell you what a pointer is, how to access the data from a pointer and also how to get the address of a pointer. But other than that? Good luck!

Dear Vipar,

I did my best to provide a very inventive explanation of pointers and how they work and when to use them and why they are awesome here:

I am linking you to my subsection on "Why Use a Pointer?" as per your quote above, since my article strives to specifically expand on this topic beyond just the basics.

Why Use A Pointer?
https://wiki.unrealengine.com/Entry_...e_a_Pointer.3F

Please let me know if it helps!


I first introduce the concept of pointers here:
https://wiki.unrealengine.com/Entry_....3E.2C_..2C_::


Again I tried to be very innovative with my explanations.

Enjoy!

(I am posting this for any other readers to enjoy as well)

Rama

[Devlin Kain]

GAH! Pointers, the one thing that wracked my brain in C++ classes. Pointing to memory addresses, changing them on the fly and reallocating the memory to be called a different variable..

....O_O. I WILL be reading and watching many of those tuts. I mean, I am alright at C++, but pointers always made me freak out. Thanks again guys!

[Meltdown]

C++ is the industry standard for game development. Since Unreal Engine targets more AAA it makes sense to keep it C++.
C++ also gives you finer control over the little things, which can sometimes be essential for larger budget projects.

[smallB]

To guys having problems with pointers.
Guys, nobody uses raw/naked pointers in modern C++ anymore. Check unique_ptr and smart_ptr, learn how to use them, and you will never have to think about memory management again.

C++ is simply beautiful.

As for headers and source files. Agreed, pain in the neck. Check out C++ modules though, and you'll understand what I mean when I say ISO committee is working hard on constantly and frequently improving C++.

[Jarhead]

The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.

I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it's a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)

Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol

It is a common fallacy that C# performs worse than C++. C# and C++ can perform equally well when compiled to native code because C# is optimized in the same manner as C++ and in some cases better. It is true that the default behavior is to compile C# to IL, however, this can be changed. Even still, C# has a just-in-time-compile feature, which means the first time an application's execution path leads to IL, it is compiled to native code and from that point on it's just as fast as anything else compiled to native code. However, C# and managed languages have other issues at run time, which make them challenging for games development. This is also the reason managed languages will NEVER be used for game engines. I'm sure there are examples of attempts to make a game engine in C# but it will never be a serious contender in the AAA world.

C# and other managed languages are only the future for applications where more hardware is the solution to memory and performance problems, aka business applications. In games, memory management is super important and managed languages don't really offer the degree of control you need in most cases. For example, garbage collection will cause rather large lag spikes if you don't consider strategies to deal with this. If I create an instance of an object each frame at 60 frames a second, it means I'm creating 60 instances of garbage that needs to be collected each frame. If I extrapolate that out over many objects, you can see that the garbage collector could easily become overwhelmed as significant pressure is applied to the CPU during garbage collection, which causes a visible drop in frame rate. In a large game, this can become very difficult to manage. In severe cases you can see situations where the game skips every couple of seconds due to garbage collection. Having shipped several games in Unity3D, this is a huge problem, which typically requires strategies like object pooling but, even with strategies like this, it's still a real pain to deal with. In C++ you have complete control over memory so you can make it work exactly the way you need it to work, rather than being forced to deal with a memory management solution that is not optimized for games.

In C#, resolving a property on a reference type requires a memory read where resolving a property on a struct does not because it's a value type that lives on the stack. Also, value types can be boxed inside a reference types (aka object), so you need to be aware of this. While this is a very minor optimization example, it's one of many you have to be aware of when dealing with managed languages that either don't apply or have a more elegant solution in C++. The bottom line is that managed languages have a place in games but it's not the future. Business applications are different story because they usually don't have the same type of performance and memory requirements that games do.

When looking at what language is the best tool for the job, it's important to consider both functional requirements AND non-functional requirements, aka memory and performance...