This kind of argument happens often when someone critics C/C++.
I disagree, C/C++ may very well give you the quickest path to realtime game programming if you put your mind to it. I'd try this first (I did) and go to the others if you have trouble -cowsarenotevil
But, what if you don't code realtime games? In most kind of projects, using C/C++ is not necessary and is a burden more than a blessing. The languages mentionned above are simpler and will produce better quality program most of the time. Eh! you can even code some pretty good games with them too! Maybe the final product will not be quite as fast as the equivalent C/C++ game but with today's computer, most people probably won't mind that much if the framerate is 50/sec instead 100/sec. -- FrancoisDenisGonthier
True, but if you do wish to make incredibly fast realtime games as your final goal, in some ways you're wasting your time with other languages. This article makes it seem like C/C++ isn't even a worthwhile option for beginners, while I can tell you that it is (was) fir me. -cowsarenotevil
If you want to make games in Python, try out http://pygame.org/. -- MikeNolan
I will admit that it will take time to see commercial games that don't use DirectX and OpenGL with C/C++, but it will eventually happen. Note that we are a bunch of hobbyist programmers and It's not the goal of most hobbyist to make "incredibly fast realtime games". That takes time and a lot of energy. I personally prefer to care about my girlfriend and code a tic-tac-toe clone once in a while than spend my whole evenings coding a big-ass 3D C/C++ game that is not likely to hit the shelves any day soon!
I will hold on my opinion (and many people share it) that C/C++ is not a good language for beginners to use. Many young kids will start learning C/C++ because their friends told them "yea uze C/C++ becoz that'z what gamez are madez wit". Then they start C/C++ and get quite happy when they display a dot on the screen. Python, for example, will allow programmers to produce a good application or a small game in much less lines of code and much more easily than C or C++. They won't need to manage memory, play with pointers that can make their program crash in an instant, know the inner working of the OS they use and they'll spend less time debugging errors than they would with C and C++ because the compiler or the interpreter won't let them make the stupid mistakes a C++ compiler would. I dare you prove me the contrary...
I'm not the one what will say you should avoid C and C++ altogether. Once a programmer get to learn one of the above language, it's not a bad thing to learn C++ because it's still the most popular language out there. Also, a programmer that doesn't have C or C++ on his resumé might be considered weird by his future employers. That only if you want to work in the industry. I know some people here don't care about that kind of argument :P -- FrancoisDenisGonthier
You mention "young kids," but I became fairly good at C++ around 10. And what's wrong with being happy to be able to make a dot on the screen? What I find sad is when people learn python/etc. and then think they are "teh 1337 pr0gr4mm0rs" and then go around telling people that pointers have no purpose and that C++ is only for people who like to pretend that they're special. I personally think getting a feel of what you're actually doing with the computer is better than being able to get graphics on the screen by copying someone else's code. But this is just turning into pointless flaming. Just keep in mind that beginners who first learn C/C++ usually do just as well as those who learn other languages. -cowsarenotevil
This is not flaming in any way...
I think you have been arguing all right and I'm trying to keep things clean. I'm sorry if I hurt your feeling by talking about 'young kids'. I really didn't know you were THAT young ;D
It's normal that you feel proud because you are able to do everything by yourself. It's a nice feeling yeah but when your goal is producing good software in the shortest time possible, it's very nice to be able to grab someone else code and not care about controlling everything the computer does in the background. Of course, if you start taking credit for things you did not do, you are stupid! That applies to everything in life!
I'm glad to hear you succeeded with C/C++ but that doesn't make them good languages to start with. Maybe your are, well, pretty good for your age. Most pre-teens I know would have got discouraged pretty quickly if they started learning C++ instead of Basic! I myself started with QBasic at 12 y/o... -- FrancoisDenisGonthier
Actually I'm 13 now. True, it doesn't neccasarily make C++ a good language to start with, but there's no real proof that it isn't either. I just think that it's a more viable option than this article makes it appear. And I also feel that there is slightly better documentation on it. -cowsarenotevil
I think it's not a good first language and I'm not the only one thinking that. If you have good reasons a _starting_programmer_, not really interrested in making 3D games right away, should learn C/C++, you are free to rewrite my (yeah, that's from me) article above. I do think you should try other languages, different than C/C++, before advocating it as a first language, but if you really feel like it, this wiki is free-for-all.. -- FrancoisDenisGonthier
I don't see why I'd want to rewrite it, both of our opinions are visible here, and I think it's fine this way. I know you aren't the only one thinking that C++ is a bad first language, and I know I'm not the only one who disagrees. I have used many of these alternative languages (mainly Java and VB, along with a bit of Python) and find them all good. What it boils down to is that you should use the language that does what you want it to.
EDIT: Heh, that works too 
-cowsarenotevil
I just feel the need to add one thing to this discussion: I think I mostly agree with the "pointers have no purpose" statement that cowsarenotevil probably meant as an example of a silly thing that only "a newbie" would say. For pretty much everything above the "OS level," pointers have no purpose but to make things harder for the programmer. I would challenge anyone to give an example where pointers are beneficial to have, as compared to having separate arrays, references, and recursive data structures.
-- AdamChlipala
Pointers useless? They are quite possibly the most useful tool for creating data structures that do exactly what you wand. Prefabricated data structures are good, but you don't have total control over them. Pointers are benificial for the shear fact that they allow access to the memory at a level that nothing "less advanced" will be able to achieve. Pointers are what makes C++ powerful, not what makes it bad. Why else would C++ support referances, AND several prefabricated data structures? I think I may just rewrite the C/C++ section after all. -cowsarenotevil
OK, then how about giving that concrete example...? I think anything you suggest that isn't subsumed by one of the language features above merely suggests another high-level language feature, not a general pointer mechanism. -- AdamChlipala
Sorry, I didn't quite understand that last post of yours. But what's wrong with just rewriting the C/C++ section in order to contain both of our views?
EDIT: But if you want an example of where an pointer would be useful, take for example an octree. They're much easier to implement using pointers.
-cowsarenotevil
Please stop editing this page while I have the edit lock for it! This is indicated by a scary red warning displayed at the top of the page when you open it for editing.
My last post asked you to give a precise example of a situation where pointers are the best tool for the job. Can you explain why pointers are better to use than recursive data structure definitions for octrees? Note that your example does not use pointers but rather uses either arrays or references if you do no non-array pointer arithmetic .
Rewriting the C++ section is fine, as long as it doesn't take over the page. The views of both sides with brief justifications would be nice.
(Communicating back and forth like this is silly. I urge everyone to mock cowsarenotevil for refusing to visit the IrcChannel. :P)
-- AdamChlipala
Sorry, I'll watch out for scary red warnings from now on (I honestly didn't see one, i just page-down immediately so that I can see the bottom of this page). I probably can't give a precise example of where pointers and C++ are the "best" tool for the job because "best" in that sense is purely subjective. I've found octrees using pointers to work very well, and though some people probably prefer doing it other ways, some (for example, me) probably don't. I just don't see why so many people like to bash C++ because it allows you to use more complex features. And you can mock me all you want for refusing to visit the IRC channel, but in some ways I find this to be better (I still think thread-based forums are the best of all of them though, but that's for another page ;)). -cowsarenotevil
More complex features allow for more bugs. Pointers are even worse than most such "features" because they are more than just "complex"; they are unsafe. Programs written using pointers can crash, have certain kinds of silly security holes, etc..
Thus, in the presence of reasons for a language not having pointers, I think you should be a little worried by the fact that you can't present a situation in which they are better to have than the combination of the other language features I've mentioned!
-- AdamChlipala
But you can use C++ without needing pointers. And as for an example where pointers are "better," what is you're definition of "better"? I could post countless examples, but you could just as easily say something else was better. It's all a matter of preferance. -cowsarenotevil
No, it's not "just a matter of preference." Pointers allow more opportunities to introduce hard-to-find bugs, so using languages that include them is an objectively bad decision because this leads to taking longer amounts of time to develop software. -- AdamChlipala
As I said, then don't use pointers if you can't get them to work properly. There are STD Vectors and countless other usable data structures included in the standard C++ libraries, but I personally like pointers because they are the most flexible way of storing data, which is also why, when used badly, they can be the worst. I prefer the flexibility and syntax over C++, and you prefer the safety(I'm sure there's a better word I meant to use, but I'm tired ) of other languages. It's really still a matter of preferance. -cowsarenotevil
No, I assert that between two people equal in all respects but "choice" of whether or not to use pointers in developing applications, the one who chooses not to use them will come out ahead in productivity. This all depends on adequate language support, of course, which C++ does not have (MlLanguage-style recursive datatypes is the most important missing feature for these purposes), but all popular functional languages do. -- AdamChlipala
Still, I have expierince with a few languages and I'm by far the most productive with C/C++. Perhaps that isn't "normal," but then again, perhaps it's normal to be abnormal. Don't ask me why I'm more producive in C/C++, it might be the style, or it could be anything else, but it always does what I want it to in a way that feels most comfortable. I also think C/C++ has the most documentation, because it's been around longer and is used by more people. -cowsarenotevil
I'm very productive with VB and C/C++ because I started real programming with the first and used the later at school. I'm quite productive with both of them but I'll readily admit both of them have flaws. I don't think we can't force the dislike for C/C++ into you but since you are 13, you have a lot of time ahead of you to learn yourself. In the meantine, keep your mind open to new experiences and remember what we said here. -- FrancoisDenisGonthier
I'm not sure who posted the 2nd last block, but I'd guess that whoever it was has never learned well a language containing the 3 key replacements for the uses of pointers in C that make up 99+% of appearances of pointers: arrays, references, and special means for defining recursive data types. -- AdamChlipala
Sorry, that was me. I have seen those replacements (and used them occasionally) but what I'm trying to get across is that in some ways I just prefer pointers. I could say I suddenly decided I hated them and never use them again, but it wouldn't be true -cowsarenotevil
If you use every pointer that you have defined as either an array or as a reference, then it's not very honest for you to say that pointers are important to you in any pragmatic sense. -- AdamChlipala
But I don't, I use them to allocate memory on the fly. -cowsarenotevil
Both arrays and references are associated with dynamic memory allocation, so I don't see what you mean. If you aren't doing arbitrary arithmetic on memory addresses, then you aren't really using pointers. -- AdamChlipala
Can you make a dynamic octree using arrays and references? If so, I think I need to start relearning some things... In all honesty I have a feeling that this discussion is going to go beyond the scope of my knowledge soon, so if I start sounding stupid, just pretend I'm not here any more. -cowsarenotevil
Yes, you can. -- AdamChlipala
Really? Do you by chance have an example? I was under the impression that references couldn't be reallocated. Anyway, I'll shut up now (I'm leaving for a vacation anyway).
- -cowsarenotevil
Well, i've jumped into the conversation awfully late, but i figured i'd chuck my 1/5 dime in. I'm not a very proficient C coder, but i know enough to make small progs for myself. I started coding in Euphoria when i was 12 or so. Now, i'm 14 (almost 15) and i'm a proficient coder in Euphoria, somewhat proficient in C, and i'm learning Perl and Assebler currently. I think that if i had tried programming in C originally i would have become discouraged and stopped immediately. Personally, when i'm designing a program, i don't want to have to consider what hardware i'm running. After designing a program in Euphoria, i will, however, translate it into C by hand, make optimizations based on my hardware, then compile it so i have a fast compiled program. I hardly ever start a program in C, but as i'm becoming more proficient in C, im coding more and more in it. -- CJSilver
Do you think it says something bad about the languages you choose if you can't get efficient development and efficient execution with any one of them alone? -- AdamChlipala
If I remember correctly, the Euphoria compiler isn't free. Never did anything with Euphoria though, so correct me if I'm wrong.
To cowsarenotevil - C++ References can't be changed, however other languages have other definitions of what a reference is: Java, for instance, uses references that behave little bit like pointers, except that they use reference counting (and thus automatically free unreferenced objects). On the other hand, java references don't allow all the nice stuff like pointer arithmetic etc. You can quite easily implement a class in C++ that behaves like a Java reference. -- MarkusB
OK, so I guess the literal C++ type "reference" can't be used to do what I said it can, but pointers used without arithmetic can, and those are references in spirit. Also, I don't think Java garbage collection is accomplished with reference counting, but rather with mark-and-sweep. -- AdamChlipala
Yes, you are probably right about the Java references - I think I confused them with references from some other language. Still, the idea is the same behind both gc-systems (reference counting might fail in a few cases when mark-and-sweep won't, like circular lists etc) -- MarkusB
MarkusB, you are mostly correct. Euphoria doesn't really have a compiler. It binds source code to the interpreter. That feature is not free. But, the free distribution of Euphoria is still extremely useful.
AdamChlipala, since i need the Eu environment to code in euphoria, it doesn't make a difference to me whether i have source code or executables on my HD. You're right in that it's not great that to share all of my programs, i'd have to translate them into a more widely-recognized language that most people have support for, or that i can compile under. But, i think that as far as general languages go, Euphoria is still nice to use. It doesn't bother me that i would have to translate a program into another language. It's something i do rather frequently anyways. Usually i write the code in euphoria first, then in C, then in Perl, and if possible, TI-BASIC so i can run it on my graphing calculator.
--CJSilver
Writing the same program repeatedly in a chain of languages may not bother you, but I think it's clearly wasteful and leads to your producing less quality software per time period. -- AdamChlipala
I don't think there is any one language a beginner should learn, as long as you can grasp the concept of the language and how it works, and it doesn't promote bad programming practices... I say go ahead. -- Mike Kuenzi
While I do agre that pointers can be dangerous in C, I do disagree with the point that they are bad to use altogether. I've been programming C for around 5 years, and can't even imagine the language without pointers...although I did start with another language, BASIC, to begin with, I somewhat wish I would have started with C in the beginning instead. Here's an example: I've programmed in Java for around 4 years, and no one explained to me that leaks are also possible in Java when there's not a variable pointing to a class. So I went and took 7 months writing an 80,000 line program in Java, and it leaks like crazy...and starts up at 120 megs. After that, I went on a 2 year spree looking for a new language and ended up with C...dynamic memory allocation and DEALLOCATION are extremely important in languages, and because power can be abused, that doesn't mean that they are bad altogether. Every tutorial I've seen explains the dangers in pointers and allocation. One example of where it's more usefull, is that I've been trying to create a coroutine application for using C as a language to somewhat script games...it's much faster than an embedded scripting engine, and much more powerful. I had to create a structure that is a void pointer, that implements a linked list of structs with a void pointer in each to a random struct of different elements...while some languages that are loosely typed may be easier than this, I can't even begin to think of how to do it in Java...pointers do have their place, and I wouldn't have a place without C/C++. -- Finder
Finder, if there really were no references to the leaked objects, they would be collected as garbage. What would have happened if you had written it in C and free()'d it when there were still references to it? You'd have problems a lot worse than just memory leaks, which make the program not just hog memory but not work at all. So which do you prefer? -- that the programmer let the program leak memory, or that the programmer dramatically and fatally break his own program? Either way it's the programmer's fault, but in the former case, the system can protect against the latter case.
Your second example of pointers being useful is very incoherent. Would you mind explaining it a bit more clearly?
I think he means that in C, you can just have a void* to be any arbitrary payload. He apparently doesn't know that you can assign anything you like to a variable of type Object in java, and you don't lose the type system like you do when you cast to void* in C. --IainMcCoy
The problem turns out to be that in java, if an object goes out of scope, the reference still exists, and the garbage collector never collected it...I suppose that a reason I didn't know this was that the book I had, and java tutorial on the Sun site never explained it in detail. So instead, I let my references go out of scope rather than setting them to null. For the example, the whole point was in real time graphics, use of structures to save the stack without using assembly...yes, I know you can do that in java with objects, but the speed is much too slow of creating blank objects for using...say, 2000 scripts in half a second. I'm not saying that Java was meant for pure speed, either...my main point is that each language has its place, and I feel that to do abstract things easily in C, pointers are nearly required. 
-- Finder
You're excessively incoherent here. Let me make myself clear: it's your doing if there are still references to the object. So, if either you or the garbage collector had deallocated the memory, it would have caused bad pointers to it, which are a lot worse than just hogging a bit of memory.
Then let me try to make myself more clear. Java has classes...I extended a class to implement a JFrame, and then self contained all of the gui elements to that jframe within this class. No other classes were linked to, except for the gui classes like JButton, etc...when created, this class creates the JFrame, and all gui elements, and when closed, it destroys it all as well using dispose(). I create this class within one function, and destroy it within another...there are no other references to it in the rest of the program. It is impossible, except through the swing library, for a reference to any gui element to still exist after destroying that class, and according to the java api, dispose should well take care of those as well. I wish I could explain it better, but please understand that this was an 80,000 line program that leaked...but I boiled the leak down to this single class, that created and destroyed frames. Each time I would destroy it, it would just leave the memory behind, even after calling the garbage collector. The reason? I was never taught that you have to set objects to null before the garbage collector will pick them up...try it. Create 2,000 string classes and let them pass out of the scope of the function, and you will get a huge leak. I don't think I can get any more clear...I'm not going to reply to this subject again, because it's beyond the point of a Cplusplus for beginners subject. My main point, is that if used correctly, memory deallocation is a good thing, and Java doesn't have an explicit deallocator. bad pointers are an easy problem...just set them to null and don't use them any more. ;-p While I do realize that sometimes you slip, it's an easy problem to take care of if you know what you're doing, and think a little bit about design. Pointers aren't that hard to follow, so long as you destroy one as soon as you make it, and watch the scope of it. -- Finder
Of course if you keep a reference to an object, and never substitute a different value for that object, the garbage collector won't collect it -- that's the point of garbage collection: if there are no no references to a block of memory, it will be deallocated. Look at the possible situations in detail. Let the object in question be called Frob.
- You had no use for your reference to Frob.
- You do nothing. Leak!
- You substitute some other value for the reference to Frob, e.g. null, though it could be any value. In this case, if there are no other references to Frob, the garbage collector will kick in to collect it. If there are other references, Frob's life happily continues, and it's not your fault if you can't control the other references to Frob and the program leaks.
You deallocate it. In this case, if there are no other references to Frob, you're amazingly safe. However, if there are references to Frob, *BAM*, segfault! because of an invalid pointer dereference: the memory that was dereferenced had been deallocated.
- You had use for your reference to Frob.
- You do nothing but use it as you would normally. This makes sense, and your program leaks because of its design.
- You substitute some other value for the reference to Frob, e.g. null, though it could be any value. In this case, if there are no other references to Frob, the garbage collector will kick in to collect it. However, if you try to use your reference, which was to Frob but is now to something else, you may get unpredictable results, especially if you had set it to null.
You deallocate it. In this case, if either you or someone else who had a reference to Frob tries to use it, *BAM*, segfault! for the same reason as above.
Now, path 1B is the only desirable path. 2B isn't nearly as bad as 1C or 2C, but you still have a bug in your own code. 1A causes the leak you wanted to avoid. Now what about the ones where you used manual deallocation? 1C and 2C have the WORST outcomes of ANY of the paths. Do you see why? And do you still want manual deallocation?
If I wrote a program to iterate two thousand times, and allocate a single string for each iteration, it would not leak. Why? Because I no longer refer to the string in the previous iteration, and neither does anyone else, so the garbage collector can kick in and eat said string, leaving plenty of heap space for the next N iterations.
One of the biggest problems with malloc()- & free()-based memory management is that you don't always know if some memory is referred to anymore. Garbage collection does not have this problem.