[Tryparse]

I'm pretty new to programming (learned basic C++ 11 years ago, & learned basic C# & VB this past year), and from what I've read on here it appears that C++ is one of the more popular game programming languages. I haven't learned much about the above languages outside of how to use them to create simple programs (database connections are pretty much the most advanced thing I've learned so far). So I have a few questions:

What can C++ do that C# can't?
What can C++ do that VB can't?
What are the fundamental differences between VB & C#? (first person to say syntax gets one of those annoying facepalm ascii posts)

[Oler1s]

I am answering your questions on an engineering basis; I'm not answering on a pedantic language comparison, which is probably not what you want.

Quote

What can C++ do that C# can't?

I'll rephrase this as "what do you get from C++ that you cannot from C#". The biggest motivator is library usage. Like any engineering disciple, it's bad to reinvent. Reinvention costs resources, of which there is only a finite amount. So what we have is libraries of code. That is reusable code. C and C++ have been around for a long long time, and a large number of libraries are exposed in these two languages. Since it's possible to use C libraries in C++ code, that means a C++ programmer has available to him a large number of libraries. Of particular concern are game engines and commercial grade libraries, which allow usage from C++.

You can also think of library requirements as a limitation. Typically games make use of OS provided APIs, which are exposed in C and in C++. So games which use such exposed functionality (for example DirectX, or OpenGL), are basically restricted to those languages.

There are other concerns. Typically, high performance software requires being able to handle very particular concerns like very controlled memory allocation and deallocation, specific data alignment, and very close to OS concerns like thread management. This is possible for various reasons in C++, but not thorugh abstractions like the .NET platform and any .NET language, and so on.

Quote

What can C++ do that VB can't?

The same applies.

Quote

What are the fundamental differences between VB & C#? (first person to say syntax gets one of those annoying facepalm ascii posts)

It is syntax. Both are .NET languages. Technically, the functionality you have access to is not complete. The CLR supports more than what each langauge provides. Generally, though, it comes down to syntax.

I hope you don't, like many others, take this information as a sign that you must program in C++ to make games. In fact, the movement to C++ by beginners flies in the face of programming trends. The trend is to move towards higher level abstractions, not lower.

[Tryparse]

So if I'm understanding you and some other posts correctly, it's really just a matter of available, tried-and-true code, and C++'s direct access to hardware vs. .NET's middleman? And if so, may one safely assume that eventually .NET languages will achieve the same functionality as C++?

Are you saying that there's really no functional difference between VB & C#? They can both accomplish the same tasks, and therefore usage is a matter of preference? If so, does this apply to Visual C++ as well?

Oler1s, on 13 May 2010 - 10:06 PM, said:

I hope you don't, like many others, take this information as a sign that you must program in C++ to make games. In fact, the movement to C++ by beginners flies in the face of programming trends. The trend is to move towards higher level abstractions, not lower.

The college I attend doesn't teach C++, and I thought that I might be at a disadvantage going out into the workforce not knowing it very well. Are you suggesting that my time would be better spent expanding my knowledge of VB/C#/Java/SQL/etc. than learning C++?

[SixOfEleven]

Tryparse, on 14 May 2010 - 01:45 AM, said:

So if I'm understanding you and some other posts correctly, it's really just a matter of available, tried-and-true code, and C++'s direct access to hardware vs. .NET's middleman? And if so, may one safely assume that eventually .NET languages will achieve the same functionality as C++?

C++ is one of the few languages that compiles to native code compared to other languages that compile into an intermediate language that is interpretted, C#, VB.NET, Java. This compiling to native code gives C++ advantages over managed languages such as direct access to hardware, being closer to the OS having it run faster(up for debate by many), and I guess because it has been around the longest there is a large code base out there. .NET language will never achieve what native code can. They will always require the .NET framework to be installed on the computer running the application, as well as the correct version of the .NET framework. If an application targets .NET 3.5 and the computer has .NET 2.0 the computer must upgrade to .NET 3.5 for the application to run. If you take a C++ application to different Windows computer it will run almost always, that is if it only uses libraries that are part of the C++ standard. If the program only uses libraries that are part of the standard the same code can be compiled and run on any platform.

