From the very first day at school, computer science, we where bombarded with a phenomenon known as Object Oriented Programming, or OOP for short. During the first year, many of us saw the beauty of it, which probably was why we where supposed to use it. We never really got to alternative methods of programming, so it must’ve been the holy grail of software engineering.

C++ really is C with object orientated syntax additions. Only being tough Java the first year and onto C# the second, I was quite curious as to how C++ would approach the subject. So here’s my second part of the journey into the universe of C++: object orientation!

The first thing any programmer notices when starting out with C++ and OOP, is the way classes are split up into two different files. Where a class in Java is defined in a single file, C++ has this extra piece of information, called a header file.

When creating a class, you actually start out with this header file, which defines the class you’re about to implement. Such a file could look like this:

class Gearbox {  
public:  
    Gearbox();

    void changeGears(int gear);
private:  
    int currentGear;
};

cpp

I’m sticking quite a lot of information at once in this header, for those who haven’t seen it before. Let’s start out with the awkward braces usage, which is terminated by a semicolon ;. It surprised me that this is necessary, especially the weird errors you get when you don’t do it. It gives errors all over the place, except for where the actual problem lies, at the end of a header definition. So always check that bit.

Then there is the alternative method of declaring the members of the class, specifically the modifiers (public, private, protected). You only need a single ‘public’, after which all public methods are declared. However, there is the possibility of using multiple modifiers, if you like to group the members:

class Gearbox {  
public:  
    Gearbox();

private:  
    int currentGear;

public:  
    void changeGears(int gear);
};

The Gearbox() method is the constructor of this class, but in C++, there is another special method for classes, namely the destructor. Like the name suggests, it’s the method that gets called when the object is destroyed. The destructor gets called when the delete keyword is used on an object.

Gearbox* gb = new Gearbox();

delete gb; // This is where the destructor of the Gearbox object gets called  

This has everything to do with memory management, where an object gets the opportunity to clean itself up before the memory manager releases the memory. This can be handy for objects referencing other objects, which won’t automatically get deleted when the parent object is deleted.

// Inside destructor of Gearbox
delete gear1; // Gear object  
delete gear2; // Gear object  

When the object is on the stack, the destructor gets called at the end of the scope.

The destructor is defined by using the name as the class, like the constructor, but prefixing it with a tilde ~.

class Gearbox {  
    Gearbox();
    ~Gearbox();
};

This syntax has been adapted in some other languages as well, so you might have seen it before. The above code could go in a file called Gearbox.h.

Header files have puzzled me some time, why do they exist and why can’t they be generated automatically? Well, one of it’s usages is to expose classes and methods to other applications. The implementation is compiled into machine code and the header file is used to list all available methods within a class. It seems they could be automatically generated, but some keywords are specified in the header file instead of the implementation, like virtual.

On to the implementation of our class, which contains the actual code of our class.

#include "Gearbox.h"

Gearbox::Gearbox() {

}

Gearbox::~Gearbox() {

}

void Gearbox::changeGears(int gear) {

}

This code could be in a file called Gearbox.cpp.

This time, we are back to normal braces-notation, without the need of semicolons. At the top of our file, we start out by including the header file. Commands prefixed with a # are compiler commands. The compiler really pastes the code of the header in there, which could cause some issues. I’ll cover those a bit later on. The first method we define is the constructor, which starts with the name of the class 'Gearbox’, followed by two colons and finally the name of the constructor, which of course is the same as the class. Note that you don’t need any visibility modifiers in here, those are already in the header file.

The destructor is quite similar to the constructor, with the exception of the added tilde ~. Then we define the method 'changeGears’, which deviates from the other two methods in its void keyword. Regular methods also do not have a visibility modifier, but they do have a return type declared in front of them. Every method is prefixed by the name of the class, because you can actually implement multiple classes in one class file.

Now if we where to use this class in another piece of code, we would use the same include directive as in the class implementation.

#include "Gearbox.h"
Gearbox* gb = new Gearbox();  

Note that we only need to include the header file, the compiler will look for the appropriate implementation.

Earlier, I mentioned the include directive simply lets the compiler paste in the code of the referenced file. This could lead to issues if we would use the same include twice or more, because the same class would be defined more than once. The compiler doesn’t approve of this and will give you an error. So to account for this, we can add some commands to the header file, to ensure it is only run once.

#ifndef GEARBOX_H
#define GEARBOX_H

class Gearbox {

}

#endif

This is where it really gets creepy for us Java developers. The first command in the above snippet, #ifndef GEARBOXH, is a command for the compiler, to check if the GEARBOXH variable has not been set ('ifndef’ as in 'if not defined’). If that’s the case, we’re defining the variable now, using the #define GEARBOXH directive. The contents of the variable will be the class definition, followed by the end of the if statement, #endif. The GEARBOXH variable can have any name, it’s just convenient to use descriptive names. The _H stands for 'Header’.

There is an alternative to the above code, in the form of pragma:

#pragma once
class Gearbox {

}

It’s a lot shorter, but it has the down side of not all compilers being able to parse the command. It seems this always works on Window machines, but on other operating systems, it might not work. The first method is the classic one, the second is a bit more modern.

With one of these compiler commands added to the code, we can now safely use as many includes as we like. You won’t need this for thecpp files, as those are handled by the compiler and will only be parsed once.

Those are pretty much the basics of object orientation in C++, next time I’ll move on to inheritance.