OpenGL version too low when using ifstream - c++

Question

I'm writing some elements of an engine for a 2D roguelike. I'm at a part where I'd like to be able to open .pngs. (I'm doing things manually because I like to learn about these things.) So I have created a PngLoader class and am starting to do basic things with it, like ... opening the file. For some reason this breaks the OpenGL GLFunctionFinder class that does something similar to GLEW, except manually.
The GLFF basically crashes out the program when the OpenGL version is too low; this is expected behavior. (Probably a segfault on an unset function pointer. I could "fix" this by making it crash more gracefully, but who cares?) The GLFF works rather well generally, since my graphics card runs OpenGL 4.3 or so, but I did have it break a few days ago when the driver switched to the integrated graphics driver (that only does OpenGL version 1.1). That was fixed by changing some settings in the graphics dashboard.
So the issue that I'm having crop up today is appearing when I write something like this:
class ifcontainerclass {
std::ifstream fs;
};
/* other code */
int WINAPI WinMain(/* ... */) {
GLFunctionFinder ff;
ff.interrogateWindows();
ifcontainerclass ifcc;
/* GL code and main loop */
return 0;
}
... the OpenGL context gets stuck on version 1.1. If I change ifstream to fstream, I get the higher version context that I expect, and the issue goes away.
I'm also finding in my testing that if I comment out the GL code and main loop area, the problem again disappears. The "version too low" checks are done in GLFunctionFinder::interrogateWindows(), not in the later GL code, so the conditions are still being checked. (After some testing, I'm finding that commenting out the MSG structure is what's making the problem go away.)
My current belief is the compiler is doing some magic that causes Windows / Intel / NVidia to only issue OpenGL 1.1 contexts / connect to the wrong driver when ... I really don't know when. The issue appears really arbitrary.
I'm probably going to look into getting rid of the global HDC and global HGLRC I was using out of laziness, since I think the problem is associated with how things are being initialized / how the compiler arranges to have these things initialized, and pulling them out of global scope will let me inspect and control that process more effectively. I did this in the GLFunctionFinder by using a static void * GlobalAddr = this file-scoped pointer, casting that to GLFunctionFinder in the dummy window's WndProc, and having HDC and HGLRC be member variables of GLFunctionFinder, accessible through the pointer. I will probably try something similar in my main window; I've been needing to clean up the global scoped stuff anyway. The other thing I can do is run each version in a debugger and see where it diverges, although I'm reluctant to do that since debugging is not really set up properly in my IDE and I'm not looking forward to fixing that.
I think I can get by in the meantime by using fstream instead of ifstream, but I'm not comfortable with not understanding problems that are this strange, since it suggests some kind of instability I ought to be aware of before I have 10k lines of code that arbitrarily stops running and can only be fixed by changing what appears to be a completely unrelated thing somewhere else.
Questions:
What in the world is happening? What is the core issue here?
Why does changing ifstream to fstream fix the problem?
Why does commenting out the MSG struct fix the problem?
PS: NvOptimusEnablement = 0x00000001 did not fix the issue.
PPS: MinGW 4.9.2 in Qt (as an IDE, no Qt libraries) with CMake
Edit: After determining Qt's debugger works when -ggdb is passed to g++, I stepped through the code and found the PIXELFORMATDESCRIPTOR in GLFunctionFinder was not being assigned; I was assigning the properties to some random temporary variable and not the member variable, while ChoosePixelFormat was using the member variable. Since the context you get depends on the kind of pixel you specify, I was effectively requesting an indeterminate device context from Windows. The specifics of compilation determined what random junk got put in the PIXELFORMATDESCRIPTOR, and it just so happens that declaring an ifstream instead of an fstream puts the wrong random junk in that area.
The problem was fixed by adding something to the effect of this->pfd_ = pfd; to GLFunctionFinder's constructor after defining the temporary pfd.
Edit 2: To satisfy my understanding of what the "off-topic" flag means, I'll provide a minimum example of the core problem:
main.cpp:
#include <windows.h>
#include <sstream>
#include <GL/gl.h>
HDC h_dc;
HGLRC h_context;
LRESULT CALLBACK MainWndProc(_In_ HWND h_wnd,
_In_ UINT u_msg,
_In_ WPARAM w_param,
_In_ LPARAM l_param) {
switch(u_msg) {
case WM_CREATE: {
PIXELFORMATDESCRIPTOR pfd; // <-- This was the error source, (pfd not set to an
// accelerated format, but only sometimes)
// except in my code it was harder to see than
// this.
h_dc = GetDC(h_wnd);
int pfint = ChoosePixelFormat(h_dc, &pfd);
SetPixelFormat(h_dc, pfint, &pfd);
h_context = wglCreateContext(h_dc);
wglMakeCurrent(h_dc, h_context);
const unsigned char * version_string =
static_cast<const unsigned char *>(glGetString(GL_VERSION));
if(version_string[0] == '1' || version_string[0] == '2') {
std::stringstream ss;
ss << "OpenGL version (" << version_string << ") is too low";
MessageBox(NULL, ss.str().c_str(), "Error", MB_OK | MB_ICONERROR);
}
break;
}
case WM_DESTROY:
PostQuitMessage(EXIT_SUCCESS);
break;
default:
return DefWindowProc(h_wnd, u_msg, w_param, l_param);
}
return 1;
}
int WINAPI WinMain( HINSTANCE h_inst,
HINSTANCE h_previnst,
LPSTR cmd_str_in,
int cmd_show_opt) {
WNDCLASSEX wc;
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_OWNDC;
wc.lpfnWndProc = MainWndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = h_inst;
wc.hIcon = NULL;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_BACKGROUND + 1);
wc.lpszMenuName = NULL;
wc.lpszClassName = "MAINWIN";
wc.hIconSm = NULL;
RegisterClassEx(&wc);
HWND h_wnd = CreateWindowEx(0,
"MAINWIN",
"MCVE Program",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
640,
480,
NULL,
NULL,
h_inst,
NULL);
return EXIT_SUCCESS;
}
CMakeLists.txt:
project(mcve_pfd_problem)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} WIN32 ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} opengl32)
In case someone skips to the end, the problem is solved, but I don't know how I'm supposed to indicate that.

