A few weeks ago I tweeted the following:

I'm now doing issue driven development using Gogs.

It is *really* great, I can now measure how much I've done and plan better.

— Jonathan Müller (@foonathan) April 16, 2016

I was requested to give a review about it:

. @irrequietus I'll file an issue. :D

— Jonathan Müller (@foonathan) April 16, 2016

This is basically the workflow I’m doing for issue driven development.

Documentation is essential. Without knowing what certain functions/classes/… do, it is very difficult to use any code properly.

Tools can help to provide a documentation. They can extract information from the source code and combine it with manually written information to generate documentation in a human readable output format.

There is a problem though: The current tools for C++ documentation aren’t that great. This post explains why and provides a (work-in-progress) solution.

And apparently also about alliterations.

The last posts showed low-level techniques like ensuring inlining or removing branches.

But those techniques alone were not sufficient.

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool. The final post shows how to apply those techniques when designing your abstractions and the importance of smart algorithms.

Yes, exaggerated title.

Branches and conditional jumps are essential for every program, you cannot write anything but the most trivial code without them. Yet they sometimes have a certain overhead and can lead to problems in performance critical code paths.

It is often faster if they weren’t there. But how can you do that?

In this series, I’ll explain my changes and share some lessons about optimization I’ve learned in the process of beating Boost.Pool. This time its all about branches and a more detailed information about the detail::small_free_memory_list.

The C++ Standards Committee Papers of the post-Jacksonville mailing were recently published. There are few quite interesting ones that deal with the STL’s allocator model: P0177R1 - Cleaning up allocator_traits, P0178R0 - Allocators and swap(actually from February) and P0310R0 - Splitting node and array allocation in allocators.

In this post, I’d like to discuss those with you and explain why I really hope some of them they will accepted. The first parts are also a follow-up to AllocatorAwareContainer: Introduction and pitfalls of propagate_on_container_XXX defaults.