I have been lurking in this thread for a very long time…it’s about time i posted
The idea is that you should use technology you’re the most comfortable/productive with, not the “newest/shiniest/most popular” one.
[/]
I agree with this.
However this
After significant amount of C++ experience, C# is extremely unpleasant to work with. C# is limiting and occasionally tries to babysit you. For example:
- because it is garbage collected, you can’t actually delete any object that is not GameObject/unity object based. You set it to null, and politely wait for GC to pick it up someday.
- However, unity does not garbage collect scene objects.
- But because it is technically garbage collected you can’t apply RAII and implement automatic object destructions and trigger object destruction when variable goes out of scope. Anything that HAS to be destructible is used in very awkward way through IDisposable interface.
- No multiple inheritance.
- No protected inheritance. Interfaces are inheritance.
- No const parameters in functions. No const references.
- No const functions. I wanna ensure that this function can’t change my class instance, dammit.
- Any attempt to use value type and ref parameters will result in huge amount of pain. Usually language will demand that you initialize every single field even if you’re not using it.
- I believe there’s trouble if you’ll try to pass out parameter to another function with “out” parameter. You’ll need to create temporary.
- Type deduction for generics is inferior.
- No type aliases or typedefs. Having to type “TMap<String, TList<MyStructureStorageType>>” every time is great.
- “var” does not work in class declaration. “TMap<String, TList<MyStructureStorageType>> myMap = new TMap<String, TList,MyStructureStoragetype>>();”! Gee, thanks. Always dreamed about having to do that dozen times per any new complex class.
- No macros means you can’t collapse those pesky getter/setter function into one-liners and have to type out every repeating pattern, increasing chance of human error and typo.
- You’ll have to use Unity serializer, but it does not support generic types. At all. You’ll need to inherit class from generic type container, then mark it as [System.Serializable].
- Everything is visible from anywhere. No visibility control. If you add anything to namespace, it will be visible from every other file as part of that namespace. C++ allows precise visibility control with its .h/.cpp scheme. Anything that is in *.cpp is by default pretty much invisibile from any other cpp, which reduces namespace pollution.
- Defining object equivalence by implementing Equals() is “FUN”. There’s no clear standard on whether operator== means equivalence by reference equivalence or value equivalence so everybody uses whatever they want.
[/]
I completely disagree, C# and C++ are two different beasts. How can C# be so unpleasant to work with after using C++ ? Why ? because of what you posted ? Well i could make a fairly good argument to use C# and not C++, because of those reasons, it would take awhile and im at work so I’m not going to waste my time, but just because those things seem limiting, in actuality they aren’t as limiting as you think. I use both in my day job, and both have their place, C++ isn’t inherently better than C#, and neither is C# inherently better than C++. It’s a completely different beast is all. Most of your complaints are things that the creators literally choose by design. You can’t complain about the design of a language just because it doesn’t make sense for you. C# wasn’t even really meant for consumption it was made specifically to be economical towards memory and processing power for a specific company, and was never meant to even directly or indirectly compete with C. I mean the creator of C# himself said that the CLR was driven by the flaws of major languages like C++, java, smalltalk. Which in turn drove the design of C# itself.
If you were to base a comparison of C# and C++ purely on modern features. C# wins.
I don’t hear you complaining about C++'s archaic compilation model, all the inherited legacy C garbage, classes vs structs, new keyword, exceptions or the ghastly multiple inheritance implementation, complexity added when operator overloading, template syntax, complicated atomics, c++ never protecting you from yourself…I mean there are allot of problems which make C++ problematic.
That’s just a few that comes to mind, not to mention that there are engine-specific quirks, like not having access to the serializer out of the box (you’ll need to download unmainatained third party script or buy it for $20 from asset store).
[/]
A Serializer isn’t necessary for game dev, you have to realize what you’re using, a game engine. There are going to be allot of things you don’t have. That’s why things like an asset store exist. Also, on the same note, in response to you saying you can never really know if a product from the asset store has a bug, well that’s the same for any program, is it not ? I mean UE4 has bugs. Your games, my games have bugs. yes all software has bugs. you paid for the assets in its current state, you did not pay for something claiming to be 100% bug free.
The ONLY good feature C# has is reflection (You’ll hear “don’t use reflection, it is slow!” all the time) and apparently ability to construct functions at runtime in the very awkward way using Expressions namespace. And that’s it. Those two advantages are outweighted by huge number of issues.
[/]
To say the only good feature that C# has is reflection is a bold statement to say. Many many people will disagree with that.