Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sindai]

How would C++ eliminate the "fun" with switch statements?

In many cases if you are doing object-oriented design (which you actually can in both C and C++, though C++ makes it simpler by supporting objects directly), you will find that switch statements can be replaced by using polymorphism with objects.

Of course, this doesn't go for every switch statement by any means.

[Nexii Malthus]

I would personally recommend learning C# for modern game development. Soon nearly all studios will have their main programming converted from C++ to C#. It saves a hell a lot of time and has many features that C++ doesn't have. C++ has only been the programmer's choice due to its brutally efficient speed, but the features available in C# have a great advantage over C++ since it the development time spent on programming is halved and so one can put more time into the gameplay than implementation.

[Blacken]

I would personally recommend learning C# for modern game development. Soon nearly all studios will have their main programming converted from C++ to C#. It saves a hell a lot of time and has many features that C++ doesn't have. C++ has only been the programmer's choice due to its brutally efficient speed, but the features available in C# have a great advantage over C++ since it the development time spent on programming is halved and so one can put more time into the gameplay than implementation.

C# is nice (and my language of choice), but to think that they're going to switch en masse is a little silly.

C# is a better language than C++. It is conceptually cleaner and offers options that C++ does not (closures, lambdas, etc.)--but it's slower. Mind you, C# is a good glue language for interoperating between different native code libraries, but therein lies the problem: C# relies on native code libraries to do almost anything game-related. DirectX is C++. SDL is C. OpenGL libraries, likewise C. Physics libraries? Depends, usually C++. Why? Because C# is slower. Significantly so in some cases, such as when doing matrix computations.

The argument that C# has more features (I'm assuming you mean the BCL and other .NET libraries) is a misleading one. .NET has more features than just C++ and the STL, but that is a far cry from the full picture--there's Boost and there are countless libraries for C++ development, most permissively licensed.

C++ also has considerable inertia. It's what developers know. It's what they (currently) like. And while it's making inroads in tools dev, C++ be the primary language for game development in the foreseeable future because the underlying engine is most critical. Good programmers can write good code in C++; bad programmers (and there are a lot of them in the game industry, don't kid yourself) can write bad C#.

That said, it is a great language for learning. I use it to write games, in fact. But to say that the mainstream will forego C++ for C# is deluded.

[lanael]

Ah great a programming language thread !

