Tutorial on Tag Dispatching—Crazy Eddie

Fresh on Crazy Eddie's Crazy C++ (fortunately not entirely true...):

Tutorial on tag dispatching

by Crazy Eddie

From the article:

... There’s been some confused notions passed around recently that lead me to think there needs to be more information about probably one of the simplest, most powerful metaprogramming techniques that exist in C++: tag dispatching. The reason tag dispatching is powerful is that it leverages the language and the compiler to do work for you so that you don’t have to. It’s a technique whereby you use overload resolution rules to decide between otherwise ambiguous functions.

Concepts and tags

The first part to understand with regard to tag dispatching is the idea of “concepts”...

A Tiny Metaprogramming Library—Manu S├ínchez

Manu Sánchez is proposing a little-big collaborative challenge to the C++ community. Learning how to build:

A Tiny Metaprogramming Library

by Manu Sánchez

The proposal:

I hope you like this idea. It’s not only me writing crazy meta-stuff, but everybody developing their own metaprogramming library, learning something new each week, and comparing the different approaches each one is taking. I’m the guy who writes this posts, but I can learn a lot with your Tiny Metaprogramming Libraries and your feedback.


Bring named parameters in modern C++—Marco Arena

I’m going to explore some of the classical ways to emulate named parameters in C++ as well as mention new approaches. Part of this work would not have been possible without Davide Di Gennaro's help and suggestions. An entire paragraph was written by Davide.

Bring named parameters in modern C++

by Marco Arena

From the article:

In programming, named parameters refer to a computer language’s support for function calls that clearly state the name of each parameter within the function call itself.[...]Several languages support named parameters (e.g. C#, Objective-C, …). C++ does not.[...]In this post, I’m going to explore some of the classical ways to emulate named parameters in C++ as well as mention new approaches.

Continuation Passing Style—whanhee

In case you missed it, from Functional C++:

Continuation Passing Style

by whanhee

From the article:

Continuation passing style (CPS) is a method of programming which allows for intricate manipulation of control flow while still maintaining functional purity.

Continuations can be used to implement a whole range of things from exceptions to coroutines, but today we’ll just introduce them and a few interesting and useful concepts...

As summarized in Wikipedia: "continuation-passing style (CPS) is a style of programming in which control is passed explicitly in the form of a continuation."



Quick Q: Is an acquire_release fence enough for Dekker synchronization?—StackOverflow

Quick A: No, because acq_rel doesn't prevent reordering a store to x followed by a load from y... seq_cst does.

Recently on SO:

Why isn't a C++11 acquire_release fence enough for Dekker synchronization?

The failure of Dekker-style synchronization is typically explained with reordering of instructions. I.e., if we write

atomic_int X;
atomic_int Y;
int r1, r2;
static void t1() {, std::memory_order_relaxed)
    r1 = Y.load(std::memory_order_relaxed);
static void t2() {, std::memory_order_relaxed)
    r2 = X.load(std::memory_order_relaxed);

Then the loads can be reordered with the stores, leading to r1==r2==0.

I was expecting an acquire_release fence to prevent this kind of reordering:

static void t1() {, std::memory_order_relaxed);
    r1 = Y.load(std::memory_order_relaxed);
static void t2() {, std::memory_order_relaxed);
    r2 = X.load(std::memory_order_relaxed);

The load cannot be moved above the fence and the store cannot be moved below the fence, and so the bad result should be prevented.

However, experiments show r1==r2==0 can still occur. Is there a reordering-based explanation for this? Where's the flaw in my reasoning?

New optimizations for X86 in upcoming GCC 5.0—Evgeny Stupachenko

Fresh on the Intel Developer Zone blog:

New optimizations for X86 in upcoming GCC 5.0

by Evgeny Stupachenko

From the article:

Part 1. Vectorization of loads/stores group.

GCC 5.0 significantly improves vector code quality for load groups and store groups. By loads/stores group I mean iterated consecutive sequence of loads/stores. For example:

x = a[i], y = a[i + 1], z = a[i + 2] iterated by “i” is loads group of size 3


The most frequent case where loads/stores groups are applicable is array of structures.
  1. Image conversion (RGB structure to some other) ...
  2. N-dimentional coordinates. (Normalize array of XYZ points) ...
  3. Multiplication of vectors by constant matrix: ...

... GCC 5.0:

  1. Introduces vectorization of load/store groups of size 3
  2. Improves load groups vectorization for all supported sizes
  3. Maximizes load/store groups performance by generating code that is more optimal for particular x86 CPU...


ODE simulations with Boost.odeint and Boost.SIMD

A very nice article on how to use boost::odeint and SIMD:

Boosting ODE simulations with Boost.odeint and Boost.SIMD

by Mario Mulansky

From the article:

Ordinary Differential Equations appear in numerous applications and finding their solution is a fundamental problem in science and engineering. Often one has to rely on numerical methods to approximate such solutions as in the presence of nonlinearities, no analytic solution can be found. Being such a frequent problem...

Tiny Metaprogramming Library—Eric Niebler

eric-niebler-toronto.PNGWe like to link to articles at all levels. This one's near the top of the scale, for those looking for a real challenge:

Tiny Metaprogramming Library

by Eric Niebler

As the intro says [emphasis ours]:

(Difficult-to-grok metaprogramming below. Not for the faint of heart.)

From the rest of the introduction:

At the recent Urbana-Champaign meeting of the C++ Standardization Committee, Bill Seymour presented his paper N4115: Searching for Types in Parameter Packs which, as its name suggests, describes a library facility for, uh, searching for a type in a parameter pack, among other things. It suggests a template called packer to hold a parameter pack:

// A class template that just holds a parameter pack:
template <class... T> struct packer { };

Many of you are probably already familiar with such a facility, but under a different name:

// A class template that is just a list of types:
template <class... T> struct typelist { };

It became clear in the discussion about N4115 that C++ needs a standard typelist template and some utilities for manipulating them. But what utilities, exactly? ...