advanced

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() {
    X.store(1, std::memory_order_relaxed)
    r1 = Y.load(std::memory_order_relaxed);
}
static void t2() {
    Y.store(1, 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() {
    X.store(1, std::memory_order_relaxed);
    atomic_thread_fence(std::memory_order_acq_rel);
    r1 = Y.load(std::memory_order_relaxed);
}
static void t2() {
    Y.store(1, std::memory_order_relaxed);
    atomic_thread_fence(std::memory_order_acq_rel);
    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? ...

Where will Evolution lead C++17?

The third part of my series about the proposals for Urbana is about the subgroup evolution:

Where will Evolution lead C++17?

by Jens Weller

From the article:

This is the third part in my series about the proposals for the current C++ committee meeting in Urbana. This time its all about the subgroup Evolution, which has the most papers, so this is only the first part. The previous parts were about concurrency, and Part 2 about core, networking, models and undefined behavior.

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

The second part of my series on the C++ Proposals for the next Committee meeting in Urbana:

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

by Jens Weller

From the Article:

The second part of my series about the proposals for Urbana, where the next C++ committee meeting will be held. The papers grand us a first view on a distant future - C++17...