如何在私有成员的构造函数之间调用函数？

Question

I am writing a class to manage GLEW and GLFW for an OpenGL application. The frameworks need to be initialized in a particular order. The correct order is this:

#include <GL/glew.h>
#include <GLFW/glfw3.h>

glfwInit();
GLFWwindow* w = glfwCreateWindow(1280, 720, "main", 0, 0);
glfwMakeContextCurrent(w);
glewInit();
// GL API is now available

My class initializes the frameworks in its constructor:

class Engine
{
    struct GLEW { GLEW() { glewInit(); } };
    struct GLFW { GLFW() { glfwInit(); } };

    GLFW m_glfw;
    // Window::Window calls glfwCreateWindow and glfwMakeContextCurrent 
    Window m_window; 
    GLEW m_glew;
    // Program::Program requires GL API
    Program m_program; 

public:
    // a simplified version of the real ctor
    Engine(int width, int height, const char* name)
        : m_window(width, height, name)
    {
        m_window.setWindowUserPointer(this);
    }
};

I had to resort to GLEW and GLFW dummy structs to call the gl*wInit functions at the right time. This works, but is very brittle. The fact that my program's correctness depends on the precise order of the private members worries me.

It's important that glfwInit and glewInit are each called exactly once throughout the lifetime of the application, but I might create many instances of the Window and Program classes. It's assumed that the Engine class will be instantiated exactly once as well.

Is there a better way to do this? I specifically want to keep the framework initialization inside the Engine class. Equivalently, I don't want to, say, move the call to glfwInit inside Window::Window (that wouldn't make any sense since many windows may be created but glfwInit should be called exactly once).

Answer 1

In C++, initialization is the job of constructors, and cleanup is the job of destructors. For each successful initialization you generally want a corresponding cleanup action. The language mechanism automates that.

Using this language-provided support is known as RAII, Resource Acquisition Is Initialization .

• Create a C++ class for each (kind of) thing to be initialized & cleaned up.
• Express relationships for initialization orders, as constructor arguments, or as base classes.
• For initialization failure, throw an exception (so that there's no instance of this class).

Since the OpenGL stuff uses error codes you might consider std::system_error rather than just std::runtime_error ; the former (available since C++11) carries an error code.

Since glfwInit needs to be called once, globally, I would automate that call. One way is to place a static variable with initialization, inside a constructor of a class, with the header file declaring a dummy constant of that class. This ensures a single common initialization across compilation units.

Answer 2

If all you want to do is have actions performed only for the first Window instance created, you can use a static local:

Window::Window()
{
    static auto once = (glfwInit(), true);
    // other stuff
} 

If you want it done before Window's own initializer list, do it in a base class of Window .

Answer 3

When you have implicit order dependencies, you can always make them explicit using constructor parameters or other syntactic constraits. Make your GLFW and GLEW structs proper classes instead of internal dummies. Have your Window class require a GLFW parameter in the constructor. Have your GLEW class require a Window parameter in the constructor. Then you have no choice but to make sure you have those things available.

Finally, turn on the compiler warning that enforces correct initializer order in the constructor, and make it an error. Otherwise the error could still slip by undetected.

Answer 4

Rather than use your struct hack, it is almost always best to initialize your members explicitly:

...
public:
    // a simplified version of the real ctor
    Engine(int width, int height, const char* name)
        : m_glfw(initGlfw()),
        , m_window(width, height, name),
        , m_glew(initGlew())
    {
        m_window.setWindowUserPointer(this);
    }

...

Having your program rely on order of member objects is not a bad thing at all, and quite common in C++ code. If you are really worried, you can enable warnings to trigger if you do it wrong (in GCC: -Wreorder). The order they are declared, is the order they should be initialized.

Answer 5

What you have isn't bad, but I understand your concern....

One option would be to defer the window initialisation to the constructor body, which lets you use simple function calls for the other initialisation steps. Add to class Window a constructor that other client code couldn't call accidentally, that clearly documents deferred initialisation:

enum Construction { Deferred_Init };
explicit Window::Window(Init);
void init(int width, int height, const char* name);

Then inside Engine :

Engine(int width, int height, const char* name)
    : m_window(Deferred_Init)
{
    glfwInit();
    m_window.init(width, height, name);
    m_window.setWindowUserPointer(this);
    glewInit();
}

Alternatively, std::unique_ptr<Window>, std::optional , boost::optional` could all be used to defer construction.

---

Yet another option is to use a class to more obviously tie these member objects together, so they're unlikely to be accidentally reordered during code maintenance / evolution. Sadly, I can't see anything in the C++11 Standard guaranteeing std::tuple<> 's order of construction, but you could easily create something similar - perhaps called eg Ordered_Construction to communicate the intent. This would tend to make access to the data members a little less convenient....

---

You could also check the documentation for the error codes returned when the initialisation isn't done correctly, and make sure they trigger the program to close down in an orderly and impossible-to-ignore way if the initialisation was broken by a code change. Hopefully that would ensure any mistake was noticed before the code was released to users....