cmake is not great, but it doesn’t matter

cmake, the language is not great. It is just not a pleasant tool to work with. Not at all; it feels like it was not designed as a language, but a mere configuration file that sets build options in a compiler-agnostic way. But, it hits many important bullet points for building software and most importantly: “just works”. As a result, it has gained popularity over the years because cmake, the software is quite good.

As it happens often, control structures began to creep into the configuration file. This little if won’t hurt anyone, and look, I can do conditional steps during the build file generation with it! How about a for loop? We don’t even have to add an array type, we can just treat strings as arrays! Regex? Sure, add some Cthulhu curse while you are at it. And so on.

And still, despite being a pretty bad patchwork of a language (certainly worse than PHP for that matter), cmake is slowly but surely becoming the de-facto standard build system for C++ projects. Even Boost is replacing bjam with cmake. Why is this happening? Continue reading →

Murmur3 hash as a constexpr function

C++14 relaxed many restrictions on constexpr functions. The ability to contain branching, loops, switch statements makes them really easy to use. Implementing complicated functions at compile time is now a piece of cake.

To prove this point, I tried and implemented Murmur3A, the Murmur3 hash variant which is optimized for x861 and computes 32 bit hash values. In this post I’m going to walk through the steps of the implementation.

Continue reading →

  1. Not that this matters for constexpr; the point is, it computes the same values as that version of the algorithm does 

Turning a legacy MFC DLL project into EXE

Recently I had to convert a MFC DLL project to EXE. At first, this appears to be an easy task, since MFC abstracts the entry point of the application, right? The answer, as always with MFC is an awkward “yeeeaah…. but”. In this post I’m detailing all the steps that need to be taken to successfully convert your DLL into a EXE project, possibly saving some hairpulling if you need to do the same.

During this project I used Microsoft Visual Studio 2010, but the steps most likely apply to later versions as well (and possibly older ones, too).

The obvious

The most obvious step is changing the configuration type of the project from DLL to EXE. To do this, open its properties (right click in the Solution Explorer -> Properties), then go to Configuration Properties -> General.


In the linker settings you will (probably) need to set the subsystem to Windows. I’m saying probably, because if you have an MFC DLL project there is a good chance it has some sort of GUI1.

To change the subsystem, (in the same dialog as above) go to Linker -> System and change the SubSystem setting:


So far, so good. In an ideal world, this would be all. Unfortunately, there are some additional steps.

The not-so-obvious

Remember how I mentioned in the introduction that MFC hides the application entry point? That is true and it does so by selecting the proper entry point in its source via preprocessor macro. That means if your project defines _AFXDLL or _WINDLL, you have to get rid of them; otherwise your exe will be linked with a DLL entry point and be impossible to run. In the configuration properties, look at C/C++ -> Preprocessor -> Preprocessor Definitions. I also suggest searching through all project files for these strings and dealing with any instances individually.

Secondly, there is a good chance that you MFC DLL project does not have a main window. But now that it’s a normal application, it will need one. If you don’t have a main window, many MFC functions will crash/fail an assertion or kill a puppy. However, often you don’t really want to create a main window, you just want to run your application-like DLL without a host process. Perhaps only displaying GUI when something special happens.

There are some ways to circumvent this. Unfortunately most of these ways involve writing lots of boilerplate due to the questionable design of MFC. My suggestion is to create and use an invisible window, something like this:

BOOL CMyMFCApplication::InitInstance()
    CWnd* mainWindow(new CWnd);
    mainWindow->m_hWnd = NULL;
    if (!mainWindow->CreateEx(0, AfxRegisterWndClass(0),
	_T("Hidden Window of MyMFCApplication"), WS_OVERLAPPED, 0, 0, 0, 0, NULL, NULL))
	logError("Could not create hidden window :(");
    m_pMainWnd = mainWindow;

    return TRUE;

One word of advice: make sure that you have a way of exiting your application. From here on, the application runs as long as the main window is open, which is hard to close when it’s hidden.

An optional step

Just to be sure, check the Linker -> General -> Output File setting. It might be hardcoded to a DLL filename. This is an error that the compiler does not report (it happily says that that your exe output is build with a particular filename when in fact it is not). The correct value is $(OutDir)$(TargetName)$(TargetExt) which you only need to change in rare cases.

The hairpulling

Now comes the fun part. If you did all of the above, your application will be built as an exe. However, when you try to run it, you will get an “Access Denied” or “invalid win32 executable” error. If you inspect the output of dumpbin /headers you will be horrified to learn that your EXE is still, in fact a DLL!

Dump of file MyMFCApplication.exe

PE signature found

File Type: DLL

             14C machine (x86)
               8 number of sections
        55BF7F4D time date stamp Mon Aug 03 16:48:45 2015
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
            2102 characteristics
                   32 bit word machine

             10B magic # (PE32)
           10.00 linker version
          B47600 size of code
          F7AC00 size of initialized data
               0 size of uninitialized data
          5841D6 entry point (105841D6) @ILT+61905(__DllMainCRTStartup@12)
            1000 base of code

What happens here? After copious amount of debugging I found that this is a Visual Studio 2010 bug (other versions might be affected, too). The problem is that even though the configuration type was changed in the project properties, there is still a flag that remained unchanged. To change it, you need to open your .vcxproj file in your favorite text editor and look for the XML tag <LinkDLL>. Change its value in all configurations where you want to build an EXE:


And that’s it! Now you should be able to run your application that was created from a DLL.

  1. if not, it might be a good idea to evaluate the cost of ditching MFC 

Emulating the static initialization blocks of Java in C++

What is a static initialization block?

In Java, there is a language construct called a static initialization block. The static initialization block will be called the first time the class is loaded by the Java runtime. For example, consider the following code snippet1:

Continue reading →

  1. The highlighting in this code snippet is different because highlight.js had problems with this rarely used construct. As a workaround, I used a GitHub Gist for displaying this snippet. 

Rarely known C++ constructs (part 1): Function try blocks

C++ has some language constructs that are rarely seen in use. These constructs have their own, valid uses, but should be used sparingly. As the now adage-status quote from The Old New Thing says:

Code is read much more often than it is written, so plan accordingly

In this series we will take a look at different instances of unusual C++ language constructs, shortly explaining their use-cases, syntax and pitfalls.

UPDATE: the series was moved to Dr. Dobbs! The rewritten, expanded first part is available here.

Implementing a code generator with libclang

[DOI: 10.5708/szelei.2014.A.1]


Click here to skip the introduction and see the code.

The following article covers the process of implementing a practical code generator for C++ in detail. You can find the full source code for the article on GitHub.

A code generator is a very useful asset in a larger C++ project. Due to the lack of introspection in the language, implementing the likes of reflection, script binding and serialization requires writing some sort of boilerplate that essentially keeps the data which is otherwise thrown away by the compiler. These solutions are either intrusive (heavily macro-based, thus hard to debug and require weird syntax in declarations) or fragile (the boilerplate must be constantly updated to follow the actual code, and might break without warning). One way to improve the robustness is to automate writing this boilerplate. In order to achieve this, we need to parse the code somehow, in other words, understand what information to keep. However, parsing C++ is an extremely complex task, and with the copious amount of weird corner cases, we are in for quite a ride if we attempt to do so. Continue reading →