Allllllllright then. Some examples.
What we are going to do here is put up three examples, all with mistakes in them. The last example is designed for you to expand upon it, with some ideas of where you might go with it.
I’m including the text versions here, but I’m also going to include links to the zipped projects that I created using Microsoft Visual Developers Studio 6.0. These contain the same text that’s in here, except you don’t have to type them in.
Before we get started, I wanted to go over using a little bit of Dev Studio. I used this because it’s what I have handy. I’m not endorsing this compiler / debugger over anyone elses – it’s just what I use. With that in mind I’m going to give you a real fast overview of getting a DOS based project going inside of Dev Studio. I realize that this isn’t what everyone is using, but again, apologies – but it’s all I have to hand right now.
In order to create a new DOS based project, select the New option from the file menu. At this point, a big selection dialog box pops up. Select the ‘projects’ tab, give the project a name in the right hand empty box, and then highlight the ‘win32 console application’ line. A win32 console app is basically a 32bit dos program. None of the windows stuff is included, which is good cos there’s a ton of it and it’s damn complicated if you don’t know what you are doing. Anyway, click OK and another dialog box appears. This time you are being asked what kind of project it should build for you. There are 4 to choose from.
An empty project – I don’t normally go for this, since there is some Microsoft stuff that you really need to use to get stuff working correctly that you would have to write yourself.
A Simple application – this one has some files in it, along with a main function already built for you, plus some headers –we’ll talk about these in a second.
A “Hello World” application. This is pretty much the same as the one above, except there is a printf statement inside the main function, plus the header file references the .h file stdio.h
And lastly, a project that supports MFC. MFC stands for Microsoft Foundation Classes. This is what windows projects rest on. It’s a bunch of classes (that’s C++ stuff) that you can use to access windows functions. It’s way beyond what we are doing now, so don’t worry about it, and Don’t Select it.
Now, select the “hello world” type, and you are done. The project appears and you are good to start developing. If you download the examples directly, you don’t need to go through this since I’ve already created the projects for you. Just select the Open at the file menu, and open the directory where you unzipped the projects, and select the projectname.dsw or projectname.dsp file. .DSW / .DSP files are microsofts project files – they contain all that Dev Studio needs to know about your projects – what files are in it, sub directories, your compiler settings and so on.
NOTE – notice that the main file that Dev studio generates uses the project name, and has a .cpp file extension. Dev studio assumes that all the projects you want to build are going to be C++. Don’t ask me why. Anyway, with Dev studio, and some other compilers, you can mix and match C and C++ files together. It’s all done from the file extension. If you have a .cpp file, then it compiles it using the C++ compiler. If it’s just .c then it uses the normal C compiler.
Now be aware that this is not the case for all compilers. Some require you to specify up front what type of project this is going to be, C or C++. In this case, the extension is really not important. You want to select a C style project. C++ has a different definition from C, and is majorly less forgiving of some of the more naughty stuff you can get away with in C.
Back to Dev studio – just renaming the files from .cpp to .c is NOT ENOUGH. Since there are project files that have lists of file types in them, you have to tell the project that you have renamed files. You do this by opening the files pane of the desktop, selecting the files in question, deleting them from the project – just hit the delete key - (this only deletes them as far as the project can see them, not from your hard drive) then re-add them into the project. To do this, select the project at the top of the tree, where the words ‘source files’ are, right click on this, and select “add files to folder” from the floating menu that appears. Then simply select the renamed files you want to add in the selection box that appears, and you are done. Remember to save the project once you are done. Just select “save all” from the File drop down menu.
The .h files that dev studio generates are not as clear as they might be. For instance, you might notice that it generates a stdafx.cpp and a stdafx.h file for the project. Instead of including stdio.h for the printf in main, we include stdafx.h instead. Why is this? Well there is some setting up going on in stdafx.h that is peculiar to good old Microsoft. It’s F**king magic; let’s leave it at that. Notice though, that it does include stdio.h in there, so we are correct in our statements that stdio.h is required.
That’s about as far as I’m going to go with how Dev Studio works, since that’s a whole different scope study. Get a book on that, or use Microsoft’s resources to find out how the compiler and debugger work. Maybe I’ll do a more in depth tutorial on that another day.
A really dumb program that I was inspired to write by a female friend, since she is all into those stupid little things that girls did at school to determine how compatible two people are. Type in both names, and see how compatible you are.
This one prints out the first X prime numbers. Nothing fancy, a brute force approach, but it works.
The ubiquitous “higher / lower” number game. This one has stats in it too! Wow! Move over Id!
Some expansion idea’s.
Obviously what we have here is a rudimentary higher/lower type game. It just barely works. Figure out a way to add the capability to import the width of the range that the random number is taken from. So you can say, “ok, it’s a random number between x and y” when starting up the program. Use argc and argv for this. Also, try and figure out a way to get the players name in there, so it’s a bit more personalized.
Try adding some different text depending on how many guesses it took the player to get the answer, and how big the range was he was guess from.
Also, you might want to try adding the ability to use floating point numbers instead of integers.
Lastly, install a debug mode set of printf’s into the project. Read ahead for what I mean by this.
While we are here, lets look at a couple of debugging idea’s you might want to think about.
The first is the most obvious – sticking printf’s into your code everywhere. This will tell you whereabouts your code is crashing. Lots of coders use a printf at the start and end of any major routine to indicate when running that the code has reached that point. That way if you crash inside that function, you will know it, since you didn’t hit the exit printf. However, you don’t always want this code to be called every time you run the program, only when you are debugging. In this case, we might put an if statement in front of each printf, and only do it if a variable is set – we can set this variable through the argv function, by passing it into the project when it’s run. For instance you might pass into the code the variable –d for debugging. So on your console you’d type your project name
And inside the main function you’d set the global variable “debug_mode” to 0 or 1 depending on what was passed into the program by the argc / argv functions. I won’t give you an example of getting the variable in from running the program, – you have to figure this one for yourself – but the printf would look something like this.
printf(“We reached function x\n”);
You can even extend this printf to provide details on any variables that have been passed into the function if you want to.
Anyway, obviously you’d only do this printf in each function is debug is set to 1, otherwise you don’t do it. This way you only get the printf’s if you are in debug mode. Now this is a good way to do it, but in actual fact if you are doing a large project, then you really don’t want to be doing that check every time you hit a function – which is where those #defines come in. Remember us mentioning right at the beginning of all this the difference between a Release build and a Debug build? Well, we can extend the whole release / debug thing further by putting a #if and #endif around the check to see if we should do a printf or not. So we’d end up with something that looks like
printf(“We reached function x\n”);
This way we only do the check if we are running a debug build, and not if we are doing a release build, which we want to be the fastest it can be. Obviously DEBUG only wants to be set if we are doing a debug build – and it’s up to you to figure out how this is done with your compiler. Gotta start finding out stuff for yourself sooner or later.
Something else you should start becoming familiar with, if your compiler comes with it, is the debugging package. You should figure out what BreakPoints are, how they work, and how your system uses them. Breakpoints are nice helpful functions where you mark a line of code, and when the debugger that is running your program hits it, it just stops execution, allowing you to examine memory, function variables and so on. Once you are done examining stuff, you can start up the program again.
Also, you should start playing with looking at memory, looking at the call stack – (when you stop a program that’s in mid flow, you can look and see what function it is in now, and what called that function, and the function that called that, and so on. You can even see what data was passed into each function from the preceding one. This is VITAL information.).
All of this stuff is vital to being able to debug functions properly.