Announcing the C++ Tour

C++ Tour Logo

I'm proud to officially announce the C++ Tour.[1]

The tour can be best explained by quoting our mission statement:

The goal of the C++ tour project is to create a new way of teaching C++.
First and foremost we want to target those, who already have some experience
in programming, but are new to C++ or return after a longer absence.

We want to guide through features of the language and standard library, showing
pitfalls and best practices. The tour will be split into chapters, each of which
contains lessons, teaching a single concept or language feature.
Every lesson will be accompanied by an interactive example, demonstrating the
concept and allowing for experimentation.

It'll be available from early next year (current content is a placeholder).

We are looking for help!

The tour is currently being built on,
we have a couple of tickets open looking for feedback.

Please give us a star and share the blog post!

Feel free to just chime in. We're looking for any help we can get to help make
the C++ tour a reality in a timely manner.

It's best to reach us over the Slack channel #cpp-tour on the CppLang slack (click here to join).

  1. The official announcement was done on CppCast and can be heard in Episode 129. ↩︎


Using clang on Windows

Update 1: Visual Studio 2017 works. Thanks to STL.

Disclaimer: This isn't about clang/C2, clang/C2 is Microsoft own fork of clang to work with their backend. This is using clang + llvm.

tl;dr: All the source is in this repository:

Recently Chrome decided to switch their Windows builds to use clang, exclusively. That got me intrigued to try it again, since my former experience of trying to use clang on Windows was rather mixed. However if it's good enough for Chrome, it surely must've improved!

Unfortunately, getting clang to compile MSVC based projects isn't as easy as just dropping in clang and changing a few flags. Let's get started.


You'll need:


Since I want to keep this build-system independent, I've setup a .bat script with all the required steps to compile a simple example. You can grab it here:

Open the build.bat and let's walk through it:

  • Set LLVMPath, VSPath and WinSDKPath to the installation paths of LLVM, VS 2017 and the current Windows Kit.
  • OUTPUT defines the name of the final .exe.
  • CFLAGS contains all your usual clang compiler flags, for our example I've kept them simple.
  • CPPFLAGS defines the include directories of the Universal CRT, C++ Standard Library and Windows SDK.
  • LDLIBS defines the library import paths for the Universal CRT, C++ Standard Library and Windows SDK.
  • MSEXT are the required flags to make clang act more like CL. Not required anymore, Visual Studio 2017 will work without.

The rest of the file is dedicated to compiling all .cc files in the current directory and linking them into an executable.

This example makes use of lld, LLVMs linker. It has a caveat, it's not yet able to fully emit PDBs, you might want to consider to keep using LINK.EXE until lld is fully ready. You can use your normal linking process, the output of clang is fully compatible.

Questions? @ArvidGerstmann on Twitter.


Is my output going to bash.exe or cmd.exe?

If you want to color the output of your terminal program in Windows, you might've noticed, that running it from different shells reacts differently.

cmd.exe does not recognize the ANSI escape sequences to change the foreground/background color, while bash.exe does not recognize Windows' SetConsoleTextAttribute. This poses a problem. A way to detect if the output is going to bash.exe or cmd.exe is required.

Fortunately, an old mail on the Cygwin mailing list[1] hinted to the fact that GetFileType for the console handle returned by GetStdHandle is different. And after a little testing, it in fact is! Equipped with this information, we can now distinguish between our output terminals:

HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
DWORD dwFiletype = GetFileType(hConsole);
if (dwFiletype == 0x3) {
    /* We're running in bash.exe */
} else if (dwFiletype == 0x2) {
    /* We're running in cmd.exe */

Questions? Criticism? Wanna talk? I'm @ArvidGerstmann on Twitter.

  1. Despite the author saying it's a bug, this isn't the case, as later emails in the thread confirm. ↩︎


Stop using #ifdef for configuration

Using #ifdef's to configure different conditional compilations is very error prone.

I believe we've all had the case where something was compiled, while it shouldn't have been, due to accidentally creating/including a #define of the same name or defining it to 0 while checking with #ifdef.

While I won't give you a solution to fix the flawed model of using the preprocessor for conditional inclusion, I'll give you a solution to make it less error prone:

  /* Do something in debug. */
  /* Do something in production. */

The USING macro requires each configuration macro to be explicitly defined to special ON or OFF values, or you'll get an error[1].

By simply defining USING to a mathematical expression and ON / OFF to be the operators, we'll get an error whenever an undefined or otherwise defined macro is tried to be used as an argument:

#define USING(x)        ((1 x 1) == 2)
#define ON              +
#define OFF             -

Comments, criticism? Drop me a tweet @ArvidGerstmann.

  1. Not entirely correct, but good enough for our case. ↩︎


C Wishlist: Inline Functions

This is the first piece of a series of posts describing a few, very easily solvable, shortcomings of the C language. And proposing a way to fix these.
This is purely done the fact that I'm currently working on a C compiler. While I've written a few compilers over the years, none was actually intended to be used in production. This time it's different!

I'm currently rewriting the expression parser of my compiler, to use the power of top down operator precedence parsing as described by Vaughan Pratt in his paper of the same name.

I'm defining token classes with structures, like this:

struct tok_class tok_add = { 10, add_nud, add_led };

when it glared me, that this could've been done a lot simpler, by declaring the function pointers inline:

struct tok_class tok_add = {
    .lbp = 10,
    .nud = ^int64_t(struct tok_info *t) {
        /* do work. */
        return 0;
    .led = ^int64_t(struct tok_info *t) {
        /* do work. */
        return 0;

I have chosen this syntax with a reason, since it resembles the already existing syntax for blocks. Which already are a C language extension, implemented in clang.

Unfortunately (or fortunately) blocks work a little different, they work like a std::function in C++. This would merely be syntactic sugar for a static function declaration of which the address is assigned to the function pointer.

Questions, criticism or just want to say hi? You can find me on Twitter @ArvidGerstmann.