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:

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: http://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:

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:

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:

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):

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…