Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
A. is a god-object and B. will run into troubles with multiple windows and threading. – Pubby Oct 4 '11 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. – drakej Oct 4 '11 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 '11 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 '11 at 0:32
Belongs on Stack Overflow. – DeadMG Jan 1 '12 at 18:31

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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