The kind of OpenGL windowing that I refer to is like GLFW, GLUT, SDL, etc.

Imagine three C++ programs: (ignore syntax)

Game A:

class Game

Game B:


Game C:

class Key
class Display

In A, everything is in one class, in B nothing is in a class, and in C the two events have their own classes. Another that is not shown is subclassing a provided 'Game' class that has predefined functions overloaded.

I would like any reasonable means that can allow the main library to delegate out to each of these three cases. The solution should not require separate storage of a 'this' parameter.

I have thought of a couple of ideas, one is a way of mapping the function in a functor. Another was lambdas. Lambdas are not okay, because they are not widely implemented yet. (Compilers of choice are VC 2010, gcc (latest stable), and Apple's clang).

Any new C++ 2011 features that are widely implemented are reasonable thoughts.

A gentleman at the local university suggested something similar to the functor, but I cannot remember the function he was talking about.

  • 1
    A. is a god-object and B. will run into troubles with multiple windows and threading.
    – Pubby
    Oct 4, 2011 at 23:08
  • Quite right. Each one has their place. I would use B definitely in a little program that was to be quick to make. In the slightly larger case, A is what I am using for my current project. It should be noted that B is how GLUT and GLFW work. Oct 4, 2011 at 23:14
  • What is the reason for not wanting to store a 'this' parameter? Have you looked at the Adapter design pattern?
    – k rey
    Oct 11, 2011 at 17:39
  • I guess that it is impossible to create a code that encapsulates all the data in a way that you can have absolute no assumptions about how the things work. One thing of another must be known about the functionality being provided.
    – Victor
    Oct 25, 2011 at 0:32
  • Belongs on Stack Overflow.
    – DeadMG
    Jan 1, 2012 at 18:31

2 Answers 2


I have thought of a couple of ideas, one is a way of mapping the function in a functor.

std::function -> problem solved. If you have a compiler that doesn't support std::function, then use boost::function. Lambdas have nothing to do with it- if you're using a compiler that supports them then you can do it, else use boost::bind.


It is not very clear what your true intention is. However, describing you based on some assumptions.

Before you think of a methods - you need to define the abstraction of the core objects - such as Windows, surfaces, canvas and the device layer which would do the rendering. I believe the inputs (such as key board and mouse) would be objects as well. A good deal of work is to represent hardware - and while many are attempting to do it, it is not that universal thing.

If you are wanting to create GUI type framework than there will be whole object hierarchies like buttons and form elements etc. If you intend to do this for the class of rendering (what openGL actually aims to) you have higher level representations of Square and Triangles and how do draw Textures on them!

Once, you sort this out you need to define their behavior of inputs and outputs they will take and define which other objects they will deal with using the other API.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.