Why are all of the tutorials for C++?

[XxionxX]

Why are all of the tutorials for C++? Is something about C not good for game programming?

 

[Klaue]

Why are all of the tutorials for C++? Is something about C not good for game programming?

C is really really old. C++ is too, but C is in a whole other league. Today, you'll probably do not want to use C for anything other than really low level or legacy stuff, kinda like it is with assembler.


Of course, millions of C fans just cried out in anger


Also, the Object-Oriented approach is better suited for game programming

 

[darfgarf]

C is really really old. C++ is too, but C is in a whole other league. Today, you'll probably do not want to use C for anything other than really low level or legacy stuff, kinda like it is with assembler.


Of course, millions of C fans just cried out in anger


Also, the Object-Oriented approach is better suited for game programming

that's all personal preference, i say which approach is better depends on the game, and C++ should be used sparingly (no sense object orienting everything)


http://lifehacker.com/5744113/learn-to-code-the-full-beginners-guide?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+lifehacker%2Ffull+%28Lifehacker%29&utm_content=Google+Reader


^^ gave those a quick glance over, and they seem to cover the basics ^^

 

[Klaue]

C is really really old. C++ is too, but C is in a whole other league. Today, you'll probably do not want to use C for anything other than really low level or legacy stuff, kinda like it is with assembler.


Of course, millions of C fans just cried out in anger


Also, the Object-Oriented approach is better suited for game programming

that's all personal preference, i say which approach is better depends on the game, and C++ should be used sparingly (no sense object orienting everything)

Of course it's personal preference Personally, I think making a game in C would be a pain in the butt, but other people might think the same thing about C++, Phyton, Java, Brainfuck2D, Pascal, VB, Whitespace, Lolcode etc etc. (No, I don't think all of them are suited for serious programming)


In the end, if you want to do every little thing down to the lowest level yourself or if you want the language to handle that stuff is just preference.


I'd still say that C++ mnakes programming games way easier than C

 

[slaeshjag]

Of course, millions of C fans just cried out in anger

I know I did

 

[bzar]

I'd still say that C++ mnakes programming games way easier than C

And you are not alone

 

[XxionxX]

what the hell happened to my topic??? lol

Sorry :unsure: Should I start another thread?

C is really really old. C++ is too, but C is in a whole other league. Today, you'll probably do not want to use C for anything other than really low level or legacy stuff, kinda like it is with assembler.


Of course, millions of C fans just cried out in anger


Also, the Object-Oriented approach is better suited for game programming

But doesn't the low level language make your program faster and more portable? I know it is all about preference, but it seems like there are certain advantages to staying closer to assembler.

 

[bzar]

Sorry :unsure: Should I start another thread?

I think this topic should be split to another thread. Mod?

But doesn't the low level language make your program faster and more portable? I know it is all about preference, but it seems like there are certain advantages to staying closer to assembler.

Neither is a given.


Low level code only makes your program faster if you can do better than the people who made the other language. A great example is that in select few cases a typical Java implementation for an algorithm is faster than a typical C implementation, because the Java implementation can do a lot of behind-the-scenes optimization most people wouldn't bother or couldn't do.


Low level code makes your code more portable only to an extent. If you need OS specific stuff, you're bound to an OS. Use some high-level language or library like python or Qt, your code runs on many platforms because the devs have abstracted the platform specific stuff to generic interfaces.


EDIT: typo

 

[Letalis Sonus]

because the Java implementation can do a lot of behind-the-scenes optimization most people wouldn't bother or couldn't do.

That is something entirely different because those optimisations do not come from the language itself or its compiler. Java is a pure bytecode language, it is executed by a VM that is usually written in C. The speed-up of those certain algorithms comes from being able to do everything at runtime, the VM is able to do optimisations based on how the program runs, optimisations that really can't be applied to static code, usually not even by the coder himself. On the other hand the VM causes a general slowdown, those win situations are rather rare and generally I really wouldn't recommend using any bytecode languages for applications that need performance unless you're really sure that you can profit a lot from those rare cases.


