22.3 Defining a new class

Just to show that making a class doesn't need to be hard, let's do the absolute simplest implementation of, say, a cDisk that represents a circle. Suppose we assume that we specify the circle by a cVector center, a Real radius, and a COLORREF fillcolor.

For a class which has simple fields as members , C++ defines an appropriate default no-argument constructor, a default copy constructor, a default overloaded operator= , and a default destructor. The default constructor allocates space for the data fields but doesn't initialize them, the default copy constructor and operator= copy the data from one object to another field by field, and the default destructor simply frees up the space used by a class object. (As an aid in debugging, when you do a Debug build of a program in Visual Studio, unitialized variables are filled with a distinctive bit pattern, commonly 0xCDCDCDCD ; so if you see a variable with a curiously regular value, it usually means you forgot to initialize it.)

For this very simple example, let's make all the class data members public so we don't have to think about mutators and accessors. So now we can define cDisk like the following.

 class cDisk  {  public:      cVector _center;      Real _radius;      COLORREF _fillcolor;  }; 

Is that painless, or what? Who says it's hard to use classes?

This is a time to remind you that

when you write classes of your own, you have to put a final semicolon at the end of the class declaration . This is a possible slip-up that can lead to really confusing error messages from the compiler.

This is also a time to mention that in C++ we have the convention of starting all of our member variable names with an underscore . This makes your code more readable as then you can easily recognize when something is a member variable. Unfortunately this sound and useful convention was not carried over to Java. Do note that the code will compile just as well if you leave out all the underscores on the private field names ; they are there only for the human programmer, the compiler doesn't care what you call the variables.

Where should we put the class definition? The clean thing to do is to put it into its own disk.h file that lives in the same directory as our Pop code. Since we don't have any cDisk methods to implement, we don't need a disk.cpp file.

How to make the disk.h file? There are several choices.

If your new class header file is similar to an existing class header file, simply make a fresh copy of the old class header file and change its name . Or use File New to create the disk.h file in Visual Studio (or in any other text editor, provided you save it as a text only file).

In either case, you'll need to use the Project Add Existing Item... [ Project Add Files... in Version 6.0] dialog to add the file to the Pop project.

You can create and add the file in one step with the Project Add New Item dialog [ Project Add to Project New Files tab dialog in Version 6.0].

A final option, not highly recommended, is to use the Visual Studio menu selection Add Class... (Note that this option is only visible if you have selected View Class View. ) [The control is Insert New Class... in Version 6.0.]

The author doesn't recommend the last technique because it throws you into a dialog box situation with a lot of choices whose consequences aren't immediately clear; and when you're done, your files have some ugly machine-written code that you truly don't need.

One caveat; when you make your own header file, don't forget to bracket it with the following lines to prevent double header-file includes (as discussed in Chapter 20: Using Microsoft Visual Studio).

 #define DISK_H  #ifndef DISK_H  ...  //The class prototype code goes here  #endif //DISK_H 

However you end up making your new header file, you need to tell the files that want to use it about the class, by putting an #include "disk.h" into them. When you have classes with methods you need to implement, you need to make a file like disk.cpp to put the implementation into. You can make this new file in any of the ways mentioned above. Be sure that the first two lines of this file are these.

 #include "stdafx.h"  #include "disk.h" 

When working with an MFC project, if the #include "stdafx.h" isn't the very first (non-comment) line of your *.cpp , you will get a confusing error message when you try to compile.