Answer 1

So, what I was actually seeing was the effect of undefined behavior due to default-initializing a struct, where the values contained in it were uninitialized:
class GLFunctionFinder {
PIXELFORMATDESCRIPTOR pfdarr_;
/* other code */
GLFunctionFinder();
setupContext();
/* other code */
}
GLFunctionFinder::GLFunctionFinder() {
/* other code */
PIXELFORMATDESCRIPTOR pfd = { /* things */ };
// Missing: pfdarr_ = pfd;
// pfdarr_ never gets set
}
GLFunctionFinder::setupContext() {
// Undefined behavior:
int px_format_default = ChoosePixelFormat(this->h_cd, &(this->pfdarr_));
/* other code */
}
This gave ChoosePixelFormat whatever junk was in pfdarr_. When I initially wrote this, it behaved as though there was no problem, because apparently the junk data "looked like" an accelerated pixel format type, and ChoosePixelFormat would give me an int format that yielded the OpenGL context I was after. It stayed like that for a while, because it just kept working.
Switching from fstream to ifstream changed some specifics about the way the compiler laid out / optimized the program, and the junk data in pfdarr_ changed to "look like" an unaccelerated format. This led to getting the wrong context, which led to failing the OpenGL version check. The story with commenting out the MSG struct and part of the event loop is basically the same: it just so happens the compiler emits something that yields the OpenGL context I want.
I was compiling the code I gave in Edit 2 last night, and it was giving me a 1.1 context. This morning, exact same code, no error; moved the MessageBox and found I'm getting a 4.3 context. Fun errors.