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 →
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.
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 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.
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:
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.
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
FILE HEADER VALUES
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
32 bit word machine
OPTIONAL HEADER VALUES
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:
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:
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 →