A beginner starting out is going to hit several of these things early on. "Why do I get link errors from this variable in my header? Why does the object I passed into a function not get changed by that function? Why does my name print out with weird characters in it or appear to be too long? Why does it crash when I copy this object then delete the first one?" All the other problems will turn up to bite them sooner or later. And they don't know which bits are 'extra' and which bits are not, because that's what being a beginner means. There's no need for a novice to be put through that as a first language. C# (or even better, Python) lets them focus on the basics, and they can move onto more complex things later.

(As for "UE4 even provides Garbage Collection in the c++ code" - come on, you know full well that only applies to certain objects which you've marked up with the UObject/UPROPERTY stuff - significant extra complexity, for a feature that doesn't apply to everything.)

C# has boxed structs that are passed by value, not by reference. XNA and Unity Vector3 is an example. Perhaps you simply prefer the ref / out syntax compared to C++'s &?

I wouldn't call it boxed, just passed by value. Boxing generally means to cast a value to a reference, like an int to object or a struct to an interface.

Almost all of these issues are actually language agnostic

They're agnostic in terms of it being possible to experience these in several languages. They are not agnostic in the sense of how likely you are to experience them, and how hard they are to address.

"Why does the object I passed into a function not get changed by that function?"

C# has boxed structs that are passed by value, not by reference. XNA and Unity Vector3 is an example.

These objects are the exception, used in situations where you expect them to be value types.

In C++ everything is passed by value by default, so you get bonus copies where they're not expected. This hits pretty much every developer at some point, leading to them coming here, then they end up in a conversation like:

• the object's getting copied, so you need the "rule of 3"
• actually he doesn't want to copy it, so use a reference
• some of us prefer to use pointer for objects we intend to alter, and const reference for the others
• these days it's better to use std::shared anyway
• really you need the "rule of 5" for efficient move operations
• he doesn't care about move operations because he doesn't need to copy it
• he'll need to copy it at some point so he should implement them anyway even if this time it should be a reference
• really he needs the "rule of 0"
• aargh

I've seen it again and again on these forums. It doesn't happen on the Unity forums, because C# is simpler. There is a much smaller quantity of "why did the original vector not change" and that's it.

"Why does it crash when I copy this object then delete the first one?"

Copying an object in C# and then deleting the native code underneath (i.e In Unity keeping a C# reference but destroying the texture) has exactly the same effect.

Probably, but it's hard to do that by accident. In C++ this often gets done for you, because copying is an intrinsic part of treating everything as a value.

Why does my name print out with weird characters in it or appear to be too long?"

C++ std::string has solved this many years ago.

I don't know which std::string you're using that understands UTF-8, but it's not the one in the standard library. Not without bolting on other functionality that breaks most of the member functions.

As for link errors in C++ caused by entries in header files, This one is pretty unlikely if writing C++

It's incredibly common. So much so that I wrote an article about it 15 years ago which still gets consulted now. Beginners don't know the difference between const and static const, or why a function in a header needs to be inline, or what the magic include guards are for.

There's no need for a novice to be put through that as a first language. C# (or even better, Python) lets them focus on the basics, and they can move onto more complex things later.

Thats the problem. They don't move on though do they? They stick with C#, go straight to Unity and never try anything else.

(a) If Unity solves their problem of allowing them to make games, great. I don't see why you think there's a rule that they need to become C++ programmers as the ultimate goal.
(b) I don't see any evidence for your claim anyway. Lots of us started on languages other than C++. I started with BASIC, then Pascal, and C++ after that.

It was the same with XNA a couple of years ago before Microsoft dropped it. Suddenly no more marketing drive and the open-source MonoGame certainly doesn't have the same number of users does it?

There are a ton of other factors there that have nothing to do with marketing, such as Unity being a more effective alternative that ships on far more platforms (crucially including the web).

My point is simply the fact that Unity is widely used over equally capable alternatives because it is incredibly well marketed vs alternatives such as UE4.

