Jump to content


Member Since 14 Dec 2013
Offline Last Active Today, 11:04 AM

Topics I've Started

Qt Creator does not honor CMAKE_MAKE_PROGRAM

30 September 2014 - 12:29 PM

I recently switched to Qt Creator as my IDE for gcc and MinGW builds. However I stumbled across a problem with the CMAKE_MAKE_PROGRAM variable.
I have compiled Ninja executables in my repository. I tell CMake to use the Ninja generator and call "set (CMAKE_MAKE_PROGRAM "${CMAKE_SOURCE_DIR}/buildtools/ninja/${platformdir}/ninja")" from the first CMakeLists.txt.
However, to build the code, Qt Creator simply invokes "ninja" and not my custom set executable like it is supposed to do.
Before switching to Qt Creator I was using Eclipse CDT which does not have any problems using the custom path for the make tool (there are some other issues though, which is why I want to switch to Qt Creator).

Has anybody experienced the same problem and by chance found a way to solve it (without changing the build steps manually every time)?

Passing shared_ptr between modules

25 May 2014 - 04:43 AM

I have a singleton class (EventManager) in a static lib that gets linked by both the .exe and a dynmic lib. Events are passed around as std::shared_ptr<IEvent>. The EventManager stores all queued events in a std::list and pops them out after handling them. This works fine as long as all events were added from the exe. If I add events from inside the DLL, pop_front throws an exception at the last event that was added from inside the DLL. It doesn't matter whether the DLL adds one event or 1000, only the one that was added last throws the exception.

This is the exception:

Debug Assertion Failed!

Program: ...ts\visual studio 2013\Projects\QueueTest\Debug\DynamicLib.dll
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c
Line: 1424

Expression: _pFirstBlock == pHead

I'm using the Visual Studio 2012 with compiler for this.

I know that you should not deallocate memory in any module other than the one that allocate the memory. However, from what I've read std::shared_ptr can be used to avoid this problem as it contains a pointer to the deleter for the memory.


I attached a sample project with this problem to this post.


Any ideas on how I can get the EventManager to work with events coming from a DLL?

[GLEW] Check available OpenGL version

19 May 2014 - 10:22 AM

The GLEW documentation states that you can check the available OpenGL version like this:

  /* Yay! OpenGL 1.3 is supported! */

So, as my code is using OpenGL 3.0 i used GLEW_VERSION_3_0 to see if the computer can run the program. However, when I tested it on an Thinkpad which uses an integrated Intel graphics card with support only up to OpenGL 2.1. GLEW_VERSION_3_0 was for some reason evaluated as true. Querying GL_MAJOR_VERSION and GL_MINOR_VERSION as well as GL_VERSION show the correct result (OpenGL 2.1).

I tested other GLEW_VERSION_X_X macros on this computer, you can see the results in the attached file.


Has anybody else experienced this before? It's not a big deal to create a workaround for it but I wonder what might cause it and if it happens on other graphic cards as well.