Abstract Classes and Polymorphism Revisited

I’m on a fundamentals trip at the moment, so I’m going back over things I mostly understand to ensure I really understand the principles involved and not just in a vague hand-waving kind of way. Today’s fundamental revisited is abstract (pure virtual) classes and polymorphism in C++ – it’s commented to the hilt to make clear not only what’s going on but WHY it’s going on. You wouldn’t generally comment your code this heavily, but as a reminder/guide I’m fine with it:

#include <iostream>
 
using namespace std;
 
/*** ----- Shape base class - (Abstract)----- ***/
 
class Shape
{
public:
        // Only a single method needs to be a pure virtual function (which we use the '= 0'
        // phrasing to denote) to make the class an Abstract class. But we'll assign them all
        // to be pure virtual functions with no implementation.
        //
        // Note: Any class which inherits from an abstract class must implement ALL methods
        // of that abstract class!
        virtual string type()      = 0;
        virtual float  area()      = 0;
        virtual float  perimeter() = 0;
 
        // Because Shape is an abstract class we should provide it with a virtual destructor
        // If we didn't declare this as virtual then it wouldn't get called when the destructor
        // of an object of a derived class is called.
        virtual ~Shape()
        {
            cout << "Virtual Shape destructor called!" << endl;
        }
};
 
 
/*** ----- Circle derived class ----- ***/
 
class Circle : public Shape
{
public:
        // Constructor declaration
        Circle(float rad);
 
        // Derived destructor
        ~Circle()
        {
            // Nothing to do here as radius property is not allocated on the heap using the 'new' keyword.
            // If it was, however, then this would be where we'd have to free that memory.
            cout << "Derived Circle destructor called!" << endl;
 
            // Note: After this, as a Circle is a type of Shape, the Shape virtual destructor will be called.
        }
 
        // Polyomrphic public methods
        string type();
        float  area();
        float  perimeter();
 
protected:
        float radius;
};
 
Circle::Circle(float rad) : radius(rad)
{
    /***
     * Member property set in initialisation list for efficiency.
     * If we set the property in the constructor then we perform TWO operations:
     *
     *     - We construct the member property with a default value,
     *     - We then overwrite that default value with our constructor parameter.
     *
     * If we use the parameter list to initialise the value, we only perform ONE operation,
     * which is to initialise the property with the parameter we passed in. This can have
     * significant performance implications when working with large arrays of objects.
     ***/
}
 
string Circle::type()     { return "Circle";                }
float Circle::area()      { return 3.14f * radius * radius; }
float Circle::perimeter() { return 2.0f * 3.14f * radius;   }
 
 
/*** ----- Rectangle derived classs ----- ***/
 
class Rectangle : public Shape
{
public:
        // Consturctor declaration
        Rectangle(float theWidth, float theHeight);
 
        // Derived destructor
        ~Rectangle()
        {
            // Nothing to do here as width and length properties are not allocated on the heap using the 'new' keyword.
            // If they were was, however, then this would be where we'd have to free that memory.
            cout << "Derived Rectangle destructor called!" << endl;
 
            // Note: After this, as a Rectangle is a type of Shape, the Shape virtual destructor will be called.
        }
 
        // Polymorphic public methods
        string type();
        float  area();
        float  perimeter();
 
protected:
        float width;
        float length;
};
 
Rectangle::Rectangle(float theWidth, float theLength) : width(theWidth), length(theLength)
{
    // Constructor uses initialisation list rather than initialising members in constuctor.
    // See Circle constructor for reasons why.
}
 
string Rectangle::type()     { return "Rectangle";             }
float Rectangle::area()      { return width * length;          }
float Rectangle::perimeter() { return 2.0f * (width + length); }
 
 
int main()
{
    // Create an array of 10 pointers to Shape objects
    // Note: The shape objects are not instantiated to any specific class as yet!
    // In fact, as Shape is now an abstract class we CANNOT instantiate an object of type Shape!
    // That is, the following would cause a compile-time error: Shape myShape;
    Shape *shapes[10];
 
    // Create 5 Circles
    shapes[0] = new Circle(1.0f);
    shapes[1] = new Circle(2.0f);
    shapes[2] = new Circle(3.0f);
    shapes[3] = new Circle(4.0f);
    shapes[4] = new Circle(5.0f);
 
    // Create 5 Rectangles
    shapes[5] = new Rectangle(1.0f,  2.0f);
    shapes[6] = new Rectangle(2.0f,  4.0f);
    shapes[7] = new Rectangle(4.0f,  8.0f);
    shapes[8] = new Rectangle(8.0f,  16.0f);
    shapes[9] = new Rectangle(16.0f, 32.0f);
 
    // Print the shape object details for each object
    for (int loop = 0; loop < 10; loop++)
    {
        string type      = shapes[loop]->type();
        float  area      = shapes[loop]->area();
        float  perimeter = shapes[loop]->perimeter();
 
        cout << "Shape[" << loop << "]'s type = " << type << ", area = " << area << ", perimeter = " << perimeter << endl;
    }
 
    // GOTCHA: We should NOT try to free the allocated pointer to the shapes array using:
    //      delete[] shapes;
    //
    // The reason being that the array of pointers to shapes was declared like this: Shape *shapes[10];
    // This means that the array of pointers to shapes is on the STACK and not the HEAP!
    // The objects themselves are on the heap, but the pointers to objects are on the stack and
    // as such don't need to (and shouldn't) be freed!
    //
    // Instead, we should free the memory used by each shape like this:
    // Note: As we have an array of pointers to Shapes, and Shape has a virtual destructor,
    // the derived class destructor will be called and then the base class destructor will be called.
    for (int loop = 0; loop < 10; loop++)
    {
        delete shapes[loop];
    }
 
    return 0;
}