Nobody mentioned the D programming language ( http://www.digitalmars.com/d ) ?!   
* Advantages : modern features ( somewhat like java and C# ) and compiled ! ( and compiling at the speed of light. at least. )
* Disadvantages : Still not very well known and in continuous development ( still, it's very usable for years )

I think that the language choice for a game depends on:
*) the type of game you want to make : if you need performance, choose a compiled language.
*) the goal you have with game development : if you want to work alone like Toady, choose whatever language you like; but if you have to work with other developers or if you plan to work in the game industry, choose C++ ... or maybe java for mobile phone projects.

bad programmers (and there are a lot of them in the game industry, don't kid yourself)

AFAIK, there are even more in other industries

[Blacken]

*) the type of game you want to make : if you need performance, choose a compiled language.

That's not always true. If I need performance, I write a library in C++ and shim it with C++/CLI to work with .NET. Managed code is generally better for control code (and it in effect allows you to do a lot of garbage collection even on native objects).

Nobody mentioned the D programming language ( http://www.digitalmars.com/d ) ?!   

Mind you, I have a world's worth of respect for Walter Bright, but--nobody mentioned D because D is a dead-end language that doesn't really address any pressing concerns. It's nice as an academic exercise, but little more. It's a solution in search of a problem.

[Draco18s]

What about A and B?

And C (and unix) was a joke anyway.

http://paginas.fe.up.pt/~jlopes/jokes/hoax.html

[Jifodus]

C# is nice (and my language of choice), but to think that they're going to switch en masse is a little silly.

C# is a better language than C++. It is conceptually cleaner and offers options that C++ does not (closures, lambdas, etc.)--but it's slower. Mind you, C# is a good glue language for interoperating between different native code libraries, but therein lies the problem: C# relies on native code libraries to do almost anything game-related. DirectX is C++. SDL is C. OpenGL libraries, likewise C. Physics libraries? Depends, usually C++. Why? Because C# is slower. Significantly so in some cases, such as when doing matrix computations.

The argument that C# has more features (I'm assuming you mean the BCL and other .NET libraries) is a misleading one. .NET has more features than just C++ and the STL, but that is a far cry from the full picture--there's Boost and there are countless libraries for C++ development, most permissively licensed.

C++ also has considerable inertia. It's what developers know. It's what they (currently) like. And while it's making inroads in tools dev, C++ be the primary language for game development in the foreseeable future because the underlying engine is most critical. Good programmers can write good code in C++; bad programmers (and there are a lot of them in the game industry, don't kid yourself) can write bad C#.

I'm just going to assume you know that C# is just a language and that it doesn't actually have any libraries nor as a language itself, any slower. So then I'm going to be using .Net in all my referencing.

In reality, I suspect that .Net will end up much faster than well optimized C++ now. If you haven't tried it recently, but with the Sun Server JVM it execute it much faster than the C++ version I had written (this was an algorithm sample); however, if speed is really a concern, nothing will beat hand-optimized assembly implementation of the same algorithm sample proved.

What's really stopping me from moving to .Net period is that I'm waiting for Microsoft to improve the JIT to improve it's execution speed to be more comparable to the JVM (I've read that it doesn't even unroll loops yet).

Now in regards to .Net making inroads into the gaming industry, I can name a good reason why that probably won't happen and it has nothing to do with speed. It basically is .Net relies on translating very specific data definitions to machine code. Those specific data definitions then make it very easy to reverse engineer the code. Now, of course there's obfuscators which make it harder to reverse engineer. It's still much easier than compiled binary code due to the type system, because you can see the different type groupings used by the code.

However, compiling C++ to native machine code you essentially lose all type information and only by analyzing hundreds (to thousands) of instructions can you start pulling out and definining structures, but it'll still be incomplete (have you tried any reversing of Dwarf Fortress?). In addition with a good optimizer you tend to lose function and parameter boundaries, sure there are identifiable functions, but watching the code accesses a non-standard parameter register for a parameter initialized in a function two calls away is always interesting.

Why would the industry care about how easy it is to reverse engineer? Well the first reason is they want you to pay for it, the second is that you don't want to make it easy for cheaters in online games.

Uhm.... I didn't plan on a wall of text...

In many cases if you are doing object-oriented design (which you actually can in both C and C++, though C++ makes it simpler by supporting objects directly), you will find that switch statements can be replaced by using polymorphism with objects.

First off, I would nearly never use much polymorphism in a static execution. I would take advantage of polymorphism in a JIT'd execution. This is because of lost performance due to extra overhead with dealing with extra memory (read: cache hits/cache misses). If you want a general idea how it works, take a look at implementing a COM object in C. You have your object in memory, you have your virtual function table, for every virtual function invocation you end up with upto 2 additional memory accesses and if you're doing complex memory intensive processing (read: games, Dwarf Fortress!) then odds are you've clobbered the cached page that holds the virtual function table.

Ok, I think that was more verbose than it should've been... I'll definitely shut up now.

A switch statement when used correctly will be best in either case, but you already knew that.

[lanael]

That's not always true. If I need performance, I write a library in C++ and shim it with C++/CLI to work with .NET. Managed code is generally better for control code (and it in effect allows you to do a lot of garbage collection even on native objects).

Yep, it's always an option ( I've done that on my 1MHz machine 20 years ago : basic + assembly ).
That said, with C# you are stuck with Microsoft thus Windows. I presume that you are then forced to use VC++.
( Ok, there's Mono, but it's not thanks to M$ )

Mind you, I have a world's worth of respect for Walter Bright, but--nobody mentioned D because D is a dead-end language that doesn't really address any pressing concerns. It's nice as an academic exercise, but little more. It's a solution in search of a problem.

Care to develop ? Why dead-end ? What pressing concerns ?

[Blacken]

I'm just going to assume you know that C# is just a language and that it doesn't actually have any libraries nor as a language itself, any slower. So then I'm going to be using .Net in all my referencing.

'Course, but the term being used was C#, so I used that term. Although there are no implementations of C# that do not rely upon the CLR (and thus at least a subset of the BCL), so that's really a minor nitpick.

In reality, I suspect that .Net will end up much faster than well optimized C++ now. If you haven't tried it recently, but with the Sun Server JVM it execute it much faster than the C++ version I had written (this was an algorithm sample); however, if speed is really a concern, nothing will beat hand-optimized assembly implementation of the same algorithm sample proved.

That's pretty farfetched, to the point of being simply preposterous. .NET will never be faster than optimized C++ simply because of the architecture. C++ lacks a number of facilities that a .NET language has (reflection, for example); while those facilities add flexibility, they're also inherently slower. There's also the problem if JITting simply not being as efficient as preprocessed native code in the general case.

What's really stopping me from moving to .Net period is that I'm waiting for Microsoft to improve the JIT to improve it's execution speed to be more comparable to the JVM (I've read that it doesn't even unroll loops yet).

I don't think it does, but I'm not a CLR hacker.

Now in regards to .Net making inroads into the gaming industry, I can name a good reason why that probably won't happen and it has nothing to do with speed. It basically is .Net relies on translating very specific data definitions to machine code. Those specific data definitions then make it very easy to reverse engineer the code. Now, of course there's obfuscators which make it harder to reverse engineer. It's still much easier than compiled binary code due to the type system, because you can see the different type groupings used by the code.

