Working on Learning C++


Blue Protoman

Well-Known Member
Joined
Mar 6, 2010
Messages
4,117
I've managed to compile a simple program on the Pandora already, which is nice. So far, on cplusplus.com, I've finished Functions II. I'm pacing myself, knowing that I'm not going to instantly be able to make a game (that's when I get to SDL). Still, I plan on sticking to this.


With that in mind, anybody know how to use Code:Block's debugger on Windows XP? I really should be learning how to use it. I have no idea how to get it to report anything to me.
 
It's been a long time since I've programmed in C++, but the compiler should give error messages if there is something wrong with the code, IIRC. So long as you're getting error messages for syntax errors, etc. I wouldn't be bothering with a full debugger just yet.


Also: Good luck!
 
Syntax errors are caught before the program's even fully compiled. But other things in which issues aren't syntax (for example, using the wrong variable) can be missed. I've already hit a few bugs in my work.


Perhaps once I learn how to use make files I'll throw everything I've made up here in a PND or something. I don't really care about the stuff I've made, just the learning experience from it, so I'll release it under the public domain. I actually have something now (though it's been improved upon since) right here.
 
Yeah, in that case I'd avoid a debugger for now, if only for the following two reasons:


1. Debuggers do a little too much of the work for you - debugging your own code is an excellent way to get a feel for how everything works, even if it can be extremely frustrating.


2. It's another thing to learn that can distract you from the task of actually learning to program.


I must admit, though, that I might be a little biased as I've never used a debugger much at all (except for some collaborative stuff that was too huge and messy to debug manually).
 
Perhaps once I start making things more complex than programs that calculate how many cookies each kid in a group will get. I want to have started learning SDL by August, whilst being familiar (not necessarily an expert) with C++. We'll see how far I can go before school starts in September and my spare time is sucked away.
 
Last edited by a moderator:
Good for you, learning to program :)


Test output is the simplest and probably most used method of debugging, just insert print commands (printf/cout/qDebug/whatever) before and after you do stuff. Add something to the test output to differentiate it from normal program output, like a few spaces in the beginning of each message. Also it's useful to always print the values of any variables that are important for the execution at that point, like loop variables or stuff read from a file. If you print the value of some strings, always surround them with some characters that tell you where the string starts and ends so you catch errors resulting from empty space in the beginning or at the end of a string.


I personally use a debugger (gdb in my case) quite little, mainly to find out where a program segfaults/hangs. Usually it's just quicker to do a couple of test prints where I think the problem might be and figure the actual problem out by running the code in my head :)
 
Hm, so debuggers, if I understand, aren't really all they're cracked up to be, except for specific situations?
 
so you finally bit the bullet and started learning :p


i'd say C is a tad easier to get to grips with to start with, but you can always write c++ in a procedural way, so the points pretty moot


a good debugger is extremely useful if you have some strange crash you need to pin down, but until you've hit a segfault that doesn't make any sense there's no real reason to learn