And my point is that Unity is widely used over alternatives becase they are either (a) less capable, (b) more complex, or (c) more expensive. UE4 is more capable but also more complex and more expensive. This makes it worse for beginners. Yes, there are some UE4 features that are great (blueprints, data tables, behaviour trees, comprehensive animation tools) but at some point you almost always have to drop down to writing some code, and as I opened with, C# is simpler than C++ and the Unity object model is simpler than the UE4 object model.

Beginners do not care about UTF-8. This is not relevant.

Nobody cares about UTF-8 but lots of people like to be able to use their own language in their text. Unity lets you use a standard C# 'string' and it just works. UE4 gives you char*, std::string, FString, FName, TEXT() macros, and expects you to know the difference.

But C and C++ (along with SDL) works on far more platforms than both XNA and Unity (including obviously web browsers with *and* without WebGL support). Why is this not a popular avenue then even for 2D games?

Because here you're comparing a low level framework to a full engine. It's like asking why people prefer bars to home-brewing kits. Both can get you drunk but one requires a lot more work. Unity provides a ton of extra functionality beyond what SDL can do, as well as giving you simple build and packaging processes.

I've been on these forums 17 years, and if anything, C++ is too popular here. People here have traditionally picked that language with SDL and SFML as a first choice. And that's why they're often here asking C++ questions about which type of smart pointer to use or how they should handle returning vectors of things or just trying to understand the language as a whole, instead of actually finishing their game. Because finishing a game is hard when the language you use is complex.