However, compiling C++ to native machine code you essentially lose all type information and only by analyzing hundreds (to thousands) of instructions can you start pulling out and definining structures, but it'll still be incomplete (have you tried any reversing of Dwarf Fortress?). In addition with a good optimizer you tend to lose function and parameter boundaries, sure there are identifiable functions, but watching the code accesses a non-standard parameter register for a parameter initialized in a function two calls away is always interesting.

Why would the industry care about how easy it is to reverse engineer? Well the first reason is they want you to pay for it, the second is that you don't want to make it easy for cheaters in online games.

This is true to a point--it's easier to reverse engineer CLR code, or Java bytecode, than native code--but I don't think it's as big a deal as you say; there are a number of obfuscatory tricks that make code generation essentially one-way. Other than that, agreed 100%.

First off, I would nearly never use much polymorphism in a static execution. I would take advantage of polymorphism in a JIT'd execution. This is because of lost performance due to extra overhead with dealing with extra memory (read: cache hits/cache misses). If you want a general idea how it works, take a look at implementing a COM object in C. You have your object in memory, you have your virtual function table, for every virtual function invocation you end up with upto 2 additional memory accesses and if you're doing complex memory intensive processing (read: games, Dwarf Fortress!) then odds are you've clobbered the cached page that holds the virtual function table.

Very good point. Static execution would scream, choke, and die if it had to hammer the virtual function table like that. In managed code, it's a lot simpler to deal with.


-------

Yep, it's always an option ( I've done that on my 1MHz machine 20 years ago : basic + assembly ).
That said, with C# you are stuck with Microsoft thus Windows. I presume that you are then forced to use VC++.
( Ok, there's Mono, but it's not thanks to M$ )

Actually, that's not totally true--Microsoft developers are closer to the Mono devs than you'd think. Not a lot of official collaboration, but there's definitely some back-and-forth. (Disclaimer: I work for the Mono project as a student developer.)

As for C++/CLI--also very true, mixed-mode assemblies only work on Windows, though C++/CLI itself builds to CLI that can be executed just like C#. But there's nothing stopping you from writing a managed wrapper for a native code assembly that's loaded directly; that's what SDL.NET does, I believe, and it's crossplatform if you swap out a platform-specific DLL.

Care to develop ? Why dead-end ? What pressing concerns ?

It's a dead-end language because it's not actually supported in a professional capacity. It's a dead-end language because it doesn't do anything significantly better enough than C++ to be worth considering over C++. And it doesn't address common C++ problems, like library divergence (Phobos isn't good enough, so here comes Tango! But neither work together!).

I'm sure that if you insist on it, D is fine. But it's just not a compelling choice for any reason other than "it's there."

[lanael]

It's a dead-end language because it's not actually supported in a professional capacity.

True, but it's still a fairly young language. And there is a big inertia regarding the professional adoption of new languages ( excepted when the language vendor is called Microsoft !). IIRC, it took C++ years before gaining notoriety. ( and before having a real C++ compiler from the language definition )

It's a dead-end language because it doesn't do anything significantly better enough than C++ to be worth considering over C++.

The D zealots would jump and yell if they happen to read that !

I'm sure that if you insist on it, D is fine. But it's just not a compelling choice for any reason other than "it's there."

I have a small and not professional experience with both C++ and D. So I can't make strong statements about this issue. What can I say is : it's far more pleasant and satisfying to write code in D than in C++ for me. I won't list all the features I liked, but such a list would begin with  "foreach"

But, hey, we just have to wait for C++0x ...

[Blacken]

It's a dead-end language because it's not actually supported in a professional capacity.

True, but it's still a fairly young language. And there is a big inertia regarding the professional adoption of new languages ( excepted when the language vendor is called Microsoft !). IIRC, it took C++ years before gaining notoriety. ( and before having a real C++ compiler from the language definition )

"Inertia" regarding adoption of new languages is a good thing. Lots of languages in use is not necessarily good. There needs to be a huge win to adopt a new language, and "I think this is cool" isn't one.

It's a dead-end language because it doesn't do anything significantly better enough than C++ to be worth considering over C++.

The D zealots would jump and yell if they happen to read that !

That's why they're zealots and should not be listened to.

I'm sure that if you insist on it, D is fine. But it's just not a compelling choice for any reason other than "it's there."

I have a small and not professional experience with both C++ and D. So I can't make strong statements about this issue. What can I say is : it's far more pleasant and satisfying to write code in D than in C++ for me. I won't list all the features I liked, but such a list would begin with  "foreach"

But, hey, we just have to wait for C++0x ...

C++0x is likely to address the major problems in the language. If it ever gets done. As for "foreach"--well, to be honest, I strongly doubt you do anything that is performance-critical, so why not just use a modern language with modern conveniences? :p