Quote

Are you saying that there's really no functional difference between VB & C#? They can both accomplish the same tasks, and therefore usage is a matter of preference? If so, does this apply to Visual C++ as well?

There is really no difference between .NET languages other than syntax. That includes, VB.NET, C#, managed C++, and now F#. It ends up being a matter of preference because they all compile to the same intermediate language and use the same libraries. I prefer the syntax of C# from my background but could just as easily write the same programs using VB.NET. I just find VB.NET more verbose and badly designed. That is of course my preference, nothing wrong with VB.NET.

Quote

The college I attend doesn't teach C++, and I thought that I might be at a disadvantage going out into the workforce not knowing it very well. Are you suggesting that my time would be better spent expanding my knowledge of VB/C#/Java/SQL/etc. than learning C++?

I wouldn't say that you will be at a disadvantage but knowing C++ would be helpful. Knowing higher level language like VB/C#/Java is just as useful as many companies are migrating to .NET for many reasons.

[Oler1s]

Quote

it's really just a matter of available, tried-and-true code

That's a major factor. C++ currently remains the best point for high performance work. I consider this to be a niche game. Many people aren't even at the level of expertise to really play in this field (not in a derogatory sense, it's just how it is given finite human time). And so APIs will continue to be exposed in C++. C++ isn't a stationary language. It gets updated too, and the latest revisions are adding more to the standard library and higher level abstractions. As I noted in my previous post, programmers are concerned about libraries and want higher level abstractions, precisely what the latest revisions in C++ are trying to achieve.

Quote

And if so, may one safely assume that eventually .NET languages will achieve the same functionality as C++?

No programmer assumes the future. No one has a crystal ball. I wouldn't make that bet, though, for various reasons. I do expect more fragmentation in the future though. That is, programs in the future (and already right now) aren't restricted to the PC. Mobile devices or computing resources taken from the NEt (i.e. cloud) are the hot things. Good abstractions from hardware is really important. For various reasons, I think as more and more programmers are confronted with their ability to handle different hardware and runtime environments, they'll pick something that abstracts out the details better than C++.

Quote

Are you saying that there's really no functional difference between VB & C#? They can both accomplish the same tasks, and therefore usage is a matter of preference?

Yes, for all practical discussions. If you look at MSDN documentation and samples, you have code examples in both C# and VB. You're not running into C# only sections or VB only sections.

Quote

If so, does this apply to Visual C++ as well?

VC++ is a compiler...and I'm not sure what you're comparing. If you could expand on this question, I might able to provide an answer.

Quote

The college I attend doesn't teach C++, and I thought that I might be at a disadvantage going out into the workforce not knowing it very well.

Maybe. It depends on what you're doing. For entering the games industry, yes, it matters. Even thoughyou might not actually program in C++ in the company, not knowing C++ would raise eyebrows, I think.

I don't really expect colleges to teach languages. That's something you can acquire on your own with time. In fact, that's what you need to do. Sit down with books and practice. A course can't really add to this. What they should focus on is theory and problem solving. While languages and technologies change, underlying theory and problem solving hasn't. Problem solving has not been abstracted away in programming. Fundamentally, programming is problem solving, and it hasn't changed one bit from, say, 40 years ago. That underlying attitude and mentalty is ever constant. And so that's what needs to be taught in college. The changing parts you learn on your own.

Quote

Are you suggesting that my time would be better spent expanding my knowledge of VB/C#/Java/SQL/etc. than learning C++?

I think your time is best spent actually tackling problems. I don't usually failures of knowledge. I see failures to engage in proper problem solving and to have a correct attitude about problems.

Complaints about knowledge are a sign of a beginner. You're not a useful programmer if all you do is solve problems with known solutions. That's called reinventing. No one cares about a guy that reinvents the wheel or the lightbulb. Great job! Moving on...

What people want is someone who can solve problems without known solutions. As in, you're always operating from a position of not enough knowledge. The only way to get good at this is to take on problems by yourself.