cppast - A library to parse and work with the C++ AST

Last year I started standardese, a C++ documentation generator. In order to provide exact documentation, I need to parse C++ code. As I didn’t want to waste time implementing my own parser, which will take ages and don’t work most of the time, I opted to use libclang.

libclang is a C API that exposes the C++ abstract syntax tree (AST) which is built on top of clang. And clang is a good and conforming C++ compiler, so I expected an interface to read the AST that just works and give me the information I need.

Well, I was wrong. Here’s why and how I solved it.

» read more »
Author's profile picture Jonathan

std::string_view accepting temporaries: good idea or horrible pitfall?

C++17 brings us std::string_view. It is a really useful tool: If you want to write a function accepting some string, but does not need ownership, i.e. a view, use std::string_view. It supports both const char* and std::string without any work, and does not involve any heap allocations. Further, it clearly signals intent: this function takes a view. It doesn’t own anything, it just views it.

As someone who frequently advocates for using correct types, I am happy about std::string_view. Yet there is one design decisions that warrants a discussion: std::string_view silently views temporaries as well. This can create a problem if the view lives longer than the temporary, as the view now views already destroyed data.

Let’s look into the reasons behind this decision and what that means for using std::string_view.

» read more »
Author's profile picture Jonathan

Implementation Challenge flag_set: Type-safe, hard to misuse bitmask

Sometimes when writing an API you need to pass various flags to a function. For example, when opening a file you can pass information like whether or not the file is opened for reading, writing, binary, write at the end etc. And often those flags can be combined arbitrarily.

Usually you’d implement that by using a bitmask: Each flag is a bit in an integer, they can be set/reset and toggled with bitwise operations. However, the naive implementation isn’t very good: I’ll explain why and show you how to do it better.

» read more »
Author's profile picture Jonathan

Implementing a tuple_iterator

This post is part of a collaboration with Arne Mertz. Arne is a software Engineer at Zühlke and a clean code enthusiast with a focus on modern C++. You can find him online at Twitter and at his “Simplify C++!” blog. We’ve both written something about accessing std::tuple, but swapped our blogs - my post is over at his blog and his one follows here now:


Did you ever wonder how we could iterate over the contents of a std::tuple at runtime, similar to an array or std::vector? You may or may not see the need for such a functionality - this walkthrough shows a proof of concept and how you tackle problems like this in C++17.

» read more »
Author's profile picture Jonathan

The problem with policy-based design

Policy-based design is a great way for library authors to provide more flexibility to the user. Instead of hard coding certain behaviors, policy-based design provides various policies the users can select to customize the behavior. If done properly, a library author can accommodate all use cases with a single implementation.

I’m a big fan of policy-based design for that reason. Whenever there’s a possible trade-off, where multiple solutions are possible, each with their own set of advantages and disadvantages, I make the decision available to the user. Instead of favoring a certain use case, I favor all of them. This is for example what I did with my variant implementation.

However, policy-based design isn’t perfect. In particular, it has a great problem: It creates lots and lots of different and incompatible types.

» read more »
Author's profile picture Jonathan

Advertisement