Will it be C++ the preferred game dev language in 3 years from now?

Started by
54 comments, last by Satharis 10 years, 6 months ago

The language in C# is really meaningless. It's more about the .NET framework than anything else.

I disagree. C# as a language (especially the later versions) has a lot of features that aren't in C++.

Maybe "meaningless" is a too harsh word. But I'm sure the productivity boost of C#/.net, compared to C++, comes from the framework, and to a lesser degree, from the better support in the IDE. The language, well... You can do almost anything in any of the two languages, sometimes C++, sometimes C# is a better fit.

Currently I don't know of any C++ framework that comes close to .net, regarding feature coverage and consistency.

Advertisement

Currently I don't know of any C++ framework that comes close to .net, regarding feature coverage and consistency.

This is what baffles me. I really like C++ but because the creators aren't in the business of making a framework for it I think it hurts the popularity of the language. Sure there are lots of libraries for it but they are all scattered around, and including all of them to get the same functionality that .NET has would be a nightmare. Libraries like Boost are often looked at as bloated.

I do wish MS would have just created .NET for C++ (because 90% of .NET could be in C++ and basically coded the same way) but I guess the lack of reflection in C++ was one of the main reasons to not use it. I know they offer C++/CLI but that's not the same.

I think C++ will stay. C++ is really like a sports car using manual transmission as you can always manage your memory without tricks like in Java, C#, or any other languages that uses automatic garbage collection which causes trouble on resource-intensive tasks. Since you're asking about game dev, it's a yes for me.

The language in C# is really meaningless. It's more about the .NET framework than anything else.

I disagree. C# as a language (especially the later versions) has a lot of features that aren't in C++.

Maybe "meaningless" is a too harsh word. But I'm sure the productivity boost of C#/.net, compared to C++, comes from the framework, and to a lesser degree, from the better support in the IDE. The language, well... You can do almost anything in any of the two languages, sometimes C++, sometimes C# is a better fit.

Currently I don't know of any C++ framework that comes close to .net, regarding feature coverage and consistency.

language features such as LINQ, reflection, garbage collection, synchronized methods, properties, etc are pretty nice for productivity imo.

as for C++ frameworks that come close to .Net i would recommend looking at QT (it also adds signals and slots through a meta object compiler which makes GUI programming in C++ slightly less painful)

[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

language features such as LINQ, reflection, garbage collection, synchronized methods, properties, etc are pretty nice for productivity imo.

Isn't reflection & garbage collection really part of the framework instead of the C# language?

language features such as LINQ, reflection, garbage collection, synchronized methods, properties, etc are pretty nice for productivity imo.

Isn't reflection & garbage collection really part of the framework instead of the C# language?

Yes and no.

The language uses a garbage collection system as part of its memory management. The .net framework includes classes and functions that let you manipulate the garbage collector.

The language specifies the exposure of metadata. The .net framework includes classes and functions that let you make use of the metadata for reflection.

I've used C# in tools since about 2005, and I've been writing internal game code in C# for over three years. When all my C# usage was in the tools I could see there was a huge productivity gain, but since the tools rely on the .net framework for many calls I could not be certain where the productivity boost was. Since the game engine provides most of the functionality and only uses C# for object scripting, about the only things I use from the framework are the generic containers and the very occasional reflection. There is a huge productivity difference between working in game's C# code and the game's C++ code, and since I don't rely on the .net framework for most features, I can assure you the performance difference is not coming from the framework libraries alone. The language design means much less effort and mental work to write software.

The language uses a garbage collection system as part of its memory management.

And isn't that GC system part of the .NET VM? I think it's more the other way around where the language is using the .NET VM garbage collection system which would make it not part of the language itself right? ie. could one make Garbage Collection work without the .NET VM? No. Could one make adding 2 numbers together without the VM? Yes. So addition is part of the language itself but GC isn't.

This is why I say C# is meaningless. It's nothing without the .NET framework which is the real power behind it all. All those features you list I can do in VB.NET also so that would put VB.NET and C# as equal in functionality, but I'm sure if I made that comparison some people's heads would explode in anger because C# is so much more amazing... smile.png

Anyway, OP, I think C++ is a good thing to know, but also learn scripting languages and .NET because it's sweet :)

And isn't that GC system part of the .NET VM? I think it's more the other way around where the language is using the .NET VM garbage collection system which would make it not part of the language itself right? ie. could one make Garbage Collection work without the .NET VM? No. Could one make adding 2 numbers together without the VM? Yes. So addition is part of the language itself but GC isn't.

This is why I say C# is meaningless. It's nothing without the .NET framework which is the real power behind it all. All those features you list I can do in VB.NET also so that would put VB.NET and C# as equal in functionality, but I'm sure if I made that comparison some people's heads would explode in anger smile.png

You are confusing the framework with the virtual machine.

The CLR (Common Language Runtime) virtual machine has pretty much nothing to do with the framework running on top of it. Nor, really, the programming languages running on it (as you point out, both the CLR and Mono virtual machines support C#, Visual Basic, F#, etc).

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

There are many parts.

There is the language. The language says that a garbage collecting memory manager is used. When you call new an object is created, and when it has no more references the object is cleaned up. The details of how that gets implemented internally is left up to the implementation.

Then there is the compiler and execution environment implementation. Currently there are two major implementations, MS and Mono. The language gets compiled into the virtual machine's intermediate language, but that is not a requirement. It could be compiled to any target, even directly to machine code if you wanted to build a compiler for that. Just like any compiled code, the details of how that works are up to the implementation. It could be part of a virtual machine and rely on the virtual machine to allocate it. It could be done through a third-party library behind the scenes. It could be managed in raw machine code. That is not specified as part of the language, but is part of the implementation.

The .net framework has a huge collection of classes and functions. Some of those functions are designed to control Microsoft's runtime environment, including the garbage collector. This is also not part of the C# language, but is a piece of library functionality. These libraries may or not be present, and are not required by the language.

It is not so different from any language, including C++.

I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.

This topic is closed to new replies.

Advertisement