On static code the differences between the languages can be huge. C can be directly translated to assembler, that's what makes it so fast. C++ tries to do that as well as far as object oriented programming allows it. Other higher level languages usually sacrifice that possibility for the sake of further abstraction to allow more advanced concepts, and the more abstraction is added the more code is needed to ensure that everything goes well. In such cases a compiler can't know whether certain cases are even possible to occur, you'll get a lot of useless code checking lots of things.


If you want to get a small impression of how much overhead comes into play you can take a look at Vala. It is very similar to C# and Java, but it was designed to be used with GLib's GObject system. That means that it actually generates C code which is directly reached through to a C compiler, but you can let it output the C sources and headers as well, this way you can take a short look into how such things are done without having to dig through assembler code - the generated code looks quite cryptic, though.

 

[bzar]

That is something entirely different because those optimisations do not come from the language itself or its compiler. Java is a pure bytecode language, it is executed by a VM that is usually written in C. The speed-up of those certain algorithms comes from being able to do everything at runtime, the VM is able to do optimisations based on how the program runs, optimisations that really can't be applied to static code, usually not even by the coder himself. On the other hand the VM causes a general slowdown, those win situations are rather rare and generally I really wouldn't recommend using any bytecode languages for applications that need performance unless you're really sure that you can profit a lot from those rare cases.


On static code the differences between the languages can be huge. C can be directly translated to assembler, that's what makes it so fast. C++ tries to do that as well as far as object oriented programming allows it. Other higher level languages usually sacrifice that possibility for the sake of further abstraction to allow more advanced concepts, and the more abstraction is added the more code is needed to ensure that everything goes well. In such cases a compiler can't know whether certain cases are even possible to occur, you'll get a lot of useless code checking lots of things.


If you want to get a small impression of how much overhead comes into play you can take a look at Vala. It is very similar to C# and Java, but it was designed to be used with GLib's GObject system. That means that it actually generates C code which is directly reached through to a C compiler, but you can let it output the C sources and headers as well, this way you can take a short look into how such things are done without having to dig through assembler code - the generated code looks quite cryptic, though.

[morning rant]


You're missing the point. You can do those same optimizations Java does (regarding memory management and all) in your C version, but they're by no means included in a standard solution, because they increase the required amount of code by many orders of magnitude. My point was that higher level languages sometimes automatically do optimizations you would never even think of doing.


C is as fast as the coder is skilled. Good coders can make the fastest programs in C. I'm not saying anything to the contrary.


(gah, got to get to work)


(continuing at work)


The example I chose is good exactly because the languages are different. Moreover, you could implement a part of Java VM in C and hard code it to run only your algorithm faster than the reference version. You just never would because it's such a huge task in C. My base point remains: higher level languages sometimes give you optimizations for free that would be a pain in the butt to implement in C. I'm not saying this is always the case. As I said in my previous post, it's just not a given that C is always the fastest with the typical implementation.


Another thing is that you did was assume a competent, good programmer. In my sad experience this is not the typical case. Assume an uninformed, perhaps even a bit dumb programmer who goes to the biology section of the library when asked to implement a binary search tree. How well do you think that programmer would implement something like a map data structure in C? Array and bubblesort? The higher level helps you even in things you are not aware of. If you are good enough, you can always make more specialized and thus faster versions of the same optimizations, but most programmers aren't. I dare say there are higher level programming tasks where an average programmer would make a more efficient solution in python than in C. The difference between a good programmer and an average programmer is in my experience a whole lot bigger than the overhead in Vala, C++ or alike. Even a bad programmer can use ready stuff and have most of his program be well optimized by others.


Another example would be something like C++'s vtable system. If you needed something like polymorphism and inheritance in your program and gave the task to an average programmer, would you expect a better result than what comes out from a typical C++ compiler? It all boils down to what you need, and can you do it better than the guys who have already done it.