Unreal Engine 4 also exports to web browser using the same technique (Do many C#/Unity developers even know this?).

It does now, but Unity had their web plugin about, what, 8 years ago? UE4 hit the web under 3 years ago, and wasn't free to use until 2 years ago. Unity was already massive by then. That's not about marketing, it's about Unity providing that capability to indies for free about half a decade before Epic did, and making it accessible to use, at the cost of some power.

I'm not 100% sure why this topic is causing me to want to respond and express my opinions so much ... but ... here goes:

Background - I am not currently a game programmer and have not been a game programmer for over 15 years. Back then I used ASM (3 months), then ANSI C (9 months), then C++ (3 years) to create embedded gambling games (like quad 6 lotto, blackjack, etc) ... my last game project was a Direct X 5 2D 8-line slot machine running on an embedded intel i815 chip around 2000. I then worked in embedded audio using C++ for 3 years. And then I sold out / went corporate and started writing database backed, server based C# web applications - which I have done very successfully for about 12 years. (I've also used perl, ruby, lua, javascript and others). I have played with Unity, XNA/monogame, SDL, tao and about 5 other pretty much dead libraries through the years.

* There is no right or wrong language (except ones almost noone is using - where you can't find help)

* There is no right or wrong library or platform (except ones that are no longer supported)

HOWEVER, NONE of the current languages, NOR libraries/engines, NOR game types are even REMOTELY like each other when you think about the following:

* Community culture

* Initial experience when not having a mentor

* Availability of online materials and support

* Availability of print material and support

* Most likely directions to take for "successful" experiences

* Number of hours to expect to spend before you know you are making progress or perhaps should change direction

* Ability to get something satisfying done quickly if you want to make PLAYABLE games

* Ability to get something satisfying done relatively quickly if you want to learn to be a "real programmer" (TM)

* Ability to translate the beginner experiences and learning forward into real jobs

* Ability to use the early experiences to contribute meaningfully to indie or beginner unpaid projects

* Ability to translate your experience forward onto other languages or platforms

* Ability to translate your experience forward onto a long term career as a professional software developer (not necessarily making games)

And by way of specifics:

* C# and Javascript are WAY WAY easier languages for starting programming in than C++ (although both are far more complex now than they were 5-10 years ago)

* C# and Javascript are the 2 languages most likely to get a junior programmer hired as a professional programmer, followed by Java and Objective-C (in nearly any industry except games)

* C++ is far and away the most dominant language used by the software and engine developers for AAA titles, C# with Unity is working to close the gap

* Mobile games are primarily built in either native Objective-C (ios) or Java (android) or on javascript based cross-platform engines.

* C# and Java are the 2 most dominant languages for colleges teaching computer science, and are very similar. Both were very simple 10 years ago, but both have become quite complex over the years. Javascript is the 3rd most common CS degree language.

* C and C++ are 2 of the only remaining languages that are still in heavy use that normally require manual memory management (although smart pointers do exist) and teach good low-level programming fundamentals if you want to do things like write device drivers, graphics or physics engines, operating systems, IoT devices, etc.

* Almost no-one outside of games or embedded systems pays anyone to program in C or C++ below the Senior Developer level of experience (in other words, its hard to get started in these career paths, but you can make great money once you are a proven expert).

* Anything you are doing that you are having fun doing, while also learning something, is always the "right" way to do it ... and what is "fun" is impossible for someone to predict for you.

* I recommend C# if you want to program (in general) - or if you want to make games quickly and not take years building "engines". I recommend C++ if you have more fun with the idea of programming than in the completion of actual programs and would like to tinker with core things until you understand them deeply.

* I recommend things like XNA/monogame, SDL, or other simple frameworks if you want to mess with simple 2D sprites.

* I recommend Unity if you want to work with 3D stuff in the next 2-3 years (cause 3D game engines are CRAZY HARD and C# with Unity is just about the easiest to get started with).

Good Luck

How come nobody is suggesting C++ and UE4? Is Unity really that much easier?

Its an annoying one but (due to Microsoft's marketing) most people tend to advise people to learn C# as their first language which pretty much shoves them straight into Unity and they never get to experience anything else.

I would say that Unity (The company) has spent many many more $ on marketing their product too than all other middleware companies combined.

And again, Microsoft has in the past spent much much more $ on marketing their product (C# & .NET) than C++ has ever had (which unlike .NET or Java obviously doesn't actually belong to any single company so has noone to market it).

So long story short. Unity and C# is a branding exercise towards "prosumers".

Bullshit. C++ is just a lot more complex than C#. Marketing has nothing to do with it.

C++ gives you:

• 5 different types of cast.
• 4 different types of object constructor (default, parameterised, copy, move) and a 5th way of invoking them (copy constructor via assignment )
• 2 different types of built-in object reference, plus 3 types of standard library reference (plus one more that is deprecated). Also: pointers to references, references to pointers...
• a string type that needs C-style functions, pointer-style semantics, and isn't usable for anything except American English (char*)
• a string type that can only handle UTF-8 if you don't use most of its functionality (std::string)
• a system clock that doesn't understand UTC (std::chrono)
• the preprocessor system and the need to understand it for #includes, and how that ties into "compilation units" etc
• the erase-remove idiom, and other oddities of the 'algorithm-first' approach to containers
• the "most vexing parse"
• no garbage collection, but maybe some ref-counting if you used the right reference type

Indeed. C++ is a mess. But I would point out a problem with your list:

Strings are not a core language feature. If you want to count them in anyway there are wide strings on linux and UTF-16 on windows. So I'm a little confused why you would say "a string type that can only handle UTF-8" when that's patently false.

But yes, its a pretty complicated language. And C++17 is coming soon.

Full internationalizable strings are a core language feature. The fact that C and C++ pretend that they aren't - while providing built-in functionality for ASCII - is just another point against them. Pretty much every other language provides, out of the box, a way to handle international text. C#, Python, Java, VB.Net, Rust all do. Even Javascript has something relatively usable.

The UTF-8 point I made applies equally well to 16-bit strings like std::wstring; the fact is that the std::basic_string wrapper type is not Unicode-aware and is incapable of providing meaningful results without external help. UTF-16 is a variable-length encoding just like UTF-8 is, just that the wrong code is more likely to appear to be working, right up until you encounter a code point large enough to use a surrogate pair, like an emoji.