What would happen if we did NOT declare Shape as an abstract class? Well, we’d have to provide implementations for the type(), area() and perimeter() methods for Shape – but that’s about it. The polymorphism part would still work, that is, we could still create an array of pointers to a Shape, and then instantiate each shape as a Circle or a Rectangle as we see fit – and the correct functions would execute for each derived class.

However, it makes good sense to declare Shape as an abstract class so that we can’t instantiate it (even if we wanted to), in the same way that we’d make a Car class abstract. You can’t go out and buy a Car – it’s generic. You can buy a Ford Escort, or a Hyundai i30 or even a Ferrari F40, but you can’t buy a car in the same way that you can’t (technically) eat food or drink beer.

Doesn’t stop me trying though. Cheers! =D

A Simple C++ OpenGL Shader Loader

Update: There’s a re-worked and improved version of this shader loading code here: https://r3dux.org/2015/01/a-simple-c-opengl-shader-loader-improved/ – you should probably use that instead of this.


I’ve been doing a bunch of OpenGL programming recently and wanted to create my own shader classes to make setting up shaders as easy as possible – so I did ;-) To create vertex and fragment shaders and tie them into a shader program you can just import the Shader.hpp and ShaderProgram.hpp classes and use code like the following:

// Set up vertex shader
Shader vertexShader(GL_VERTEX_SHADER);
vertexShader.loadFromFile("MyVertexShader.vert");
vertexShader.compile();
 
// Set up fragment shader
Shader fragmentShader(GL_FRAGMENT_SHADER);
fragmentShader.loadFromFile("MyFragmentShader.frag");
fragmentShader.compile();
 
// Set up shader program
shaderProgram = new ShaderProgram();
shaderProgram->attachShader(vertexShader);
shaderProgram->attachShader(fragmentShader);
shaderProgram->linkProgram();

There’s also a loadFromString(some-string-containing-GLSL-source-code) method, if that’s your preference.

The ShaderProgram class uses a string/int map as a key/value pair, so to add attributes or uniforms you just specify their name and they’ll have a location assigned to them:

// Add the shader attributes
shaderProgram->addAttribute("vVertex");
// ...
 
// Add the shader uniforms
shaderProgram->addUniform("pMatrix");
// ...

The ShaderProgram class then uses two methods called attribute and uniform to return the bound locations (you could argue that I should have called these methods getAttribute and getUniform – but I felt that just attribute and uniform were cleaner in use. Feel free to mod if you feel strongly about it). When binding vertex attribute pointers you can use code like this:

// Set up a vertex buffer object to hold the vertex position data
GLuint vertexBufferId;
glGenBuffers(1, &vertexBufferId);
glBindBuffer(GL_ARRAY_BUFFER, vertexBufferId);
glBufferData(GL_ARRAY_BUFFER, model.getVertexDataSizeBytes(), model.getVertexData(), GL_STATIC_DRAW);
 
// Set up the vertex attribute pointer for the vVertex attribute
glVertexAttribPointer(
    shaderProgram->attribute("vVertex"),  // Attribute location
    VERTEX_COMPONENTS,                    // Number of elements per vertex, here (x,y,z), so 3
    GL_FLOAT,                             // Data type of each element
    GL_FALSE,                             // Normalised?
    0,                                    // Stride
    0                                     // Offset
);

Finally, when drawing your geometry you can get just enable the shader program, provide the location and data for bound uniforms, and then disable it like this (I’m using the GL Mathematics library for matrices – you can use anything you fancy):

shaderProgram->use();
 
    // Provide uniform data
    glUniformMatrix4fv( shaderProgram->uniform("mMatrix"), 1, GL_FALSE, glm::value_ptr(mMatrix) );
    // ...
 
    // Draw stuff
 
shaderProgram->disable();

That’s pretty much it – nice and simple. I haven’t done anything with geometry shaders yet so I’ve no idea if there’s anything else you’ll need, but if so it likely won’t be too tricky a job to implement it yourself. Anyways, you can look at the source code for the classes themselves below, and I’ll put the two classes in a zip file here: ShaderHelperClasses.zip.

As a final note, you can’t create anything shader-y without having a valid OpenGL rendering context (i.e. a window to draw stuff to) or the code will segfault – that’s just how it works. The easiest way around this if you want to keep a global ShaderProgram object around is to create it as a pointer (i.e. ShaderProgram *shaderProgram;) and then initialise it later on when you’ve got the window open with shaderProgram = new ShaderProgram(); like I’ve done above.

Cheers! =D

Source code after the jump…