@, that’s a pretty bad post you wrote and it’s in very bad taste.
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 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 with Unity you have to pay extra for a .
[edit] Funny just noticed a thread where Epic already answered this question
[=;18270]
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 ( that have AAA reviews by definition? :p), and there JUST one person who works on JavaScript support for , 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.
@: 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”…
[=nlaq;18180]
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.
[=nlaq;18180]
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/05/c-vs-c-performance.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/212856/Head-to-head-benchmark-Csharp-vs-NET
[=nlaq;18180]
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.
[=nlaq;18180]
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.
[=nlaq;18180]
Safety Features:
- Array bounds checking
[/]
Identical feature: C++ boost:array (superior because you can optionally disable the checks when you want to “go fast”)
[=nlaq;18180]
- 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”.
[=nlaq;18180]
- 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?
[=nlaq;18180]
- No raw/dangling pointers
[/]
As a type safety feature I agree.
[=nlaq;18180]
- 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:
[=nlaq;18180]
- Interfaces
[/]
C# interfaces exist simply to fill in the gap because you don’t have multiple inheritance.
[=nlaq;18180]
- Better enums
[/]
Agreed.
[=nlaq;18180]
- 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:
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.
}
[=nlaq;18180]
- 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:
[=nlaq;18180]
- 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.
[=nlaq;18180]
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.
[=nlaq;18180]
Productivity Features:
- Much, much (much much much much) faster compile times
- Visual '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.
[=nlaq;18180]
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.
[=;18285]
One thing I don’t see people mentioning, I like how I can use Visual 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 with Unity you have to pay extra for a .
[/]
I don’t know what you exactly mean, but debugging works without any , you actully needed to see where your code crashes
Yeah I think you misunderstood my post
[edit] Here they discuss what I refer to
[=eblade;18136]
- 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.
[=Serapth;18164]
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.
[=Serapth;18164]
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.
[=Serapth;18164]
Would you hire a contractor that thought a hammer was the solution to every problem?
[/]
Please spare me those silly analogies.
[=eblade;18203]
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.
[=MonsOlympus;18200]
(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 ).
[=MonsOlympus;18200]
which Im not complaining about by the way!
[/]
So what is it that you’re actually complaining about?
[=;18349]
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
[=;18436]
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 Google Publishes C++, Go, Java and Scala Performance Benchmarks - ReadWrite,
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.
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 , 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.
[=;18371]
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 
[=;18286]
@: 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”…
[/]
Whoops! Turns we know each other from Unity forums. Small world, small world… 
[=;18441]
I genuinely don’t want to hear about python, javascript, java nor c# where games (AAA games) are involved.
Go here Google Publishes C++, Go, Java and Scala Performance Benchmarks - ReadWrite,
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.
[/]
Well main reason why they did that was to let users to play with the code and “mod” the game without needs of giving out header files, i reamber hearing developer interviews back then saying you can modify game whatever you like thanks to python. Same goes with UnrealScript, in UE1 editor even have text editor for them 
[=;18441]
I genuinely don’t want to hear about python, javascript, java nor c# where games (AAA games) are involved.
Go here Google Publishes C++, Go, Java and Scala Performance Benchmarks - ReadWrite,
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.
[/]
Not sure why you have such a high disdain for other languages. Normally, your game logic will literally run circles around a render frame. Sometimes your game thread can make multiple game logic passes before the render thread even has a chance to consume the frame
So this is how things work in a few game engines I’ve seen that use a multithreaded renderer. There are normally 2 approaches (trying to stay brief no one needs a wall of text)
Approach 1:
Game/Main thread produces the logic for the frame and submits this to the multithreaded renderer. After this frame has been submitted, it does a lot of busy work. Like run physics jobs in parallel, animation jobs for next frame, etc. Afterwards, it may stop and wait for the render thread to come back
Approach 2:
Game/Main thread runs parallel with the render thread. Game thread runs through logic for the frame and then submits this data when it’s done. But unlike approach #1, it doesn’t stop and wait on render thread. It keeps going, working on the next frame. It is possible render thread will ‘miss’ a game frame. So to present this case the Game thread is busy making sure all the data he is going to pass on contains complete information, tricking render thread into thinking he has a ‘complete’ up-to-date frame copy
In both cases, your game thread is so fast, he is waiting on rendering. Render thread is often busy computing shadows (Cascade shadow maps, etc), running post effects, running the deferred renderer, etc.
My point is that in most engines you usually have plenty of CPU left for a high level language.
Where problems creep up in AAA games or rather, porting these games, is getting that game to run on a lower target. This is when you might look at your scripts with a scope.
My last title I worked on it was running at 60 fps. I think the game had 2 script VMs running and we were still GPU bound. Not CPU bound. We didn’t have to change not a single script when we down-ported it to other platforms
So my main point is for sure you have plenty of bandwidth for other languages.
[edit] I just made a very broad statement there. And of course I only refer to using these other languages for Game logic. Plus, physics was run on another thread. On our target platforms, we had at least 4 cores available to run jobs and at least 3 you have 100% control over without the ‘system OS’ interrupting
(Sorry forums for all the posts but I felt my other post was too long winded and didn’t even answer his question)
[=;18441]
Why would anyone choose anything but C++ for AAA game development is beyond me.
[/]
Ok, another try to see if we can find some middle ground here.
Usually you go with a scripting language because you have a Designer/Artist/VFX/Audio sitting there and they usually outnumber the programmers by a wide margin. Plus, their salaries are lower (see game industry surveys).
What to do? You have a 100+ and an army of non-programmers. So you toss them into your codebase. But wait- if you let these ‘newbies’ into your C++ codebase you’ve just unleashed HELL. Memory stomps, memory overruns, etc. Nightmare! And no one really does code reviews like they should to begin with.
So you give them a scripting language. And to encourage their productivity you make it a rapid prototyping language.
At one company I worked it, it got so bad at one point C++ was taking like 20 mins to compile even with that popular Agent uses (Incredibuild). It was our fault. But it happened. Eventually we got SSDs and they got it down to 5mins or less.
Back then I did mostly gameplay programming so I would do all my hacks in the scripting language too. After all, virtually no compile time > 5 mins
Granted, I am seeing a shift now where a lot of smaller studios ((50<) are dumping scripting languages in favor of visual scripting. I think the Designers were happier when they had both scripting and visual scripting. This gave them full control.
But I digress. I gave you my point of view. I don’t expect to change your point of view. But I think this worked really well. And it’s surprising. You’ll see even Artists scripting little things if you let them
[=;18489]
(Sorry forums for all the posts but I felt my other post was too long winded and didn’t even answer his question)
Ok, another try to see if we can find some middle ground here.
Usually you go with a scripting language because you have a Designer/Artist/VFX/Audio sitting there and they usually outnumber the programmers by a wide margin. Plus, their salaries are lower (see game industry surveys).
What to do? You have a 100+ and an army of non-programmers. So you toss them into your codebase. But wait- if you let these ‘newbies’ into your C++ codebase you’ve just unleashed HELL. Memory stomps, memory overruns, etc. Nightmare! And no one really does code reviews like they should to begin with.
So you give them a scripting language. And to encourage their productivity you make it a rapid prototyping language.
At one company I worked it, it got so bad at one point C++ was taking like 20 mins to compile even with that popular Agent uses (Incredibuild). It was our fault. But it happened. Eventually we got SSDs and they got it down to 5mins or less.
Back then I did mostly gameplay programming so I would do all my hacks in the scripting language too. After all, virtually no compile time > 5 mins
Granted, I am seeing a shift now where a lot of smaller studios ((50<) are dumping scripting languages in favor of visual scripting. I think the Designers were happier when they had both scripting and visual scripting. This gave them full control.
But I digress. I gave you my point of view. I don’t expect to change your point of view. But I think this worked really well. And it’s surprising. You’ll see even Artists scripting little things if you let them
[/]
Actully most artists usally don’t understand scripting languages either and they searching for programer, for them UnrealScript looks same as “bad” as C++ visual scripting helps them out