Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    @ShadowKindGames, that's a pretty bad post you wrote and it's in very bad taste.
    Godz for UT '99 / UT 2003

    Comment


      So, I think we've established the bonuses of going with C++ and some of the weaknesses. I am curious do people have any thoughts about rapid prototyping with C++? The editor can pretty much reload most changes fine. The only weakness I am seeing that hampers my productivity is when I add a C++ class within the Editor interface I have to shutdown the editor and restart it. I don't suppose anyone is looking into trying to make the editor more prototype friendly? I've worked on game engines before in C++ but we've never supported reloading a DLL so this is currently out of my domain of expertise atm

      One thing I don't see people mentioning, I like how I can use Visual Studio directly with the Engine w/o additional plugins. In sharp comparison, if I want to debug Unity I have to run Monodevelop. If you want to fully support Visual Studio with Unity you have to pay extra for a plugin.

      [edit] Funny just noticed a thread where Epic already answered this question
      Last edited by sandboxgod; 04-15-2014, 11:03 PM.
      Godz for UT '99 / UT 2003

      Comment


        Originally posted by Shadowriver View Post
        Did anyone saying here you need to rewrite UE4 or something? People acting here like C++ is something terrifyingly hard and time consuming, in reality engine APIs is no different from seem in other UEs, it feels like using UnrealScript just it's C++... and thanks to that you can do anything unlike it was in UnrealScript, which also required C++ to go beyond things. And it also got same object management and garbage collection. Blueprint missing something which is in APIs? just bind it with child class which you can use in blueprint and there you go.... you exteded borders of this engine already.... and it actually easier then making Kismet nodes in UnrealScript And not to mention all i did is recommand, not command people

        But again there no point of argueing really, if people hate C++ so much that they even don't what to try it and want to use C# or anything else... no problem, there people already doing even C# editor integration for that and i bet they are not AAA studio (studio that have AAA reviews by definition? ), and there JUST one person who works on JavaScript support for everyone, over time i bet where will a hell lot of plugins for lot of stuff for others to use, extending borders of this engine
        I'm not saying C++ is going to ruin making a game, neither am I saying it's that hard once you get used to it. I've used Unity and I like C# I think it's a decent language, but I'll use whatever it takes to get my game shipped. Point being, everything has there merit's I wouldn't write off people wanting to use higher level languages, it's whatever the team / person is most productive with.

        @sandboxgod: What are you talking about? How about you be more constructive and add a bit of detail to your post? That reply was in "Poor taste"..
        Last edited by ShadowKindGames; 04-15-2014, 11:27 PM.

        Comment


          Originally posted by nlaq View Post
          Did you read the thread? There are quite a few garbage posts such as:

          The comment you were referring to was directed at posts such as these.

          Note that in my reply, I did state that native code is a very appropriate choice for many of the performance critical subsystems in the engine; but may be significantly less so for game logic, AI, networking code and so on (i.e. a majority of the game-specific logic you may wish to implement).
          My apologies about that one, I did in my haste filter out those sorts of posts and didn't consider them as anything but noise (certainly they aren't well reasoned debates).

          And of course that's all we are doing here is debating the pros and cons here of which there are many facets.

          Originally posted by nlaq View Post
          That's because C++ being inherently faster than C# is a myth. Writing the same logic in either language will produce fairly similar results in regards to performance; C# is compiled into IL, IL is compiled (at runtime) into machine code...
          That's not a statement that's born out in reality and testing. There are cases where C# can be as fast, but saying that in general a JIT'ed language is just as fast as C++ glosses over an enormously complex and varied set of circumstances. The Mono optimizer typically employed by users of Unity is much slower than the IL that is compiled by a microsoft JIT optimizer. And even in the the later example, certain parts of the IL specification (like as you mention indexing) eliminate some types of optimizations that can be done.

          It's my opinion your assertion that C# is as fast as C++ is false in general, and true in certain cases. It's also my opinion that C# is plenty fast and reasonable to do a large variety of things in.

          http://creamysoft.blogspot.com/2013/...rformance.html

          The next article is much more exhausting and examines head to head comparisons of C# and C++ in a large variety of isolated cases, as well as larger programs. In almost every case C++ is faster by a factor of at least 2. One of the later programs, a Soduku solver runs 200% faster in C++.

          http://www.codeproject.com/Articles/...-Csharp-vs-NET

          Originally posted by nlaq View Post
          There are certain things that the runtime does that makes it slightly slower (array references are bounds-checked for example - though scoff at this all you want, but this feature has removed a metric crapload more critical (and potentially security related) bugs than C#'s lack of constness has added).
          I don't scoff at that feature by any means but that's a security feature not a stability feature. An IndexOutOfBounds exception is typically a fatal error, or will at least lead to undefined behavior. I don't see that as necessarily beneficial to have in game-code, where security and in particular memory overrun exploitation bugs are not an issue you are typically designing around.

          If your point was that you can find those errors faster, as they happen, then you are just not aware that C++ provides similar and potentially superior ways of doing the same thing (for example boost:array). The benefit with C++ is that when you are ready to "go fast now" you can disable the indexing checks if you want to.

          Originally posted by nlaq View Post
          Many other systems, the kinds that a gameplay programmer, tool developer, or AI developer would write are not performance critical. Giving them a leg up in productivity and correctness is worth a slight performance hit - hell, while this figure is absolutely incorrect, I'd even say a 2x performance hit is more than worth it. Remember: these systems do not need to be executed many times in a frame.
          It's difficult to agree or disagree with this without a better use case. The only thing I can say for sure about whether in general you'll be more productive writing those systems in C# than in C++ is: it's complicated, and not necessarily. Dealing with the GC in some of those cases might be a drain on productivity. C# does make certain types of things harder to do, but it also makes some things easier.

          Originally posted by nlaq View Post
          Safety Features:
          - Array bounds checking
          Identical feature: C++ boost:array (superior because you can optionally disable the checks when you want to "go fast")

          Originally posted by nlaq View Post
          - Better type safety
          Both languages are strict-statically typed. This seems like you are equating the fact that C# has a subset of the type-casting features of C++ as equivalent to "more safe because it lacks that ability".

          Originally posted by nlaq View Post
          - An exception system that developers aren't embarrassed to use
          Not sure about that one, in my experience they are essentially equal. I don't litter my code with the nothrow() stuff though. I've never really seen a big difference there. Are you talking about C# exceptions vs SEH?

          Originally posted by nlaq View Post
          - No raw/dangling pointers
          As a type safety feature I agree.

          Originally posted by nlaq View Post
          - Requirement that variables be definitely assigned before access
          C++ catches these cases as warnings. Warnings=error setting is a good practice to have.

          OO Features:

          Originally posted by nlaq View Post
          - Interfaces
          C# interfaces exist simply to fill in the gap because you don't have multiple inheritance.

          Originally posted by nlaq View Post
          - Better enums
          Agreed.

          Originally posted by nlaq View Post
          - Lack of multiple inheritance (I've yet to see a proper use-case of multiple inheritance in C++, except in the case where classes with only pure virtual methods are used to emulate interfaces). This especially holds true as the programming industry, at large, now discourages heavy use of inheritance in favor of composition-based OO strategies.
          Not a benefit of the language. Here's a good use case in C# that illustrates issues with GC and lack of multiple inheritance:

          A generic linked list container that puts the linkage pointers inside the class, instead of allocating linkage nodes like the C# library System.LinkedList does:

          Code:
          class Base { // some basic functionality };
          
          // OK I want to make a new class called Derrived that goes into a generic linked list class without having extra heap allocations for the linkage pointers.
          
          class LinkedListNode<T> : where T class { T prev; T next; }
          
          // Can't do this! C# doesn't have multiple inheritence.
          
          class Derrived : Base, LinkedListNode<Derrived> { // do some special things }
          
          // Forced to do this:
          
          interface ILinkedListNode { Next { get; set; } Prev { get; set; } }
          
          class Derrived : Base, ILinkedListNode {
               // Forced to implement ILinkedListNode in every class that goes into my LinkedList.
          }
          Originally posted by nlaq View Post
          - Arguably better generic type system. C++ templates are glorified macros, while generics in C# are baked straight into the runtime. 90% of cases where C# generics can't emulate something that you can do with C++ templates are unnecessary in C# - such as traits. Furthermore, generics in C# do not affect the size of the assembly, nor the time it takes to compile.
          C++'s template meta programming is a full turning complete language. To suggest they are glorified macros leads me to suspect you don't have very much experience with either of them. C# generics are much more restrictive, and don't perform as well as C++ template code does.

          C++ templates do increase compile time and code size, again a trade-off in power and performance vs a less capable but faster to compile feature.

          Runtime Features:
          Originally posted by nlaq View Post
          - Proper reflection - which includes instantiating generic types at runtime. Yes, reflection can be emulated in C++ though heavy use of templates, but this adversely affects compile times as well as runtime performance.
          - Type safe dynamic code generation via expression trees
          C# wins here, but I'm not sure where this part ties into your game programmer example in particular. I can see reflection being sort of useful as an archetype system or dynamically creating behaviors from XML.

          Originally posted by nlaq View Post
          Other Features:
          - Unicode (UTF-16) is baked straight into the framework and requires no additional thought. The existence of a string primitive (and lack of support of C-style strings) removes complexity and increases compatibility with third party code.
          - The existence of a delegate type. This, yet again, can be emulated in C++ though clever use of templates and other features - yet, delegates are a first class citizen of the .net world.
          Agreed, but C++11 now has lamba functions and closures now, so the gap has narrowed on that one.

          Originally posted by nlaq View Post
          Productivity Features:
          - Much, much (much much much much) faster compile times
          - Visual Studio's C# support, combined with ReSharper, destroy any toolset of any language I have come into contact with. Ever.
          - The way in which the compiler handles errors (C++ errors, especially linker errors, can be quite cryptic)
          Yes. Although some of this is because of C# restricted feature set.

          Originally posted by nlaq View Post
          C++ is hardly more "expressive" than C#. C++ is a hodgepodge of features that, with dedication and discipline, can be cobbled together into sensible code. Most of the time, however, these "expressive" features of C++ are simply used to emulate features that are inherently available in C# and other .net languages. Slate is some sort of odd subset of C++ that cleverly uses some of C++'s unique features (such as C++'s obscene list of overloadable operators) to create a programming experience that is some kind of imitation of a C# like language combined with a declarative DSL.

          Furthermore, it may have been advantageous for Epic to have created an actual, outside-of-C++, DSL for slate layout files. Creating DSLs is incredibly easy to do in C#, especially with tools such as Antlr - and if you combine them with the dynamic code generation features of C#, they can have the same performance characteristics of straight-up managed code.
          The rebuttal here is just a redirection and a handwave that avoids facing the real issue presented with Slate and UObject. I have no doubt a system as feature rich as Slate could have been done in C#. However, Slate and the UObject system brilliantly demonstrates the expressive power of C++ and C# totally lacks the features necessary to do this.

          Comment


            Originally posted by sandboxgod View Post
            One thing I don't see people mentioning, I like how I can use Visual Studio directly with the Engine w/o additional plugins. In sharp comparison, if I want to debug Unity I have to run Monodevelop. If you want to fully support Visual Studio with Unity you have to pay extra for a plugin.
            I don't know what you exactly mean, but debugging works without any plugin, you actully needed to see where your code crashes
            =========
            My Tutorials:
            Basic knowledge about Classes and UObject environment and stuff like that

            Comment


              Yeah I think you misunderstood my post

              [edit] Here they discuss what I refer to
              Last edited by sandboxgod; 04-16-2014, 12:08 AM.
              Godz for UT '99 / UT 2003

              Comment


                Originally posted by eblade View Post

                * of course, there will be some things where your bar of performance may be vastly different, but for some tasks, C++ doesn't give acceptable performance, either.
                The performance of C++ will always beat C# or Java. And yes, you can write **** in any language but **** written in C++ will always be faster than **** written in C#/Java.

                Comment


                  Originally posted by Serapth View Post
                  No offence, but your comments are pretty common to the amateur mindset.
                  None taken, I am professional programmer (note: not professional C++ programmer) for years now, and due to my experience I (for games development) choose C++ over anything else, each time.
                  Originally posted by Serapth View Post
                  The C++ == speed meme is something you really have to get over. A pragmatic ( read -- good ) programmer looks at all tools available to do the job and choose the right one for the situation. Even in games, and other realtime perfomant applications, C++ isn't always the right tool, although often it is. Dismissing other tools based mostly on reputation is silly at best.
                  No reputation, but facts. C++ does provide best performance whilst providing high level of abstraction. This is not a reputation. These are facts.

                  Originally posted by Serapth View Post
                  Would you hire a contractor that thought a hammer was the solution to every problem?
                  Please spare me those silly analogies.

                  Comment


                    Originally posted by eblade View Post
                    I use the tools that get the job done, but I'm rarely the guy deciding what those tools should be for a product.
                    Python, PHP, Unrealscript, Javascript and other slow motion creatures will not get the job done in AAA. Forget about it.
                    This is gaming industry, every tick matters and nothing beats C++ - get use to it and the sooner the better.

                    Comment


                      Originally posted by MonsOlympus View Post
                      (Im used to dealing with zealots).
                      yep, sure. And you consider everything else but C++ - how is this for oxymoron?

                      And just to make sure, I am not a zealot. I don't mind any language. If at some point there will be language which outperforms C++ whilst giving at least the same level of abstraction and freedom, I drop C++ in an eye blink.
                      But as things are for now, C++ is the king of performance, C++ gives you high enough level of abstraction and C++ gives you virtually unlimited freedom. No other modern language can give you that at the moment.

                      C#? Please, give me a break. C# destroyed my beloved IDE (Visual Studio).
                      Last edited by smallB; 04-16-2014, 07:07 AM.

                      Comment


                        Originally posted by MonsOlympus View Post
                        which Im not complaining about by the way!
                        So what is it that you're actually complaining about?

                        Comment


                          Originally posted by smallB View Post
                          Python, PHP, Unrealscript, Javascript and other slow motion creatures will not get the job done in AAA. Forget about it.
                          This is gaming industry, every tick matters and nothing beats C++ - get use to it and the sooner the better.
                          Well as i rember battlefield 2 engine used python for scripting, ofcorse its not like used in every frame
                          =========
                          My Tutorials:
                          Basic knowledge about Classes and UObject environment and stuff like that

                          Comment


                            Originally posted by Shadowriver View Post
                            Well as i rember battlefield 2 engine used python for scripting, ofcorse its not like used in every frame
                            I genuinely don't want to hear about python, javascript, java nor c# where games (AAA games) are involved.
                            Go here http://readwrite.com/2011/06/06/cpp-...oBB4syd7S289Rq,
                            see how some of the languages compare to C++.

                            Why would anyone choose anything but C++ for AAA game development is beyond me.

                            But it is not even about the performance.
                            The deeper you go with coding the more you starting realize that C# or Java are not only not easier but lots of things are far more difficult to do with them than with C++.

                            Guys, is C++ perfect? Absolutely not. Is it better for games development than C# or Java or any other modern language. Without any doubt.

                            Comment


                              Why are people still discussing this? Is this a discussion about programming languages? If so, then there are a lot of forums where you can go and discuss.

                              UE4 was programmed in C++, and this time, Epic didn't included a scripting language. And they did so because, besides the reasons given by Tim, there are no reasons whatsoever to do so. Unlike UDK, you have complete access to all code, so if you want a scripting language for the engine and integrate it with the editor, then you can easily do so.
                              "I have harnessed the shadows that stride from world to world to sow death and madness."

                              Comment


                                Originally posted by smallB View Post
                                So what is it that you're actually complaining about?
                                Because people have something to say to c++'s detriment that means they are complaining? I dont always answer questions with questions but if I was going to complain it would be about someone posting 5 times in a row on forums. I said my piece, Im done here. I could go on about VS longer than I could C++, I have never liked it since I first tried it back at version 5 but I can see youre upset about something unlike the rest of us (you probably dont want to see me upset). If youre upset about that then youre directing that at the wrong people, we are here for Unreal Engine and I dont think it matters what IDE or language it uses because people will be there supporting Epics amazing programmers

                                Comment

                                Working...
                                X