No announcement yet.

Why C++ for Unreal 4?

  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by EruArnold View Post
    I think he makes some valid points in his talk - I don't think he is going to write any programming language himself - he even says so - so I wouldn't worry about his ability or background for being able to personally do it.

    I think his main goal at this point is just to raise awareness of the possibility of such a project, and of the potential net-gain that can be made if/when such a thing would ever exist.

    As for performance, smallB, it is pretty obvious from your reaction that you didn't watch the talk at all.
    He aims for such a new language to not only be faster then C++, but possibly even faster then C.
    Granted, this is no small aspiration, but I agree with him that it is not impossible.
    If you take into consideration the amount of bloat, cruft and general 'legacy'/'backward-compatibility'-related encumbrances that muti-decades-old languages like C and C++ carry with them, you should be able to build a case for the viability of possibly writing a new spec from scratch that does't suffer from such evolutionary-baggage, and thus be potentially faster. He doesn't suggest another "managed-language" (like C# or Java), in fact, he flat-out dismisses the inclusion of any sort of garbage-collector as a 'non-starter', which is the main reason he dismisses Go, for example...

    I liked how he practically dismisses the whole 'smart-pointers' story of C++11/14 as being 'impractical', due to the cost of heap-allocation(s) and the need to consolidate them for any kind of real-world viability in terms of performance. This falls flat in the face of anyone claiming that C++11 'changes the game' so to speak when it comes to memory-safety. It theory, yes it does. In practice, nope...
    Same goes for standard-library templates for 'containers' and 'algorithms' - they may be at the point of being "affordable", in terms of 'programmer-productivity' (thanks to the addition of 'Lambdas' and 'auto'), as well as 'run-time-performance' (mainly thanks to r-value references, 'Move-Semantics', perfect-forwarding, variadic-templates, etc.) - but all of this is not 'free', and incurres a cost at 'compile-time' - which makes them ultimately 'un-affordable' in the grand-scheme... (at least for large-projects, due to the accumulative compile-time-cost).

    I am not sure this is a solvable-problem in a new language, but let's think about it:
    Let's say a new language is designed, do the default-behaviors are the ones that are actually being used ~80% of the times in C++ anyways:
    1. Variables are 'immutable' (const) by default, and you have to explicitly define them as mutable using a key-word (Rust does this).
    2. Ownership is 'Moved' by default, and you have to explicitly state you want to 'Share' (Rust does this, sorta...)
    3. Arguments and assignment-operators are 'pass-by-reference' by default, and you have to explicitly say you want a 'copy' in case you do.
    4. Memory-Allocations of members (for structs/classes) are optimized in the compiler to be done 'in-bulk' by default, as well as guaranteed to be layed-out sequentially (which prevents the whole 'memory-block-member' workaround shown in the video, and known very well by game-developers).
    5. Pointers are unique by default (using a standard-notation, built-in to the language, not a template in a library that needs to be compiled...).
    6. Shared-pointers have their own notation (say, re-purposing the '&' for this semantics, given No.2 + No.3 makes C++ style references redundant).
    7. Arrays are implemented built-in as the C++ Vectors are, and not as a compiled-template.
    8. All other containers as built-ins instead of templates (Maps, List, Queue, Set, etc.).
    9. Algorithms as built-in-functions instead of templates (Sort, find, etc).

    I can go on, but you get the picture...
    There is A LOT of room for improvement from what C++11/14 offers, just by taking a look at patterns that are already being done for decades now, and switching-up the default-behaviors to represent the +80% use-cases, as well as turning templates into built-ins - all of which can dramatically improve code-readability, expressiveness AND performance, memory-efficiency and safety, and all long before one even begins to talk about game-domain-specific optimizations...

    So yeah, would it be difficult? Probably. Yes. Is it impossible? Definitely no. Is there a strong case for it? HELL YEAH!!!
    This guy will never introduce any new language. He may aim and introducing language that is faster than C++, but all he will end up is just couple of excited talks. Nothing else.
    Everybody can come up with great ideas for great language. This is so easy.
    Implementing it, making people to use it is a very different story as @inside rightly pointed out.
    I hope you not taking this guy seriously.

    If I'm wrong I will admit that I was wrong and get you a beer.
    If I'm right you will admit that, deal?
    Lets give him 2-3 years and we see how this project progresses from where it is now, that is, big, "fairyland" talk, nothing concrete, nothing else.
    Last edited by smallB; 09-26-2014, 02:01 PM.


      Of course this is very early, but there seems to be enough of a demand for such a thing, so my bet is that it's going to get done eventually.
      In fact, Rust may end-up being it, as he says - his only 2 reservations regarding it, is it's memory-safety that feels too constraining (though there exist an escape-rout in the form of 'unsafe {...}' blocks), and it's relative 'immaturity', which will be even more of an issue for a completely new language, and should be somewhat resolved in a few months/weeks for Rust when it officially reaches '1.0' - and even much more so in a year or 2 when 'Servo' launches (Mozilla's next-gen browser written in Rust).


        Lets wait then.


          Originally posted by timconwell View Post
          OMG! That would be sweet.

          10 PRINT "UE4 Rocks!"
          20 GOTO 10
          Thanks for remembering how old I am!


            So the flood-gates have finally opened, and cppcon 2014 video-recordings are starting to poor-into YouTube...

            Happened to stumble upon a particularly relevant talk about C++ for Game-Engine development:

            Turns out, as you can see in the talk, that not only C++ is unfit for scripting, it is even also unfit for game-engines (!)
            The speaker was asked specifically what are the benefits of using C++ as the language of choice to implement a game-engine, to which he could not come up with any answer... If it was up to him, the entire engine would be written in C99 with some parts in assembly (yes, he actually said that explicitly in a C++ conference...).
            Bjarn's short-description for C++ has always been on the line of "...affordable abstractions..."
            Well, turns-out they are not so affordable after-all, and that compile-time is almost as important as runtime.
            So, they don't use the STL at all, as well as (almost) never write or use any Templates(!)
            Why? Too expensive in compile-time... (yes, that's what he said)
            Think about the magnitude of that statement:
            That means no smart-pointers of any kind (yes he said that specifically also), as well as no use of any standard containers or algorithms.
            They also never use multiple-inheritance and tend to shy-away from virtual/abstract methods and function/operator-overloading.
            Why? Too expensive in runtime-cost (perf. and/or mem.)
            They also shy-away from having much members in any given class, as they tend to favor custom-made allocators.
            So, where are all these so-called "affordable abstractions" that have consistently been promised as the pinnacle of C++? Turns out there aren't that many left...
            And if this isn't enough, turns-out that most compilers still optimize very poorly (surprised?), especially MSVC (no surprise here...), and require the code to include lot's of unnecessary helping-hands to nudge them in the right direction.

            In short, the C++ that you tend to find in game-engines code, seems to end-up looking like "C With Classes" at best, and "Pre C99" at worst...
            Abstractions? Type-Safety? Modern-Style? Turns one none of these "luxuries" are affordable for game-engines...
            The only reason the speaker found to use C++, is "cultural", as he notes many times...

            So, seems like even Modern C++ is the "middle-man" that no one likes - it takes too much and returns very little benefits...
            Too slow for game-engines, too unproductive for scripting game-logic.
            Last edited by EruArnold; 10-01-2014, 06:08 PM.


              Hi All.

              I too am familiar with BASIC and FORTRAN....gawds I hate that language. haha!!

              I have been watching this topic as well as watched the two above Youtube vids....thank you by the way.

              Since it has been brought to the front as a C++ Hybrid or more Elegant Language......I will have to say that NWScript is basically that language. Very powerful, elegant, easy to figure out and use. Looks like C/C++ in format. There is even a Lexicon for all the internal functions and descriptions. How the scripting language actually functions between the lines is the development to speak with memory and game specifics. If anyone has programmed in NWScript will know that productivity is extremely high....and if we were allowed to access more of the 'Internal' BioWare Aurora engine specifics the language could have been even better. I still enjoy programming in it.

              As for UE4 I would be a huge advocate for a Middleware that has commonality to NWScript that makes thing simple for all sorts of UE4 uses.

              **I did this to a large extent in Unity but in C#

              For any curious programmers

              Some of the craziness in this forum topic is just silly, however, I have very much enjoyed watching this and reading everyone's opinions. I agree on both fronts on this.




                Don't forget UDK/UE3 was build around a script language called UnrealScript. There are many reasons why they removed this UScript from UE4.
                Seems for some of the guys, C++ is not enough and want to bring in lots of obscure scripts languages, for the sake of "elegant" coding reason. Absurd.. totally absurd.

                Originally posted by EruArnold View Post
                So, seems like even Modern C++ is the "middle-man" that no one likes - it takes too much and returns very little benefits...
                Too slow for game-engines, too unproductive for scripting game-logic.
                C/C+ is not here for games, and was not made only for games dev. And is fast enough, if you want the ONLY fastest route over C/C++, go ASM and good luck with that finishing a game/application.


                  Originally posted by TDoro View Post
                  C/C+ is not here for games, and was not made only for games dev. And is fast enough, if you want the ONLY fastest route over C/C++, go ASM and good luck with that finishing a game/application.
                  I was paraphrasing the cppcon talk above, and in it's context.
                  I was not making a general statement - I agree that that would be silly...

                  At least from the perspective of the speaker in that talk, he basically only uses C-level features out of C++, and combines that with some ASM that he writes manually - you should really watch this talk, it's quite different then most other conference-talks I have seen of late. He states up-front right at the beginning of the talk that writing in ASM exclusively is not an option, for obvious reasons that we all know. The question is thus, could there be a more 'modern' version of C that can replace C++ for game-engine writing. My guess is that this is starting to happen, with promising contenders like D and Rust. Just in terms of compile-time, nothing nowadays beets D as far as I know, and I think both D and Rust have support for in-line ASM block, so they just seem like a much better fit for next-gen game-engines.

                  But the reason I brought it up, is because I am learning 'Modern' C++ these days, and UE4 is the only game-engine that I know of that supports it (binary-compatible, due to it being developed and compiled in MSVC of VS2013), and I was really disappointed to discover that game-engines generally don't use any high-level C++ language features, on the count of them being 'too slow'... For example, I would have liked to see much less wide-spread reliance on 'macros', as they are not type-safe and are very difficult to debug (plus, most intellisesnse don't work with them correctly, don't auto-completes them, etc.). So, if you're coding against a 'practically C' API, what's the point of it supporting 'Modern C++'? It makes it look like 'vaporware' - a false-promise on behalf of Epic... Sure, you 'could' use templates and such in your own code, and that's cool and all, but it's one thing to 'consume', say, the STL, but it's quite another to consume a game-engine library/API that is written using templates (which it seems most game-engines don't, including UE4). So, you also 'could' write your own templates and build your own library, but that is way overkill for what you 'should' be expected to do... Templates are for library-authors and API designers - the likes of the people who write game-engines - it is NOT intended (or rather shouldn't be considered to be intended) for game-designers and game-logic coders. One would expect a Modern C++ game-engine to provide with high-level abstractions that are conveniently consumable by anyone wanting to code game-logic against that game-engine, and iterate on design-ideas quickly. Alas, it seems these high-level productivity-enhancing features of Modern C++ are too expensive for game-engine to design their APIs around, and the only thing that shields a game-developer from having to interface with a game-engines "C like" API (type-unsafe, leaky/dangerous, etc.), are a slew of 'macros' that are very unproductive to work with... This just comes as a very grossly unfortunate predicament for the games-industry, and I think that most game-developers know this reality and it's frustration very well - which comes with sharp contrast to what 'C++ Zealots' (like smallB here and others) are preaching to themselves and others...

                  The situation is much less rosy than the way it is being presented, and it just makes the whole story seem very disingenuous - is my general point.


                    Originally posted by EruArnold View Post
                    So, if you're coding against a 'practically C' API, what's the point of it supporting 'Modern C++'? It makes it look like 'vaporware' - a false-promise on behalf of Epic...

                    The situation is much less rosy than the way it is being presented, and it just makes the whole story seem very disingenuous - is my general point.
                    While I agree it may not be as nice, I don't consider it a false promise and I appreciate what Epic has provided. If Epic used all "Modern C++" the engine and compilation would be slower, which would mean less effects that could be supported, less actors, less detail, slower speed, etc. The whole reason modern game engines use C style with some C++ is because it is faster. Bottom line.

                    C style isn't really bad at all. In some cases I prefer it for it's speed, macro's are iffy though, lol, but they are used as a neat hack for the editor as well. In programming you use whatever you have to, to achieve your goal reasonably well. A game engines goal is to push as much data as it can through the CPU and GPU, and if you're talking about speed you're talking about C. C++ in quite a few cases can get just as fast, but not everywhere. The C++ standard libraries are developed to be as fast as they can for general programming, but not all of them are fast enough for game programming (or at least engine programming). The D language is the only language which looks like it has a hope of competing in the future, but they have to straighten out their memory management.

                    To a decent programmer, it doesn't matter if the language is C, C++, ASM, D, C#, Java, Perl, PHP, Python, JavaScript, Ruby, etc, they can make it work. Some have some nicer features and make things a little easier, but when it comes to good engines and games you have to expect it's going to take professional level work.

                    I don't say it's a false promise when they say that you can "Quickly create a wide range of surfaces that hold up visually under close examination...", and I try it out and find out that the tool is complex. Of course it's complex for me, I'm not an artist. I can't expect a drag and drop scene with just a few clicks and sliders and all of the sudden I have an amazing scene. Nice games with a lot of detail and powerful technology are complex, it's just part of the job.


                      One can program in C++ in a wide range of styles, covering procedural, object orientated and then some things living in spheres mere humans might write but not really understand anytime soon again aftwards (worse if someone else wrote it). Template metaprogramming is on the verge of beeing unreadable (can only talk about me. Heres the chance to let everybody know what a superporgrammer one is and thats *really easy* to do. lol), so Im *quite* happy UE4s codebase doesnt look like WebKit


                        Thanks for the links EruArnold, even if they arnt directly on topic I still think they are very useful for programmers. I know Im constantly complaining about the complexities of C++, that there are too many nuances and that more global scope standards are better. I see far too often in C++ people breaking their own rules, not sticking to the standards set by the API they are interfacing with let alone the standards set by the language itself, I know its a powerful language but as they say with great power comes great responsibility. For me, I dont want that responsibility, I do want to be able to create DataTypes but I dont want to require a degree in quantum thermodynamics to be able to do it, I love auto-initialization, I love auto-exposing variables in a manner that allows WYSIWYG editing, there are a whole host of things that are great about Epic's API that arnt directly related to C++ such as Garbage Collection. I do appreciate some people want the performance end but Im sick of having to write so many extra lines because one of these watch makers decided that IntVector shouldnt be used with UPROPERTY, I think that people who want those things should be the ones who have to do the extra defining, to remove the layers they dont need rather than me piling them on, especially since my goal is to work with Epics API first and foremost not with the core C++ language or any other libraries.

                        One example Ive used recently is this, to expose a variable to the editor in UScript:

                        Var() int ThisX;

                        in C++ with Epic's Headers:

                        UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "")
                        int32 ThisX;

                        Now I know different platforms can have different sizes for int and whatnot, I know that complexity exists but I really dont care about it, Im not asking for people to not have that level of access just stating that I really dont need it, I never have, not even back modding Quake, all the way up and till now and in the future. I like blueprint because it hides some of the complexity but it really isnt a replacement for UScript, the only way to get that type of level is to do C++ but then you have to take all the complexity that comes with the entire C++ language ontop of the API and interop complexities ontop of that. Epic have done a really good job with what they have to work with, there are some amazing mathematicians/programmers working at Epic but we cannot ignore the fact that we need to get simpler tools into the hands of designers so that programmers can focus on Engine level code and that is why Blueprint exists. My issue is that Im being told that I should use C++ for any serious programming when in all honesty alot of what I do in Blueprint could be converted into C++ text by the editor and then compiled out, if that is too complex to happen, if machines have trouble writing C++ then you can sure as hell think humans would too. I must admit, the core C, when its stripped down and used as in GLSL for example, Nvidia have some great examples too of some really solid math libraries, unfortunately Epic's maths libraries are overshadowed by the other complexities.

                        Basically the gist of it is that people using Blueprint shouldnt be treated as second class citizens, that C++ is useful but it should be used sparsely and effectively, especially to expand the abilities of Blueprint.

                        Thanks again for the links
                        Last edited by MonsOlympus; 10-04-2014, 07:41 PM.


                          IMO, Node.js has struck a nice balance that would work well in a game dev platform. When you have at least a clue about both languages and how the platform itself works, there are things you would never want to do with one that you should do with the other. The key to keeping your scripting platform from getting twisted with all of your lower-level performance critical stuff IMO, is to split the two across an event loop with the one on top being a language that only executes one function at a time. That maintains the distinction that things like thread management and lower-level performance critical tasks are not the scripting language's job.


                            Node.js, like JavaScript ? I wouldn't unleash JavaScript on my worst enemy. Not to say about normal people.
                   - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.


                              I have not read the entire thread but saw references to D and Rust. I'm curious if there are any technical reasons that those languages can't be used with UE more or less out of the box?

                              Can't you call C/C++ functions from Rust/D?

                              Can you compile UE assets using UE tools, then compile your Rust code using Rust compiler and then link the two binaries?


                                Guess this is common knowledge now, but...

                                Unity users can program in C#, JavaScript, or Boo. The development environment runs on Mono, an open source version of the .NET Framework.

                                Unity itself is written in C++.

                                “The code that has to run super-fast like the physics and animation, all that is C++, but the code that should be easy to write, you can write in .NET.”

                                (Cite from Helgason, one of Unity's pioneers.)
                                "Fortune favours the prepared mind..."
                                - L. Pasteur