Learning C++
jamieshepherd
Join Date: 2009-09-04 Member: 68693Members
<div class="IPBDescription">The best places to learn this language</div>So I've done a lot of XHTML/CSS over the years, and worked a lot with ActionScript, and this year I've been learning PHP which it seems is very similar to AS2, so we've been getting along swell. However, I've always wanted to look into a language like C++, or a language that will enable me to write my own client side applications with a lot of flexibility. Now I don't want to write the next Spark engine or whatever, I understand this takes decades of experience and university degrees, but I'd like to know where everyone started. If there are any competent programmers out there who started on a particular book or resource, please let me know. There are hundreds of books on Amazon and it's a bit of a mind###### as to which would be a good read for a beginning programmer. Unfortunately I'm primarily a visual learner, and it seems there is absolutely zero [good] C++ video tutorials available, so I'll have to have a really dumbed down book to get me going. I've had a few recommended, but I want to be coding clean and up to date standards compliant code. There are books which recommend, for example, you do system("PAUSE"); at the end of your programs (massive example here) but dozens of sites say this is bad practice, however this book for example gets a lot of good reviews, yet it's teaching you bad practice? So confusing.
So anyway, if anyone can help, let me know what resources you used to get started with programming in C++! (My eventual aim in years to come will be little puzzle games and such, and I'm learning as a hobby to keep me occupied - no more). Kind regards.
Edit: As a side note, if anyone knows of any <u>good</u> DVD or video training series this would be a mega bonus! I learnt the basics of PHP entirely from a DVD from Lynda, so went there originally for C++ training, but they were unable to provide one :(
So anyway, if anyone can help, let me know what resources you used to get started with programming in C++! (My eventual aim in years to come will be little puzzle games and such, and I'm learning as a hobby to keep me occupied - no more). Kind regards.
Edit: As a side note, if anyone knows of any <u>good</u> DVD or video training series this would be a mega bonus! I learnt the basics of PHP entirely from a DVD from Lynda, so went there originally for C++ training, but they were unable to provide one :(
Comments
As to "bad practices"... it's not like CSS/HTML. It's not like designing with tables vs. CSS. The point is for you to write stuff that works. The only "standards" I can think of are to actually split your program into functions and objects and such... not just have it all in one gigantic main function.
I learned it without a book by just trying to write programs and searching (google) when I got stuck.
Though honestly, if you're just trying to learn this to write some games as a hobby... I would definitely recommend learning C# with XNA... There are lots of tutorials for handling graphics and input and sound, and 2D games are way easier. C# is less used in the industry than C++ of course because it is generally slower... but it's also "fluffier" (it handles memory management and the syntax is less convoluted) and so writing games in it is going to be easier.
For learning C# I would recommend getting a book off amazon. Make sure it includes working with .net libraries and is fairly recent. I believe .net 4.0 is either out or in beta, so you want at least 3.5 or 4.0 if you can find it.
The beauty of teaching yourself from a book instead of from the internet is that books teach you a lot of things you should know but don't know to ask, whereas the internet is best at answering specific questions.
This is a good point.
For anyone who is already rather proficient with C++, I would recommended Effective C++ by Scott Meyers. Shows you a lot of common mistakes people make and some different design patterns. Meyers has an Effective STL book and a More Effective C++ book, but both of these seem to be less about general C++ usage (More Effective C++ might as well be called "all about autoptr").
I definitely think C# is the way for you to go jamie.
I've mostly learned C++ from a foundation of C/Basic/scripting via reference manuals and doing projects.
I recommend grabbing a good textbook (sorry, don't know one) since not only do they tell you how, they tell you why.
For example, it's one thing to know C++ lets you send pointers to functions. It's another thing to know when and why it's a good idea (almost always a good idea).
<a href="http://www.cplusplus.com/" target="_blank">http://www.cplusplus.com/</a>
<a href="http://www.learncpp.com/" target="_blank">http://www.learncpp.com/</a>
<a href="http://www.cplusplus.happycodings.com/index.html" target="_blank">http://www.cplusplus.happycodings.com/index.html</a>
Books:
<a href="http://www.amazon.co.uk/Sams-Teach-Yourself-21-Days/dp/067232072X/ref=sr_1_1?ie=UTF8&qid=1292213669&sr=8-1" target="_blank">Teach Yourself C++ In 21 Days</a>
<a href="http://www.amazon.co.uk/Beginners-Guide-Second-Herbert-Schildt/dp/0072232153/ref=sr_1_1?s=books&ie=UTF8&qid=1292213706&sr=1-1" target="_blank">C++ A Beginners Guide</a>
Good luck! (I've been learning on and off for about a year now and wish I had more time for it because I genuinely enjoy coding in C++ and PHP.)
I hate C++ so much. I swear, it's a programming language developed by trolls.
Except maybe C.
--Scythe--
So, it's using the massive assumption that you're going to be writing a console app and launching it in windows. Which just happens to be true for the large majority of beginners. I'd chalk it up as a good idea for learning/debugging. Although some development environments will do the pause for you, not all will.
That being said, I don't know of any books that are better than others. It's been a while since I cracked open a c++ book that wasn't about a specific API. I'd think anything with a lot of sample code would be a good place to start.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->if (i<=a.Length && i>0)
assert (a[i] >= a[i-1]);<!--c2--></div><!--ec2-->
How is it physically possible for this to cause an index out of bounds error??
EDIT: Bit of background.. I'm taking this programming theory course where we use <a href="http://www.research.microsoft.com/specsharp" target="_blank">Spec#</a>, so as to prove our programs correct. Mostly the problem is telling the program why x==y, but in this case some sort of magic is causing even running the program normally to crash, unless I remove all the Spec# proof stuff (none of which have side-effects, by definition) whereupon it works perfectly. Maybe I should post this in the Spec# mailing list instead...
remember that an array indexing starts at zero, not one. So if you let an index i be equal to the length of an array, it will actually point to the element after the array has ended.
The last element is Length - 1.
C# is just outright unnecessary.
C is the way to go. C++ has some advantages (<< >>), but it's best to take what conveniences you need, and stick with core C for the rest.
As far as a DVD to teach you to program, that's a little like learning to paint through interpretive dance. Sure, you can /do/ it, but it makes little sense to anyone else as to why you'd want to. If you need the auditory side of things, you can likely find a lecture series. But a vast majority of coding is conceptual understanding on a deep level... a video isn't going to help with that like it would with fixing a toaster. It's a mindset more than anything else.
Really, check out your local community colleges. You'd benefit FAR more in a classroom or even a simple lab setting, if a book isn't sufficient.
On the other hand, Java provides many of the same object oriented and system integration features of C++ with less quirks. You may want to consider learning Java first and then sidestepping to C++.
Even though I taught myself some C and C++ early on, at university I learned first an interpreted language (a lisp dialect), then an object oriented language (Java), then a low level language ©, then assembly language (mips), then C++, python, etc. For what it's worth, that progression helped me learn what there was to learn at each level and not get tripped up by language features that didn't make any sense at whatever current level of understanding.
Bias: I prefer using python for high level, performance insensitive tasks, and C for when I need speed and efficiency.
That being said, if you can do it in C, there's almost nothing faster.
That being said, Java is getting really darn fast since it uses virtual environment and can make runtime optimizations, and so in many applications is now as fast if not faster than C/C++.
That being said, knowing a scripting language like Perl or Python will get you far in life. In fact, most tech jobs have that as a requirement.
C# is just outright unnecessary.
C is the way to go. C++ has some advantages (<< >>), but it's best to take what conveniences you need, and stick with core C for the rest.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'd rather say; use the right tool for the right job. Learn the language for the job, not the job for the language. Far from every problem is C/ASM-solvable (without significant extra work), and it is certainly not the optimal tool for many tasks.
Java, FORTRAN, C, C++, Python, PHP, Lisp, MATLAB -- I've used them all for different tasks. I am currently working on a large scale application in Java (using the lovely Eclipse) and I could not see myself doing it with any other of the above languages. Perhaps C# or some other strictly typed language, but certainly not C.
C, as any other language, is a specialized tool disguised as a general tool ;)
As for recommending C# or Java over C++, I personally think that people coming out of uni these days are clueless about some of the more critical aspects of programing. I personally think that you should start with C until you have a basic idea of functios, control flow, passing values, references and return values etc. You should almost certainly have experience with pointers and dynamic memory management before you move to a system with automatic memory management.
Head First is a good book-series that helped me keep the interest past the 4th chapter :p
<a href="http://headfirstlabs.com/" target="_blank">http://headfirstlabs.com/</a>
I have the Java Programming 2nd edition. Helps you get started at least....although swing is booring as hell.
Lies. Compilers totally can do all your memory management and loop unrolling for you.
<!--quoteo(post=1816489:date=Dec 16 2010, 10:23 AM:name=Skvate)--><div class='quotetop'>QUOTE (Skvate @ Dec 16 2010, 10:23 AM) <a href="index.php?act=findpost&pid=1816489"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ive tried learning C++ a couple of times, but never gotten too far. I would recommend trying Java or similar first, to get a good handle on OO and not worrying about pointers, "destructors" etc.<!--QuoteEnd--></div><!--QuoteEEnd-->
I agree with you puzl for aspiring Software Engineers. If you're planning to do this as a profession you need to understand the low level stuff. I don't think it is as important for a hobbyist, and in many ways I think getting a grasp of the logic of programming before even needing to worry about memory issues is going to be an easier way to learn. Learn to think like a programmer and create well structured programs, and then learn how memory management works and how to make your programs go faster.
Even if pointers are the first thing you want to learn about, I still don't think C++ is the best choice. The reason I started really understanding pointers was because I took a class where we wrote in Assembly. When you're writing at that low of a level the pointer reference / dereferencing is absolutely essential and it helps to clear up how the operators work when you get to the C++ levle.
Even if pointers are the first thing you want to learn about, I still don't think C++ is the best choice. The reason I started really understanding pointers was because I took a class where we wrote in Assembly. When you're writing at that low of a level the pointer reference / dereferencing is absolutely essential and it helps to clear up how the operators work when you get to the C++ levle.<!--QuoteEnd--></div><!--QuoteEEnd-->
Very good point! We wrote a lot of Assembler for 8086 in class (untested, mostly writing simple stuff and using clock cycles per instruction to figure up a total time cost) and actual programs for this little SBC in the lab. Programming at that level forces you to confront things like registers, segments, and near/far jumps, and the difference between them. The tradeoffs between doing a near jump and spending less CPU but forcing your program into a smaller memory space, or doing a far jump for more cycles but giving you a bigger working area. And it really flipped me out to realize that all the mysticism of a computer basically just comes down to a deterministic 16- or 32-bit adder. :P
Later on we had a more gooder SBC that we could write C on using CodeWarrior. That thing was neat.
Or prolog?
Or prolog?<!--QuoteEnd--></div><!--QuoteEEnd-->
If you can't synthesize a 32bit ALU in VHDL what're you doing in the programming world?
Or prolog?<!--QuoteEnd--></div><!--QuoteEEnd-->
Prolog and similar languages emphasise on relations between sets of data and such are well built to represent and treat information. However, it is not unique and there are other alternatives to it (some which are more up to date). It's not a silly language though.
Assembly has the unique position that it is a representation of the inner workings of the computer instead of an abstract view of it.
... or were you sarcastic and trying to use a language's age or widespread use as an indicator of its usefullness? ;)
<!--quoteo(post=0:date=:name=puzl)--><div class='quotetop'>QUOTE (puzl)</div><div class='quotemain'><!--quotec-->As for recommending C# or Java over C++, I personally think that people coming out of uni these days are clueless about some of the more critical aspects of programing. I personally think that you should start with C until you have a basic idea of functios, control flow, passing values, references and return values etc. You should almost certainly have experience with pointers and dynamic memory management before you move to a system with automatic memory management.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, from where I am sitting there are also other critical aspects of programming, such as maintainability. Ideally, one should have a fair grasp of all these aspects of software development before being labeled as a programmer.
Which end to start I cannot say, but it might well be that C/ASM is the place to start to force the subject on the students before anything else.
Now, there's obviously champions of either side. Of course, they come in many different sizes, but I prefer these stereotypes myself. Say they've both been in the business since the early 70s.
On one side (A), you've got the guy who's running Linux at home but his heart's still in Unix. He's gritty- years of visualizing the stack has left him jaded and scarred, but he wears those scars like a crown. His keyboard is probably older than you, and it's got axle grease on it because he also builds robotics and circuits.
On the other (B), you've got the guy who never quite found his place. Punched cards in college were black magic, but he never dared show weakness. As the young discipline of Software Engineering started to take its first breaths, he was the first on the firing line, quoting observations by the great book writers. "Design is an iterative process!" He'd say in meetings. "We must future proof!" As he tapped the table relentlessly with his index finger. His designs are cursory at best, because given even months of time, he cannot follow all control paths of the program in his mind, and so he sacrifices real assurance that the program will work for the picturesque diagrams that black box design gives him.
Guy A considers Guy B a dead weight. Guy B considers Guy A a lowly code monkey. As time passes, newer and more illustrious terms than "Software Engineer" are used to describe them- "Systems Engineer," "Chief Architect," "Chief Scientist." And still the field of computer programming/software engineering is a scorched no-man's-land. And as a result, we struggle on as a sort of red headed step child in Engineering.
I apologize for going on! I guess my point is, there really isn't a defacto place to start in software. What's mostly required is the perseverance to keep at it until you're able to do what you want to do.
I think you are right except that the OP isn't just looking for a place to start in software. The OP is looking for a place to start in game dev... and not on the super deep optimization stuff either (since that is really graphics, networking, databases, etc), but as a way to create games as a hobby. To me this screams of the second case between your two "personalities".
I really think unless you are doing serious low-level speed-conscious stuff, you can get away with C#. Of course, in programming my personality is more on the architect side rather than the hacker side...
Learn with C/C++. Do and track your own damn malloc() and dealloc() work, don't rely on the computer to do it for you. Still the most widely used programming language(s) in the world, and for damn good reason, compared to more recent offalings. Then again, I don't really count interpreted languages (Java/Perl/VBasic) as <i>real</i> programming languages.
Then again, I'm sure the COBOL coders may say the same about C.
Learn with C/C++. Do and track your own damn malloc() and dealloc() work, don't rely on the computer to do it for you. Still the most widely used programming language(s) in the world, and for damn good reason, compared to more recent offalings. Then again, I don't really count interpreted languages (Java/Perl/VBasic) as <i>real</i> programming languages.
Then again, I'm sure the COBOL coders may say the same about C.<!--QuoteEnd--></div><!--QuoteEEnd-->
Java is compiled to what is essentially Java virtual machine machine code. (I actually think those to machines are correct form...) That makes it on par with something like a virtual machine on your computer running Ubuntu and compiling C, not interpreted in the sense that is usually thought of, and I don't think it's fair to make the comparison.
Besides that, if we are to write off progress in memory management at a high language level because it's sloppy, then we should also write off the progress made at the low level in assigning particular chunks of memory to programs when they ask for it using malloc and let it go using free. The machine does some complicated heuristics to help ensure that when a program asks for memory, it doesn't have to wait long for it because a suitable chunk of contiguous memory is not available. The same is true of hardware routines for writing to disk, or handling deadlocks in resources. Vanilla C/C++ have very limited libraries for handling these things.
Writing TCP/IP between programs in C++ involves finding a Berkley sockets library, studying the API which will allow you to grab a port, open it, bind to it, and then check it for data. Maybe you can give the library a callback to tell you when it has data. Ring buffers, buffer overflow checks, extra packet headers, and any other nice things that you might need to do anything really useful, you must write yourself.
You're talking probably 200-400 lines maybe just to read a packet correctly from a socket over TCP/IP in C to say nothing of doing valuable caching or handling surges and what not. And that's doing as little as possible. In .net C#, the same functionality will run you maybe 10 lines, and most likely it will be <i>more</i> secure because it's matured over 10 years backed by hundreds of engineers minds, while your code is yours alone.
Next, consider the flexibility of C#'s file system. In C++, a class must be entirely declared within one file - usually a header. The definition of the class, the real source, can be split up any way you want over how many files you want, but you declare part of a class here and the other part over there. In C#, you can. Partial classes let you generate half or more of you class from a python script or some such to save you lots of time on boiler plate code, and then regenerate it over and over again without ever worrying about messing up hand coded segments. In C++ this is a pain.
Just to examine a few differences.
Learn with C/C++. Do and track your own damn malloc() and dealloc() work, don't rely on the computer to do it for you. Still the most widely used programming language(s) in the world, and for damn good reason, compared to more recent offalings. Then again, I don't really count interpreted languages (Java/Perl/VBasic) as <i>real</i> programming languages.
Then again, I'm sure the COBOL coders may say the same about C.<!--QuoteEnd--></div><!--QuoteEEnd-->
I scoff at your high-level programming languages. REAL coders use a microscope and a magnet to set the bits on the platter by hand. That's where you should start, not with COBOL. In fact, screw that too. If you haven't built your computer from the ground up, transistor by transistor (preassembled AND gates? Are you ###### KIDDING me?!), you know NOTHING about programming and you might as well go back to your Lego Mindstorms, SCRUB.
Get with the times. Real EEs use Verilog noob.