[/morning rant]

 

[Letalis Sonus]

I think this topic should be split to another thread. Mod?

++

But doesn't the low level language make your program faster and more portable? I know it is all about preference, but it seems like there are certain advantages to staying closer to assembler.

If you want to squeeze the last bit of performance out of your program you at least have the option to do such hardcore optimisations. It is common practise for commercial games to code the whole thing in C++, track down the bottlenecks and rewrite those parts in assembler. Many low level languages allow you to directly embed assembler into your code, which will be directly translated. That way they can get the maximum out of it without having to sacrifice the structural benefits of a OOP language, as far as they are experienced on writing highly-optimised C/C++ code (which isn't that difficult to achieve, IMHO).

Another example would be something like C++'s vtable system. If you needed something like polymorphism and inheritance in your program and gave the task to an average programmer, would you expect a better result than what comes out from a typical C++ compiler? It all boils down to what you need, and can you do it better than the guys who have already done it.

Counter question: When do you know that you really need it? When would you actually use it?
The time one of that dumb coders would need to get deep enough into that matter to actually see the advantages of these concepts so that he starts using them would be enough to actually gain quite a large amount of knowledge on how to code somewhat efficient in the classic imperative way.


Another matter is that especially Java is behaving totally different, it has a completely different "idea" of how efficient code should look like due to its VM magic. A Java freak would go crazy using static languages, simply because what Java may consider efficient because the VM can optimise it a lot and therefore terminating the increased overhead would be horrible inefficient when executed directly. Splitting things up in tons of classes may be good in Java (to come back to the example of the dumb coder: that one wouldn't code this way anyway), but statically it means that a LOT of long jumps need to be done, you'll continuously jump across the whole code creating a quite noticeable bottleneck.


I still say that Java is a bad example because it's not the language itself that differs that much, it's the artificial architecture behind it that completely differs from real architectures and that's not what makes Java being considered a high-level language, I could use an imperative Java-like VM based low-level language as well and would still profit from those optimisations. Compile your stuff to native code with e.g. gcj and we'll talk.

 

[bzar]

Counter question: When do you know that you really need it? When would you actually use it?

Whenever it fits the data model behind my program and makes my code more elegant. A typical example is modeling a biosphere that has a load of organisms, some of which are animals, some of which are mammals, some of which are humans. All organisms can reproduce, all animals can move, and so on. However different animals move in different ways, so they need different implementations. It would be tedious to sort all animals to different data structures based on species and call all of their respective movement functions one by one. With polymorphism you can just have an array of Animals and call move on all of them. On the other hand I can also have another class derived from Organism called plant that is a different kind of organism. And so on. Though I'm sure you knew all this.

The time one of that dumb coders would need to get deep enough into that matter to actually see the advantages of these concepts so that he starts using them would be enough to actually gain quite a large amount of knowledge on how to code somewhat efficient in the classic imperative way.

Yes, if he actually does the smart thing and tries to learn something instead of making it the stupid way and leaving it at that because "well, it works". I'm constantly surprised by the frequency people, even some smart people, do this. I can't tell how many times I've seen data structure implementations that are way more inefficient than any standard library ones. The same applies to stuff provided by the languages. It's almost always possible to make a better specialized implementation, but most people won't bother or can't, because they're more interested in making the application logic.

Another matter is that especially Java is behaving totally different, it has a completely different "idea" of how efficient code should look like due to its VM magic. A Java freak would go crazy using static languages, simply because what Java may consider efficient because the VM can optimise it a lot and therefore terminating the increased overhead would be horrible inefficient when executed directly. Splitting things up in tons of classes may be good in Java (to come back to the example of the dumb coder: that one wouldn't code this way anyway), but statically it means that a LOT of long jumps need to be done, you'll continuously jump across the whole code creating a quite noticeable bottleneck.

This is in my opinion correct in most aspects. However, "noticeable bottleneck" is somewhat relative. Is it comparable to a badly written algorithm? I'm saying it's not that big of an impact in the big scheme. Of course in edge cases (runs full speed, runs 90% speed) it is important because of the limitations of the hardware.

I still say that Java is a bad example because it's not the language itself that differs that much, it's the artificial architecture behind it that completely differs from real architectures and that's not what makes Java being considered a high-level language, I could use an imperative Java-like VM based low-level language as well and would still profit from those optimisations. Compile your stuff to native code with e.g. gcj and we'll talk.

Depends on what you're comparing. I was comparing the performance of the same algorithm written in two languages. Of course it's possible write the most efficient code in C or asm, that's a no-brainer. However in a typical real-life scenario most people rarely use the most efficient implementation due to not knowing them or laziness. For example caching is sometimes a pain in the butt to write, but may add up to significant speed boosts. However, the pain in the butt is too much to bear unless it's absolutely needed, so it's not implemented.


Remember here, my argument was that it's not a GIVEN that a C implementation is ALWAYS faster than an implementation in a higher level language. My other argument was that it's not a GIVEN that every C program is inherently more portable than the same program written in another language. The rest is just answering arguments

 

[XxionxX]

So it depends on the coders general knowledge of the language they are using and assembly for optimization? But I thought that higher level languages were harder to port? Is this only true if you have no knowledge of assembly?

 

[darfgarf]

So it depends on the coders general knowledge of the language they are using and assembly for optimization? But I thought that higher level languages were harder to port? Is this only true if you have no knowledge of assembly?

it's all down to experience, if you come at things form a computer science point of view, you'll most likely learn how to do object-oriented first, and gravitate towards java/C++ etc, if you work up from the bottom like i did (hand programming a z80 dev board in hex) then you'll most probably start with asm/C etc, then it's all dependent on what you write and how you write it.


high level OOP code can be hard to read if you're in the procedural mindset, and vice versa

 

[Klaue]

But I thought that higher level languages were harder to port?

Quite the opposite. The higher a language is, the less the user of it has to care about the system he's on. Of yourse, you can also make low-level-language programs portable, but the lower you go, the harder it is.


I wanted to add an example here, but I couldn't think of a good one..

 

[darfgarf]

Of yourse, you can also make low-level-language programs portable, but the lower you go, the harder it is.


I wanted to add an example here, but I couldn't think of a good one..

a well written and segmented game, written in C/SDLiece of cake


compared to an emulator, with an x86 assembly coreain in the cake as all the asm needs rewriting


both are essentially 'low level' in the sense it's not C++, but the difference is quite a lot


problem with high level things is it's harder to port the language in the first place, lets say language X depends on libc, and language Y depends on about 50 other libraries aswell, which is easier to get running on a new system? (this is assuming it's a completely new system etc, all theoretical as it's not really like that)

 

[Klaue]

Okay, if you take assembler into it, an example is easy to be found I thought more about C and Java (there was something about file rights or file types that was extremely proprietary in C but I can't remember it)

 

[darfgarf]

C-compiler exists for anything, depends on little and therefore easy to port the language, fairly portable code overall but neeeds to be compiled for each target etc


java-harder to get the virtual machine setup going, depends on a lot compared to c, more portable assuming the system already has java ported to it, runs on anything


(all ignoring performance/system requirements etc, as that's another kettle of fish)

 

[bzar]

Just adding a little detail, C porting is easy if the code uses no platform-specific stuff. For example sockets in C work differently with linux and windows, but the same code works for both platforms in (for example) python or java or C++/Qt.

 

[Klaue]

C-compiler exists for anything[...]


java-harder to get the virtual machine setup going[...]

I guess that XxionxX means apps made by the programming language, not the language itself (nad the parts of it like compiler, interpreter or in java's case JVM etc)