i'd also suggest at least learning to code on/for linux, as there's always quirks in the various systems, and definately stop using codeblocks, at least until you understand the concepts of compiling/linking correctly, and how to do such things manually from a command line (you'll need to know when it comes to using makefiles anyhoo :p )
 
Hm, so debuggers, if I understand, aren't really all they're cracked up to be, except for specific situations?
I'd disagree with the others on this. Debugging your own code is fine, but you can put in a ton of prints, write loads of unit, system, white box, black box, mock object tests, but nothing beats SEEING your code run line by line. The number of things I've spotting just from the different view of actually stepping through each line of code gives you...
 
Last edited by a moderator:
That C Dev Tools PND really is a blessing, I've used it a few times and it worked perfectly and simply.
 
Hm, so debuggers, if I understand, aren't really all they're cracked up to be, except for specific situations?
Depends if you want to use a hex editor to look at your RAM when you need to check that the pointer you thought you used correctly is indeed correct or it contains garbage data. Debuggers are incredibly useful, once you go outside the purview of Hello World and Guess My Number. Of course you will more than likely need to place your own debugging messages throughout your code, especially in real-time applications, and I have done it more than enough in all my ten years of programming with C++.
 
Hm, so debuggers, if I understand, aren't really all they're cracked up to be, except for specific situations?
I'd disagree with the others on this. Debugging your own code is fine, but you can put in a ton of prints, write loads of unit, system, white box, black box, mock object tests, but nothing beats SEEING your code run line by line. The number of things I've spotting just from the different view of actually stepping through each line of code gives you...
This is very true. A good debugger combined with a good IDE is a great asset in programming. Especially debugging some of the more complex algorithms. Seeing all the variables and stepping through the statements one at the time is very helpful in those situations.


My comment was more geared towards continuous debugging, where you don't wnat to step through stuff every time, but get a "summary" of what happened on that run. This summary you can get every time you test the program without needing to try to repeat the situation while running in a debugger. Also in some situations you don't have access to a good IDE/debugger combo, such as on pandora (that I know of), in which case you're better off knowing how to use the other tools efficiently. I'm currently in a situation where only the pandora build of my application fails, which is a good example of a situation like this.


Test output is a hammer. Quick, brute, effective, available everywhere. Debugger is a multi-tool. Slower, precise, handles even special cases with grace, available almost everywhere.
 
My two cents :


- debuggers are nice for two things : see your code run step by step when using a complicated algorithm (but you'll need this less and less over time) AND stopping on a particular occurence (class member modified, assert, etc) to examine stack, memory... especially in C++ where all the overloading/riding mecanisms can make it very difficult to know when a specific section of your code is run, in big projects. But IMHO if you find yourself relying too much on the debugger, it's probably a sign your code has grown to big/messy to handle properly. gdb is a sound choice on Pandora/Linux (can't remember whether it's in the dev tools though), since you should be able to remote-run it and use DDD/KDBG on your PC with gdb server. Never did it myself on pandora so maybe it's not possible ?


- for segfaults and other uninitialized variables or allocations problems, catching them with valgrind/memcheck before they happen is the best.


- I learned C++ the hard way with C++ annotations. Best site web I found. Quite long but even explains template metaprogramming. Gives a lot of sound advices/best practices. Isn't written by a C++/OOP fanboy. Took me three months though. You should also read Design Patterns at least once. No use learning C++ if you don't learn patterns too IMO. especially if you intend to program games latter on.
 
Thanks, but I don't have all year, so for now I'm just sticking with cplusplus.com and cprogramming.com. I did bookmark that, though.
 
gdb is a sound choice on Pandora/Linux (can't remember whether it's in the dev tools though)

It's not in the pnd - I'll stick it in the next version. Debuggers are very useful of course, but I usually forget they exist (I tend to use the kind of test output that B-ZaR describes).
 
gdb is a sound choice on Pandora/Linux (can't remember whether it's in the dev tools though)

It's not in the pnd - I'll stick it in the next version. Debuggers are very useful of course, but I usually forget they exist (I tend to use the kind of test output that B-ZaR describes).

gdb is at /usr/bin/gdb as expected, no need to install it, it is part of the default nand ;)
 
Um yeah - there's always the option of using the one that's already there I suppose! :rolleyes:


Incidentally, the book Programming Linux Games (link to the legal version) has a nice introduction on using gdb, and is mostly devoted to teaching how to make a game using SDL. It might not be that useful for you though, Blue Protoman, as it uses C rather than C++.
 
Last edited by a moderator:
That's OK, I found another great site for SDL. It focuses on the language itself rather than the application of it, but I'll figure it out.
 
gdb is at /usr/bin/gdb as expected, no need to install it, it is part of the default nand ;)

is gdbserver included too ? could be useful for those of us who'd rather use a graphical frontend to gdb on pandora...
 
is gdbserver included too ? could be useful for those of us who'd rather use a graphical frontend to gdb on pandora...
Yes and No: I gather it's been integrated into gdb since 5.3 and the version on the nand is 7.0, but there's no separate executable for it. I'm guessing here, but I'd say you can the functionality of gdbserver by running gdb, but there's no nice low-resource version of it.
 
Last edited by a moderator:
Back
Top