Michael Park

2019-01-22T00:00:00-00:00

Introduction

In 2015, I wrote an article titled Variant Visitation which described an implementation strategy for std::visit. The approach involved a matrix of function pointers, and many have raised concerns regarding poor code-gen caused by optimization limitations of function pointers on some compilers.

Here are a few that I remember:

Open GCC issue from Vittorio Romeo
Tweet from Jason Turner @lefticus
Blog post from Björn Fahller @bjorn_fahller
CppCon 2018 Talk from Nir Friedman quicknir
Several Reddit threads:
- Disappearing C++17 std::variant act
- std::variant code bloat? Looks like it’s std::visit fault (Part 1) (Part 2)
- When performance guarantees hurts performance: std::visit
- std::visit unable to generate optimal assembly
- std::visit overhead.

Anyway, it’s been on my list of things to do for a while. The motivation for action didn’t come however until a few months ago when Nir Friedman (quicknir) filed an issue on mpark/variant and generously offered to help with the effort!

This post describes the switch-based approach implemented in mpark/variant, and its benchmark results.

Variant

Let us get started with a minimal variant interface. This will give us a frame of reference throughout the post. We only need the following:

v.index(): Returns the index of the currently stored value.
std::get(v): Returns the currently stored value if v.index() == I else throws std::bad_variant_access.

Visitation

Here is the signature of visit:

template <typename F, typename... Vs>
constexpr decltype(auto) visit(F &&f, Vs &&... vs);

It performs f(std::get<Is>(vs)...) where Is... are the compile-time values of vs.index()....

Implementation

For single visitation in Variant Visitation, we generate a 1-dimensional array of function pointers where the function pointer at I performs f(std::get(v)). We can then invoke the function pointer at v.index().

In this implementation, we want to switch on v.index() instead and invoke f(std::get(v)) directly rather than through a function pointer. This should facilitate compilers that have trouble inlining function pointers.

Here’s a limited but simple example on GCC 8.2:

Single Visitation: Exactly 4 Alternatives

Let’s start with the following snippet:

template <typename F, typename V>
constexpr decltype(auto) visit(F &&f, V &&v) {
  switch (v.index()) {
    case 0: {
      return std::invoke(std::forward<F>(f), std::get<0>(std::forward<V>(v)));
    }
    case 1: {
      return std::invoke(std::forward<F>(f), std::get<1>(std::forward<V>(v)));
    }
    case 2: {
      return std::invoke(std::forward<F>(f), std::get<2>(std::forward<V>(v)));
    }
    case 3: {
      return std::invoke(std::forward<F>(f), std::get<3>(std::forward<V>(v)));
    }
  }
}

As discussed, we switch on v.index() and perform f(std::get(v)). This however only works for variants with exactly 4 alternatives 😅.

Single Visitation: Up to 4 Alternatives

To do this, we need to detect and disable the invalid branches. We’ll introduce a struct dispatcher templated on bool IsValid, where the false specialization contains the invalid code path declared __builtin_unreachable(); so that compilers know they can safely optimize it out, and the true specialization performs the valid code paths.

template <bool IsValid, typename R>
struct dispatcher;

template <typename R>
struct dispatcher<false, R> {
  template <std::size_t I, typename F, typename V>
  static R case_(F &&, V &&) { __builtin_unreachable(); }
};

template <typename R>
struct dispatcher<true, R> {
  template <std::size_t I, typename F, typename V>
  static R case_(F &&f, V &&v) {
    using Expected = R;
    using Actual = decltype(
        std::invoke(std::forward<F>(f), std::get<I>(std::forward<V>(v))));
    static_assert(
        std::is_same_v<Expected, Actual>,
        "`mpark::visit` requires the visitor to have a single return type");
    return std::invoke(std::forward<F>(f), std::get<I>(std::forward<V>(v)));
  }
};

In visit, we call this conditional case_ function by checking whether the case index is within std::variant_size_v. If the case is valid, we invoke f with std::get(v) as before. Otherwise it’s unreachable.

  template <typename F, typename V>
  constexpr decltype(auto) visit(F &&f, V &&v) {
+   using R = decltype(
+       std::invoke(std::forward<F>(f), std::get<0>(std::forward<V>(v))));
+   constexpr std::size_t size = std::variant_size_v<std::remove_cvref_t<V>>;
    switch (v.index()) {
      case 0: {
-       return std::invoke(std::forward<F>(f), std::get<0>(std::forward<V>(v)));
+       return dispatcher<0 < size, R>::template case_<0>(
+           std::forward<F>(f), std::forward<V>(v));
      }
      case 1: {
-       return std::invoke(std::forward<F>(f), std::get<1>(std::forward<V>(v)));
+       return dispatcher<1 < size, R>::template case_<1>(
+           std::forward<F>(f), std::forward<V>(v));
      }
      case 2: {
-       return std::invoke(std::forward<F>(f), std::get<2>(std::forward<V>(v)));
+       return dispatcher<2 < size, R>::template case_<2>(
+           std::forward<F>(f), std::forward<V>(v));
      }
      case 3: {
-       return std::invoke(std::forward<F>(f), std::get<3>(std::forward<V>(v)));
+       return dispatcher<3 < size, R>::template case_<3>(
+           std::forward<F>(f), std::forward<V>(v));
      }
    }
  }

At this point, we can visit variants with upto 4 alternatives. Next let’s enable visiting variants with arbitrary number of alternatives.

Single Visitation: Arbitrary # of Alternatives

In the above example, we only handled cases 0 through 3. Since there is no such thing as a variadic switch statement, we need to instead use recursion to handle the next range of values 4 through 7, and continue on until we’ve covered all of the valid cases.

We’ll do this by modifying the switch statement to handle the same range of values but adjusted by a base number. That is, given a base B, each recursive call will handle B+0, B+1, B+2, B+3. The initial value for B will be 0, and each recursive call will increment B by 4. We can continue while B is within a value range, i.e., B is within std::variant_size_v.

That means we have another pair of valid/invalid code paths to consider. Let’s call it switch_, to complement the case_ we already have:

  template <bool IsValid, typename R>
  struct dispatcher;

  template <typename R>
  struct dispatcher<false, R> {
    template <std::size_t I, typename F, typename V>
    static constexpr R case_(F &&, V &&) { __builtin_unreachable(); }

+   template <std::size_t B, typename F, typename V>
+   static constexpr R switch_(F &&, V &&) { __builtin_unreachable(); }
  };

  template <typename R>
  struct dispatcher<true, R> {
    template <std::size_t I, typename F, typename V>
    static constexpr R case_(F &&f, V &&v) {
      using Expected = R;
      using Actual = decltype(
          std::invoke(std::forward<F>(f), std::get<I>(std::forward<V>(v))));
      static_assert(
          std::is_same_v<Expected, Actual>,
          "`mpark::visit` requires the visitor to have a single return type");
      return std::invoke(std::forward<F>(f), std::get<I>(std::forward<V>(v)));
    }

+   template <std::size_t B, typename F, typename V>
+   static constexpr R switch_(F &&f, V &&v) {
-     using R = decltype(
-         std::invoke(std::forward<F>(f), std::get<0>(std::forward<V>(v))));
      constexpr std::size_t size = std::variant_size_v<std::remove_cvref_t<V>>;
      switch (v.index()) {
        case B+0: {
-         return dispatcher<0 < size, R>::template case_<0>(
+         return dispatcher<B+0 < size, R>::template case_<B+0>(
              std::forward<F>(f), std::forward<V>(v));
        }
        case B+1: {
-         return dispatcher<1 < size, R>::template case_<1>(
+         return dispatcher<B+1 < size, R>::template case_<B+1>(
              std::forward<F>(f), std::forward<V>(v));
        }
        case B+2: {
-         return dispatcher<2 < size, R>::template case_<2>(
+         return dispatcher<B+2 < size, R>::template case_<B+2>(
              std::forward<F>(f), std::forward<V>(v));
        }
        case B+3: {
-         return dispatcher<3 < size, R>::template case_<3>(
+         return dispatcher<B+3 < size, R>::template case_<B+3>(
              std::forward<F>(f), std::forward<V>(v));
        }
+       default: {
+         return dispatcher<B+4 < size, R>::template switch_<B+4>(
+             std::forward<F>(f), std::forward<V>(v));
+       }
      }
+   }
  };

With this mechanism in place, visit simply bootstraps the recursion.

  template <typename F, typename V>
  constexpr decltype(auto) visit(F &&f, V &&v) {
    using R = decltype(
        std::invoke(std::forward<F>(f), std::get<0>(std::forward<V>(v))));
+   return dispatcher<true, R>::template switch_<0>(std::forward<F>(v),
+                                                   std::forward<V>(v));
  }

Great! We’ve got single visitation supporting arbitrary number of alternatives. While I showed each recursive level handling 4 cases, the actual implementation handles 32 cases at a time.

Multi-visitation

Even though multi-visitation is currently implemented with a generalized version of this technique, I’ll leave the details for another post since there’s more work to be done. Specifically, I want to investigate some compile-time improvements and add some benchmarks for runtime performance.

Benchmark

The following benchmarking code is what the measurements are based on, and is inspired by the one that Björn Fahller presented in his blog post: When performance guarantees hurts performance - std::visit.

The benchmark creates a vector of approximately 5000 variants with N alternatives, and sums up the compile-time indices that are assigned to each variant. The idea being that if the visitor is inlined for the switch and out-of-line for jump table, switch should perform better.

#include <benchmark/benchmark.h>

#include <cstddef>
#include <type_traits>
#include <vector>

#include <mpark/variant.hpp>

template <std::size_t I>
using size_constant = std::integral_constant<std::size_t, I>;

template <std::size_t... Is>
auto make_variants(lib::index_sequence<Is...>) {
  std::vector<mpark::variant<size_constant<Is>...>> vs;
  for (std::size_t i = 0; i < 5000 / sizeof...(Is); ++i) {
    int dummy[] = {(vs.push_back(size_constant<Is>{}), 0)...};
    (void)dummy;
  }
  return vs;
}

struct visitor {
  template <std::size_t I>
  constexpr std::size_t operator()(size_constant<I>) const {
    return I;
  }
};

template <std::size_t N>
static void visit1(benchmark::State &state) {
  auto vs = make_variants(lib::make_index_sequence<N>{});
  for (auto _ : state) {
    int sum = 0;
    for (const auto &v : vs) {
      sum += mpark::visit(visitor{}, v);
    }
    benchmark::DoNotOptimize(sum);
  }
}

BENCHMARK_TEMPLATE(visit1, 1);
BENCHMARK_TEMPLATE(visit1, 2);
BENCHMARK_TEMPLATE(visit1, 3);
BENCHMARK_TEMPLATE(visit1, 5);
// ...
BENCHMARK_TEMPLATE(visit1, 200);

This benchmark was only tested with GCC and Clang. GCC 4.8/4.9/5/6/7/8 and Clang 3.8/3.9/4.0/5.0/6.0/7 under each of C++11/14/17, as supported.

The following is the result for Clang 7 under C++17:

Jump Table

---------------------------------------------------
Benchmark            Time           CPU Iterations
---------------------------------------------------
visit1<1>         2847 ns       2847 ns     244887
visit1<2>        11459 ns      11455 ns      61324
visit1<3>        10127 ns      10125 ns      68804
visit1<5>        10607 ns      10604 ns      66159
visit1<8>        11363 ns      11360 ns      61668
visit1<15>       12432 ns      12431 ns      56413
visit1<32>       10590 ns      10590 ns      64951
visit1<65>       10595 ns      10593 ns      66403
visit1<128>      21990 ns      21985 ns      31979
visit1<200>      27180 ns      27174 ns      25770

Recursive `switch`

---------------------------------------------------
Benchmark            Time           CPU Iterations
---------------------------------------------------
visit1<1>         2846 ns       2845 ns     246770
visit1<2>         3405 ns       3404 ns     205871
visit1<3>         2934 ns       2933 ns     239269
visit1<5>         3815 ns       3814 ns     183281
visit1<8>         2935 ns       2935 ns     238622
visit1<15>        2950 ns       2950 ns     238193
visit1<32>        2927 ns       2927 ns     239187
visit1<65>        2954 ns       2954 ns     233865
visit1<128>       9570 ns       9570 ns      73112
visit1<200>       9635 ns       9635 ns      73103

The following is the result for GCC 8 under C++17:

Jump Table

---------------------------------------------------
Benchmark            Time           CPU Iterations
---------------------------------------------------
visit1<1>         2811 ns       2811 ns     248491
visit1<2>         9494 ns       9493 ns      73727
visit1<3>        11461 ns      11460 ns      60527
visit1<5>        11487 ns      11486 ns      60689
visit1<8>        11571 ns      11571 ns      61453
visit1<15>       11592 ns      11592 ns      60979
visit1<32>       12553 ns      12553 ns      56333
visit1<65>       10630 ns      10629 ns      65991
visit1<128>      17035 ns      17034 ns      40331
visit1<200>      18484 ns      18484 ns      37944

Recursive `switch`

---------------------------------------------------
Benchmark            Time           CPU Iterations
---------------------------------------------------
visit1<1>         2828 ns       2828 ns     247810
visit1<2>         4203 ns       4202 ns     167167
visit1<3>         2904 ns       2904 ns     241905
visit1<5>         2858 ns       2858 ns     245063
visit1<8>         3830 ns       3830 ns     182081
visit1<15>        2854 ns       2854 ns     245068
visit1<32>        3826 ns       3826 ns     181831
visit1<65>        6920 ns       6920 ns     102445
visit1<128>      12084 ns      12084 ns      57905
visit1<200>      14330 ns      14330 ns      48923

The full matrix of the benchmark results is captured in Travis CI.

Conclusion

Clang/GCC both benefit from roughly a 3x improvement in performance from the switch-based implementation strategy. Please reach out with your ideas for further improvements to the library! Thanks to Nir Friedman (quicknir) for contributions / discussions over the past few months in making this happen.

Thanks to Agustín “K-ballo” Bergé and Barry Revzin for reviewing this post!

Variant Visitation V2 was originally published by Michael Park at Michael Park on January 22, 2019.

2018-11-21T00:00:00-00:00

Introduction

A few weeks ago, the Fall 2018 C++ Committee meeting took place in San Diego. It was a record-breaking meeting with 274 papers submitted to the pre-meeting mailing and 180 people in attendance. As the number of authors grow, there seems to be an increasing interest in easily creating beautiful documents.

The format of papers vary widely - Plain Text, HTML, LaTeX, Bikeshed, MS Word, etc. Personally, I prefer the look and stability of a PDF document generated from LaTeX. My first paper, N3887 was indeed written in LaTeX: N3887.latex.

But writing LaTeX is a real pain. I couldn’t transfer my thoughts into LaTeX directly so I ended up writing in Google Docs first then converting to LaTeX afterwards. This was completely unreasonable so I started looking for ways to write Markdown instead. I soon came across Pandoc, which is a Swiss army knife that can convert basically any document format to another.

Today, I write my papers in Markdown, which gets translated to LaTeX then generated into a PDF document. Here’s the Tony Table for a snippet of P0655R1:

P0655R1.md	P0655R1.pdf

Project Structure

The paper sources live at mpark/wg21, and all of the relevant templates live in the data directory. Given a Pandoc Markdown file <paper>.md at the top-level, make <paper>.pdf generates PDF document via LaTeX at generated/<paper>.pdf and make <paper>.html generates HTML at generated/<paper>.html.

The following sections cover common elements and scenarios in C++ paper writing.

Title

The title is generated by a YAML metadata block.

---
title: "`visit<R>`: Explicit Return Type for `visit`"
document: P0655R1
date: 2018-07-09
audience: Library Evolution Group
author:
  - name: Michael Park
    email: <mcypark@gmail.com>
  - name: Agustín Bergé
    email: <agustinberge@gmail.com>
---

A table of contents is generated by default, but can also be explicitly set via toc: true in the YAML metadata block.

P1260R0.md	P1260R0.pdf
`--- title: "Pattern Matching" document: P1260R0 date: 2018-05-22 audience: Evolution author: - name: Michael Park email: <mcypark@gmail.com> toc: true ---`

The default depth is 3, but it can be modified with toc-depth: <N>.

---
title: "Pattern Matching"
document: P1260R0
date: 2018-05-22
audience: Evolution
author:
  - name: Michael Park
    email: <mcypark@gmail.com>
toc: true
toc-depth: 4
---

It can also be turned off via toc: false.

Markdown

For most of the document content itself, you should simply reach for the basic Markdown functionalities you probably already know, such as headers, lists, quotes, fenced code blocks, inline formatting (bold, italics, strikeout), etc.

You can also refer to the full Pandoc Markdown specification for extensions!

Code Examples

Code examples are written with cpp code blocks as you normally would. The thing to note is that the annotations that appear time to time in “Standardese C++” such as see below, unspecified, and INVOKE are formatted automatically without any decorations in the code.

```cpp
  template <class F, class... BoundArgs>
    unspecified bind(F&&, BoundArgs&&...);
  template <class R, class F, class... BoundArgs>
    unspecified bind(F&&, BoundArgs&&...);
```

Of course that means if you name a variable unspecified, it’ll unintentionally be italicized. At least for now… just, don’t do that 😅.

Tony Tables

Tony Tables are before/after tables showing the code we had to write without the proposed feature, and the code we get to write with the proposed feature.

While this post is merely about formatting C++ papers, I will say that if you don’t have Tony Tables in your paper, you’re likely not communicating the value of your feature as effectively as you could be.

Tony Tables are fenced Div blocks that open with ::: tonytable and close with :::. Fenced code blocks are the only elements that actually get added to Tony Tables, except that the last header (if any) before a fenced code block is attached to the cell above.

Here is an example Tony Table:

::: tonytable

### Before
```cpp
switch (x) {
  case 0: std::cout << "got zero"; break;
  case 1: std::cout << "got one"; break;
  default: std::cout << "don't care";
}
```

### After
```cpp
inspect (x) {
  0: std::cout << "got zero";
  1: std::cout << "got one";
  _: std::cout << "don't care";
}
```

:::

Each fenced code block element is pushed onto the current row of the table, and horizontal rules (---) are used to move to the next row. You can also control the width of a column by adding a width=<float> attribute to a header.

Here is a more elaborate example:

::: tonytable

### Before {width=.53}
```cpp
std::visit([&](auto&& x) {
  strm << "got auto: " << x;
}, v);
```

### After {width=.47}
```cpp
inspect (v) {
  <auto> x: strm << "got auto: " << x;
}
```

---

```cpp
std::visit([&](auto&& x) {
  using X = std::remove_cvref_t<decltype(x)>;
  if constexpr (C1<X>()) {
    strm << "got C1: " << x;
  } else if constexpr (C2<X>()) {
    strm << "got C2: " << x;
  }
}, v);
```

```cpp
inspect (v) {
  <C1> c1: strm << "got C1: " << c1;
  <C2> c2: strm << "got C2: " << c2;
}
```

:::

Proposed Wording

This section of the paper is generally where most diffs (code and wording) appear.

Code Changes

Code changes are written with diff code blocks as you normally would.

Unchanged: No marker
Added: + marker
Removed: - marker

```diff
// 20.3.4: tuple-like access to pair:
template <size_t I, class T1, class T2>
-  constexpr typename tuple_element<I, std::pair<T1, T2> >::type&
+  constexpr tuple_element_t<I, pair<T1, T2> >&
-    get(std::pair<T1, T2>&) noexcept;
+    get(pair<T1, T2>&) noexcept;
```

Wording Changes

Wording changes are written with fenced Div blocks (similar to Tony Tables) for large changes or bracketed Span for small changes.

Fenced Div blocks open with ::: add or ::: rm and close with ::::

> \pnum{1} Let _n_ be `sizeof...(Variants)`. Let `m` be a pack of _n_ values of type
> `size_t`. Such a pack is called valid if $0 \leq$ `m`_~i~_ <
> `variant_size_v<remove_reference_t<Variants`_~i~_`>>` for all $0 \leq i < n$.
> For each valid pack `m`, let _e_(`m`) denote the expression:
>
> > \small _`INVOKE`_`(std::forward<Visitor>(vis), get<m>(std::forward<Variants>(vars))...)` _// see 19.14.3_
>
> ::: add
> for the first form and
>
> > \small _`INVOKE`_`<R>(std::forward<Visitor>(vis), get<m>(std::forward<Variants>(vars))...)` _// see 19.14.3_
>
> for the second form.
> :::

Bracketed Span either looks like [<new text>]{.add} or [<old text>]{.rm}.

> \pnum{3} _Returns:_ _e_(`m`), where `m` is the pack for which `m`_~i~_ is
> `vars`_~i~_`.index()` for all $0 \leq i < n$. The return type is
> `decltype(`_e_(`m`)`)` [for the first form]{.add}.

Grammar Changes

Grammar changes are written with line blocks (|) in order to preserve the leading spaces.

> | *selection-statement:*
> |     `if constexpr`*~opt~* `(` *init-statement~opt~* *condition* `)` *statement*
> |     `if constexpr`*~opt~* `(` *init-statement~opt~* *condition* `)` *statement* `else` *statement*
> |     `switch (` *init-statement~opt~* *condition* `)` *statement*
> |     [`inspect constexpr`*~opt~* `(` *init-statement~opt~* *condition* `) {` *inspect-case-seq* `}`]{.add}
>
> ::: add
> | *inspect-case-seq:*
> |     *inspect-case*
> |     *inspect-case-seq* *inspect-case*
>
> | *inspect-case:*
> |     *attribute-specifier-seq~opt~* *inspect-pattern* *inspect-guard~opt~* `:` *statement*
>
> | *inspect-pattern:*
> |     *wildcard-pattern*
> |     *identifier-pattern*
> |     *constant-pattern*
> |     *structured-binding-pattern*
> |     *alternative-pattern*
> |     *binding-pattern*
> |     *extractor-pattern*
>
> | *inspect-guard:*
> |     `if (` *expression* `)`
> :::

References

Similar to Title, references are generated by a YAML metadata block.

---
references:
  - id: N3546
    citation-label: N3546
    title: "TransformationTraits Redux"
    author:
      family: Brown
      given: [Walter, E.]
    issued:
      year: 2013
    URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3546.pdf
  - id: N3655
    citation-label: N3655
    title: "TransformationTraits Redux, v2"
    author:
      family: Brown
      given: [Walter, E.]
    issued:
      year: 2013
    URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3655.pdf
  - id: N3797
    citation-label: N3797
    title: "Working Draft, Standard for Programming Language C++"
    author:
      family: Toit
      given: [Stefanus, Du]
    issued:
      year: 2013
    URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf
---

Citations

In-text citations look like this: [@<citation-label>]

# Introduction

This paper is inspired by [@N3655], section 3 of which was adopted at WG21's
2013 Bristol meeting. That section provided (as did its predecessor [@N3546])
template aliases for the result of _metafunctions_ in `<type_traits>`.
However, the broader question of analogous template aliases throughout
the remainder of the standard library was not addressed.

Final Remarks

In this post, I’ve covered the common elements that I’ve needed writing papers. Writing papers in Markdown has been a sigfinicant improvement for me in smoothly transferring my thoughts onto a paper. Perhaps it’ll be helpful to others as a framework as well 🙂

Also, most of what’s being done here is just Pandoc out of the box. Kudos to the Pandoc developers for an amazing tool!

How I format my C++ papers was originally published by Michael Park at Michael Park on November 16, 2018.

2017-08-08T00:00:00+00:00

An anecdote from benchmarking the compile time of mpark/variant, an implementation of std::variant for C++11/14/17.

Introduction

std::variant has a converting constructor that looks like this:

template <typename... Ts>
class variant {
  template <typename T>
  constexpr variant(T &&);
};

For this constructor, we need to determine which of the Ts... will be initialized with T. For std::variant, the behavior is defined as follows:

template <class T> constexpr variant(T&& t) noexcept(see below);

Let Tj be a type that is determined as follows: build an imaginary function FUN(Ti) for each alternative type Ti. The overload FUN(Tj) selected by overload resolution for the expression FUN(std::forward<T>(t)) defines the alternative Tj which is the type of the contained value after construction.

For example, given variant<int, std::string> v("hello");, we want to create an overload set FUN with int and std::string then manually perform overload resolution with an argument of type const char (&)[6].

The following is the initial approach I took for FUN:

template <typename Head, typename... Tail>
struct FUN;

// Base case.
template <typename Head>
struct FUN<Head> {
  Head operator()(Head) const;
};

// Recursive case.
template <typename Head, typename... Tail>
struct FUN : FUN<Tail...> {
  using FUN<Tail...>::operator();
  Head operator()(Head) const;
};

Then the winner of overload resolution can be determined using FUN like this:

using best_overload = std::result_of_t<FUN<int, std::string>(const char (&)[6])>;

The compile-time benchmark of variant’s converting constructor using this implementation looked like this on GCC 5:

A minimal example on Wandbox shows (via -ftime-report) that the cost of using this particular implementation of FUN at N = 350 is ~20s!

What’s so expensive…?

Determining the Source

The first thing I found is that commenting out the using declaration from the above example takes the compile time down to ~0.15s. So the recursive inheritance seems fine, and the using declaration could be the issue, but by not pulling in the parent operator() we’re also no longer performing overload resolution. Could it be the cost of overload resolution?

Well, the non-recursive, hand-rolled version of FUN which does perform overload resolution takes ~0.1s. Okay, it must be the using declaration.

Now what…?

Surrogate Call Function

When considering the overload set for a call to object of a class type, it’s not just the operator()s that get involved in the action.

For example, an implicit conversion operator to R (*)(P1, ..., PN) is also considered. They participate in overload resolution as surrogate call function with the unique name call-function and has the form:

using F = R (*)(P1, ..., PN);

R call-function(F f, P1 a1, ..., PN aN) { return f(a1, ..., aN); }

This is an example taken basically verbatim from [over.call.object]:

int f1(int);
int f2(float);

typedef int (*fp1)(int);
typedef int (*fp2)(float);

struct A {
  operator fp1() { return f1; }
  operator fp2() { return f2; }
} a;

int i = a(1);  // calls f1 via pointer returned from conversion function

How does this help us?

What’s in a Name?

Why did we need the using declaration in the initial approach, anyway? It’s due to the fact that the name of the overloaded function in that case was operator(), and FUN<T, Ts...>::operator() shadowed FUN<Ts...>::operator(). So we needed to pull the FUN<Ts...>::operator() name explicitly into FUN<T, Ts...>’s scope.

With surrogate call functions, the “pulling in” happens implicitly:

Similarly, surrogate call functions are added to the set of candidate functions for each non-explicit conversion function declared in a base class of T provided the function is not hidden within T by another intervening declaration.

As such, the “name” is essentially the type of the pointer to function.

Now, we can implement FUN like this:

template <typename Head, typename... Tail>
struct FUN;

// Base case.
template <typename Head>
struct FUN<Head> {
  using F = Head (*)(Head);
  operator F() const;
};

// Recursive case.
template <typename Head, typename... Tail>
struct FUN : FUN<Tail...> {
  using F = Head (*)(Head);
  operator F() const;
};

With this implementation, at N = 350 we get ~0.6s! MUCH better than ~20s.

Final Touch with Multiple Inheritance

Since the surrogate call functions are implicitly pulled in from the base classes, we don’t even need to keep the recursive inheritance anymore.

We can flatten, simplify, and improve the implementation with multiple inheritance:

template <typename T>
struct FUN_leaf {
  using F = T (*)(T);
  operator F() const;
};

template <typename... Ts>
struct FUN : FUN_leaf<Ts>... {};

Now, with this implementation, at N = 350 we get about ~0.2s! Not as drastic, but still a ~3x improvement.

Final Remarks

This issue was discovered while I was setting up MPark.Variant/Benchmark to compare the many variant implementations out there.

My hope is that this website will help to improve the community-wide implementation quality of variant by comparing existing implementations.

Take a look at the latest GCC 5 results to see the improvements that have been made to mpark/variant!

Thanks to Agustín “K-ballo” Bergé for introducing / explaining surrogate call functions to me.

Thanks to Louis Dionne and Bruno Dutra for developing the metabench framework and setting a precedent with metaben.ch!

`using` killed the `FUN` on GCC 5 was originally published by Michael Park at Michael Park on August 08, 2017.

2017-05-26T00:00:00+00:00

NOTE: Welp, this post is about 3 years late. But… it still seems to come up from time to time and the technique (trick?) doesn’t seem to be widely known, so I figure I should write it down.

Introduction

Since C++11, functions can be marked constexpr. What does this really mean? Well, it specifically does not mean that it will be evaluated at compile-time. It actually means that it is possible for it to be evaluated at compile-time.

Why is this important? Well, it means that the function needs to be written in such a way that the parameters can be compile-time or runtime values.

Consider the following contrived example:

constexpr void f(std::size_t n) {
  static_assert(n == 42, "");  // not allowed.
}

This function is not allowed because n could be a runtime value, in which case it would violate the requirement that static_assert must be given a constant expression.

Non-Type Template Parameter

The example above is pretty simple to fix though, since we can just make the function parameter be a non-type template parameter.

template <std::size_t N>
constexpr void f() {
  static_assert(N == 42, "");
}

Simple enough. But what if it’s a slightly more complex type, like std::tuple<int, int>? Maybe something like this…?

template <std::tuple<int, int> X>  // not allowed.
constexpr void f() {
  static_assert(std::get<0>(X) == 101, "");
  static_assert(std::get<1>(X) == 202, "");
}

This doesn’t work because we’re not allowed to pass an arbitrary literal type as a non-type template parameter.

N3413 proposes to allow arbitrary literal types for non-type template parameters.

Why does this restriction on non-type template parameters exist in the first place?

For one, C++ has a fundamental notion of “same type”. Given values x and y, we have to be able to answer whether foo<x> and foo<y> are the same type. Currently, the non-type template parameters are restricted such that this question can be answered using the built-in value equality comparison. Once user-defined literal types are involved, we have to be able to find a unique operator== across translation units to perform equality comparisons, and also mangle the same types to the same name. This potentially introduces a lot of complexity into the linker.

NOTE: This doesn’t cover the entirety of the issue since “same type” doesn’t cover function templates. For example, given the function template f above, f<std::make_tuple(101, 202)> and f<std::make_tuple(23, 24)> both have the type void (). Thanks tcanens for the reddit comment!

Can we get around this limitation?

Value-Encoded Type

The std::integral_constant class template takes a type and a value of that type. It essentially encodes the value as part of the type.

This isn’t directly helpful for us though, since the value still needs to meet the requirements of a non-type template parameter. However, the idea of shoving a value inside the type remains useful. We simply need a way to encode the value inside the type without the value being part of the type.

Okay, I admit that may be a bit confusing. Here is the code:

struct S {
  static constexpr auto value() { return std::make_tuple(101, 202); }
};

Here, we’ve created a type S that encodes the value std::make_tuple(101, 202) without the value actually being part of the type. The tuple(101, 202) is not really part of the type S, but we can extract the value from S (via S::value()). The compiler therefore must somehow associate the value with the type, which I consider to be a valid encoding.

We can then pass it into a function and use it like this:

template <typename X>
constexpr void f(X) {
  static_assert(std::get<0>(X::value()) == 101, "");
  static_assert(std::get<1>(X::value()) == 202, "");
}

int main() {
  struct S {
    static constexpr auto value() { return std::make_tuple(101, 202); }
  };
  f(S{});
}

Macros (< C++17)

I don’t like macros either. But at least this is a pretty simple one.

#define CONSTANT(...) \
  union { static constexpr auto value() { return __VA_ARGS__; } }

NOTE: Shout-out to @lichray for pointing out that anonymous struct is not part of the C++ standard in this tweet!

The above example can then be written like this:

template <typename X>
constexpr void f(X) {
  static_assert(std::get<0>(X::value()) == 101, "");
  static_assert(std::get<1>(X::value()) == 202, "");
}

int main() {
  using S = CONSTANT(std::make_tuple(101, 202));
  f(S{});
}

We could also have a version that returns an instance of such a type so that we don’t have to have a preceding using-declaration every time.

#define CONSTANT_VALUE(...) \
  [] { using R = CONSTANT(__VA_ARGS__); return R{}; }()

With this we could pass it directly to the function:

template <typename X>
constexpr void f(X) {
  static_assert(std::get<0>(X::value()) == 101, "");
  static_assert(std::get<1>(X::value()) == 202, "");
}

int main() {
  f(CONSTANT_VALUE(std::make_tuple(101, 202)));
}

Note that this macro introduces a new type for every value. We’re essentially “solving” the problem of performing equality comparison of literal types by punting it entirely and saying “they’re never equal”. For example,

auto x = CONSTANT_VALUE(42);
auto y = CONSTANT_VALUE(42);

static_assert(std::is_same<decltype(x), decltype(y)>::value, "");  // fail!

Initially, I was concerned about the potential of introducing too many types. But this is actually similar to how lambdas work. Specifically, lambdas that happen to be lexically equivalent don’t have the same type.

auto x = [] {};
auto y = [] {};

static_assert(std::is_same<decltype(x), decltype(y)>::value, "");  // fail!

It seems that “having too many types” may not be an issue.

Compile-Time String

Compile-time strings in the context of static reflection and metaprogramming are a point of discussion in the C++ committee. Meanwhile, this macro can be used to capture and pass around compile-time strings, or even a std::string_view.

#include <string_view>

template <typename StrView>
constexpr void f(StrView) {
  static_assert(StrView::value() == "hello", "");
}

int main() {
  using namespace std::literals;
  f(CONSTANT_VALUE("hello"sv));
}

This technique is also used in Boost.Hana to implement BOOST_HANA_STRING which came out of a conversation with Louis Dionne during our first meeting back in CppCon 2014 😊

C++17

Since we have constexpr lambdas in C++17, we can ditch the macros from above and pass around the lambdas directly. For example,

template <typename X>
constexpr void f(X x) {
  static_assert(std::get<0>(x()) == 101, "");
  static_assert(std::get<1>(x()) == 202, "");
}

int main() {
  f([] { return std::make_tuple(101, 202); });
}

Final Remarks

I’ve used this technique for mpark/format which is an experimental string format library where the format string is parsed and checked at compile-time.

I’d love to hear about your use cases if you find this useful!

Thanks to Louis Dionne for reviewing this post!

`constexpr` function parameters was originally published by Michael Park at Michael Park on May 26, 2017.

2017-05-20T00:00:00+00:00

I just returned from C++Now 2017 in Aspen, CO. This was my second time attending the conference and it was just as amazing as last year. My girlfriend decided to come along this time, since Aspen is such a beautiful place. We flew into Denver, rented a car and took the beautiful 4-hour drive into Aspen. She was very happy 🙃. Strongly recommended!

The week started like this:

Green grass, bright flowers, crisp air. Colorado is good for the soul.

A post shared by Amber (@audreydevotee) on May 19, 2017 at 8:09pm PDT

Talks

Here are most of the talks I attended, in chronological order.

C++17 Features - Bryce Lelbach

Bryce took a breadth-first approach of exploring C++17 features that are around the corner. They took a form of “Tony Tables”, where we saw a simple before-and-after of each feature. I was glad to find many compelling examples delievered in the talk. It helped me remind myself that although we didn’t get many of the major language features we were hoping for, we still got a lot of useful features into the language. A few highlights:

Language: structured bindings, if constexpr, class template deduction
Library: filesystem, string_view, optional, variant, any,

Expression Templates Everywhere with C++14 and Yap - Zach Laine

Zach presented his expression template library called Yap. It’s being proposed as a boost library as a modernization of Boost.Proto. He covered some of the common and compelling use cases of expression templates in the domain of mathematics, then went on to describe the machinery of yap.

If I need expression templates soon (and I think I might), I’m glad to know that there’s a modern libray solution for it 😊.

constexpr ALL the things! - Ben Deane, Jason Turner

Ben and Jason shared their experience in pushing the boundaries of constexpr. Exploring containers that can be used during compile-time and run-time, enumerating standard algorithms that can / should be marked constexpr, and standard defects (probably?) such as std::pair’s operator= not being marked constexpr. The relaxed constexpr in C++14 made these constexprs relevant, because now things can be modified, as long as they happen within a constexpr function.

The highlight of the talk was the compile-time parser framework built by Ben to parse JSON at compile-time. This was of particular interest to me because I’ve written a compile-time parser myself to parse format strings in experimenting with mpark/format. Needless to say, this was a very engaging talk for me.

The Mathematical Underpinnings of Promises in C++ - David Sankel

David talked about the mathematical approach of reasoning about futures and promises (although he sticks to calling them just promises). We first learned about denotational semantics and found that it’s not quite sufficient due to the introduction of time; we then moved onto using operational semantics to tackle the issue.

This talk was mainly focused on math, but it lead into his follow-up talk, Promises in C++: The Universal Glue for Asynchronous Programs, in which he describes his open source promise library that is based on this mathematical backing.

Postmodern Immutable Data Structures - Juan Pedro Bolivar Puente

Juan presented his persistent, immutable data structures library called immer. Functional languages have been promoting value semantics since the 1950s, and was part of C++ since its initial design. Most of us love value semantics because of the referential transparency it provides, making our programs much easier to reason about.

The issue of performance has gotten in the way of using value semantics in the past, and move semantics in C++11 made that a lot more practical. Juan takes this further by allowing objects to share views of common subcomponents. The result is that we get very efficient data structures that are very fast to compare, with a compact undo-history.

He also presented ewig, a text editor using these data structures. Demo involves opening and editing a very larg file. Two things stood out to me:

The text editor displays an asterisk when the file has been modified but not yet saved. When it is modified to be the same state as the original, the asterisk disappears immediately. This may not seem like a big deal, but it demonstrates that the original stayed in tact, and that the comparison is super fast.
Juan copy-pasted a large portion of the file a bunch of times, and the editor handled that with no problem whatsoever. He then stopped and told us something along the lines of, “at this point, if we were to save this file and re-open it, we wouldn’t have enough memory to read it back in”.

Impressive.

Type Based Template Metaprogramming is Not Dead - Odin Holmes

Odin presented kvasir, the fastest metaprogramming library out there, competing against others like meta, metal, mp11, and brigand. According to metaben.ch, it’s the fastest in every algorithm except cartesian product. metal takes that one, but Odin had an excuse for it 😜.

On a more serious note, he presented an empirical study of the cost of compile-time operations:

Compile time costs of various TMP techniques #cppnow pic.twitter.com/PpudMV9hV5
— Meeting C++ (@meetingcpp) May 17, 2017

Strategically paying for the cheaper compile-time operations is the secret to kvasir’s efficiency. I’ll need to remember this list to improve the compile-time for mpark/variant. Glad to have some general guidance here 😀.

Also, this was funny 😂:

"This is basically @ericniebler showing off", @odinthenerd on meta functions #cppnow pic.twitter.com/Ipxl4R984e
— Meeting C++ (@meetingcpp) May 17, 2017

Alright, so I think it was right about here when it looked like this outside 😳…

Snow!! In May!! Aspen is beautiful in all weather

A post shared by Amber (@audreydevotee) on May 21, 2017 at 8:51pm PDT

Middle of #cppnow. I look happy 😄 #cpp pic.twitter.com/X5VaIU6I7F
— Michael Park (@mcypark) May 22, 2017

Okay, back to the talks.

Call: A Library that Will Change the Way You Think about Function Invocations - Matt Calabrese

Matt presented his experimental call library that explores the space of function invocation, which in my opinion is a bit of a mess in C++ land currently.

Utilities such as std::apply, std::invoke, and std::visit all work great independently, but they don’t compose all that well.

He presented 3 hours worth of material, but this is the most basic issue:

In Python, we can say:

args = (1, 2, 3)
f(0, *args)

In C++, we have…

auto args = make_tuple(1, 2, 3);
apply([](auto&... args) { return f(0, args...); }, args);

This is way too complicated… With call, you can instead say:

auto args = make_tuple(1, 2, 3);
call(0, unpack(args));

Much better. The library does a lot more than this, but this is the beginning of its motivation.

The talk is based on his standards paper: A Single Generalization of std::invoke, std::apply, and std::visit.

Practical (?) Applications of Reflection - Jackie Kay

Jackie talked about reflection in other languages, followed by a comparison of P0194 “reflexpr” proposal, vs P0590 “operator $” proposal. She pointed out that the proposals currently only support introspection, and that in order to do really interesting things we’d need more.

She shared a bunch of examples that were tested with the current implementations in Clang, I’m really glad that she’s investing time to get practical experience with the proposals.

The talk is based on her popular blog posts: An Introduction to Reflection in C++ and Fun with Reflection in C++.

Locally Atomic Capabilities and How to Count Them - Lisa Lippincott

I went to Lisa’s talk last year, What is the basic interface? which won best session. This was a follow-up to that session, and it was just as engaging.

She formally discusses the nature of capabilities of functions divided into different “neighborhoods”. She makes an analogy to chemistry, where the essential atoms are preserved during the flow. In programming, “claim”s such as “destructible”, and “deallocatable”, exit a function like new, and enters a delete. By counting the flow of essential atoms, one can detect bugs that arise due to humans’ poor ability to perform non-local reasoning.

While I understood the gist of the talk, I’m sure I didn’t fully follow. So I’m already looking forward to watching it again on YouTube 🙂.

Beyond the Talks

The program was fantastic this year. Shout out to our program chair Bryce Lelbach, and all the speakers for their spectacular material.

Having said that, the real reason I attend C++Now is not because of the talks. As embarrassing as it is to admit, I missed all of the keynotes this year. But it’s okay. I can catch those on YouTube. (Sorry, keynote speakers! I’ll catch you on YouTube, I promise.)

What I cannot catch is the face-to-face interactions I get with the speakers and attendees, many of whom I consider to be good friends. C++Now is intentionally scheduled with a long lunch, and frequent, long breaks between sessions. People also hang out at the bar in the evenings, most nights into early morning. It’s ridiculous. I was up every night until 2am - 4am, discussing ideas, learning new concepts, having heated arguments, presenting my thoughts, and listening where I’m a novice.

It’s wonderful, and to me, this is the real magic of C++Now.

Also, a fun poll by Bryce, asking for the most desired features up to C++50:

Entirely non-serious C++-20 to C++-50 polls. Q0: Most desired #Cpp20 feature. #CppNow #Cpp @cppnow
— Bryce Lelbach (@blelbach) May 19, 2017

and a fun challenge:

What is the most interesting valid #Cpp17 code you can write with no alphanumeric characters other than 'o', 'u', 'a' and 't'? #CppNow
— Bryce Lelbach (@blelbach) May 19, 2017

Ah… what a week.

My Contribution

I gave a lightning talk entitled “MPark.Patterns: Pattern Matching in C++14”.

It’s a brief introduction of mpark/patterns which I’ve been working on in order to bring a clean pattern matching library to C++.

I started out with a few simple examples, and finished with a complex, red-black tree balancing code at the end:

My general feeling was that it was well received. Michael Caisse asked people to raise their hands if they thought the library was cool, and from what I saw, more than half of the room raised their hand! 😀

There’s some stuff that I didn’t get to present in the 5-minutes, of course. For example, the sum pattern allows matching on variant-like types, and the variadic pattern allows the power to implement std::apply, and std::visit. The real power of course is not just the ability to implement them, but rather the ability to compose them.

I’m planning to continue my work here and give a full session in the future. 🤓

The 4-hour drive back to Denver:

Aspen -> Denver #cppnow #cpp pic.twitter.com/VrEBpfQF6A
— Michael Park (@mcypark) May 22, 2017

Last but not Least

Thank you to the conference chair Jon Kalb for putting an excellent conference together every year.
Thanks to all of the conference staff and student volunteers.
Thanks to my employer Mesosphere for sponsoring me to attend!

C++Now 2017 was originally published by Michael Park at Michael Park on May 20, 2017.

2016-05-12T00:00:00+00:00

NOTE: If you’re writing ≥ C++11, reach for type alias rather than typedef declaration. The syntax matches what people naturally expect, and it also supports templated type aliases (i.e. alias template).

Introduction

The typedef declaration provides a way to create an alias for an existing type. For example, we can provide an alias for int called integer like so:

typedef int integer;

I imagine most people have seen such declarations, and they are fairly simple to read. In fact it’s so simple that we may incorrectly conclude that the syntax for typedef is:

typedef <existing_type> <new_type_name>;

This syntax works for simple cases, but at some point we encounter a typedef declaration that doesn’t quite meet our expectations:

typedef int (*function_pointer)(double);

This declares an alias for int (*)(double) (pointer to function) called function_pointer. This is clearly inconsistent with our earlier conclusion, since if it were, we would have seen the following instead:

typedef int (*)(double) function_pointer;

In an effort to keep the simple cases simple, many people understandably start to treat this as a special case. Until they encounter another weird one:

typedef int array[3];

Fine! Yet another special case. But what about…

typedef int integer, (*function_pointer)(double), array[3];

Huh…? Is this even legal? — Yes. Yes it is. — I’m NOT suggesting that you do this!

Seriously, how do we read these damn things?

Correct Reading

The misconception and mystery behind the reading of the typedef declaration lies in the seemingly innocent, but misleading simple examples. Here is the syntax for the typedef declaration according to cppreference:

typedef type_declaration;

The type_declaration after the typedef keyword is a simple declaration with some restrictions (e.g. cannot be declared static).

Refer to the Standardese section if you’re interested in some of the fine details.

Consider the following variable declarations:

int i;
int (*f)(double);
int a[3];

In variable declarations, the introduced names are instances of the corresponding types.

int i;             // `i` is an instance of `int`.
int (*f)(double);  // `f` is an instance of `int (*)(double)`.
int a[3];          // `a` is an instance of `int [3]`.

However, when the typedef keyword precedes the declaration, the introduced names are aliases of the corresponding types.

typedef int i;             // `i` is an alias of `int`.
typedef int (*f)(double);  // `f` is an alias of `int (*)(double)`.
typedef int a[3];          // `a` is an alias of `int [3]`.

Thus, the task of reading a typedef declaration can be delegated to reading a variable declaration then reinterpreting the names to be aliases of the corresponding types as opposed to instances of them!

Inaccurate Sources

Unfortunately, the source of the misunderstanding goes beyond us naively assuming the simple syntax.

Wikipedia article enumerates a bunch of scenarios. It makes it seem as if there is a special case for function pointers, for example.

Function pointers are somewhat different than all other types because the syntax does not follow the pattern typedef <old type name> <new alias>;. Instead, the new alias for the type appears in the middle between the return type (on the left) and the argument types (on the right). […]

Cplusplus tutorial flat out incorrectly says:

In C++, there are two syntaxes for creating such type aliases: The first, inherited from the C language, uses the typedef keyword:

typedef existing_type new_type_name ;

where existing_type is any type, either fundamental or compound, and new_type_name is an identifier with the new name given to the type.

Conclusion

Hopefully I’ve helped you understand how typedef declarations actually work. As I mentioned at the beginning of the post, reach for type alias instead if you’re writing modern C++.

As we’ve seen in the earlier examples, the design of typedef declaration successfully achieves the “make simple things simple” principle. However, the generalized rule that one would naturally deduce from the simple cases do not prepare you for the complex cases at all.

I’ve also shown that the underlying rule is actually quite simple and consistent. The level of confusion that arise from what seems like such a coherent and simple design is quite intriguing.

Standardese

The formal definition of the syntax can be found in §7 Declaration:

§7 ¶1:

$\begin{align*} \textit{simp}&\textit{le-declaration:} \\ &\textit{decl-specifier-seq} \space \textit{init-declarator-list}_{opt}\textit{;} \\ &\textit{attribute-specifier-seq} \space \textit{decl-specifier-seq}\space\textit{init-declarator-list;} \\ \end{align*}$

§7 ¶9: If the decl-specifier-seq contains the typedef specifier, the declaration is called a typedef declaration and the name of each init-declarator is declared to be a typedef-name, synonymous with its associated type (7.1.3). […]
§7.1 ¶1:

$\begin{align*} \textit{decl}&\textit{-specifier:} \\ &\textit{storage-class-specifier} \\ &\textit{defining-type-specifier} \\ &\textit{function-specifier} \\ &\textbf{friend} \\ &\textbf{typedef} \\ &\textbf{constexpr} \\ \textit{decl}&\textit{-specifier-seq:} \\ &\textit{decl-specifier} \space \textit{attribute-specifier-seq}_{opt} \\ &\textit{decl-specifier} \space \textit{decl-specifier-seq} \\ \end{align*}$

§7.1.3 ¶1: Declarations containing the decl-specifier typedef declare identifiers that can be used later for naming fundamental (3.9.1) or compound (3.9.2) types. The typedef specifier shall not be combined in a decl-specifier-seq with any other kind of specifier except a defining-type-specifier, […] If a typedef specifier appears in a declaration without a declarator, the program is ill-formed.
$\begin{align} \textit{type}&\textit{def-name:} \\ &\textit{identifier} \\ \end{align}$
A name declared with the typedef specifier becomes a typedef-name. Within the scope of its declaration, a typedef-name is syntactically equivalent to a keyword and names the type associated with the identifier in the way described in Clause 8. A typedef-name is thus a synonym for another type. A typedef-name does not introduce a new type the way a class declaration (9.1) or enum declaration does. […]

Thanks to Artem Harutyunyan and Kapil Arya for reviewing this post!

Typedef Literacy was originally published by Michael Park at Michael Park on May 12, 2016.

2016-05-11T00:00:00-00:00

Introduction

variant reached a design consensus at the fall ISO C++ committee meeting in Kona, HI, USA. While the design is still not final, I’ve been experimenting to deliver a reference implementation.

In this post, I’ll be presenting my approach and implementation of the visitation mechanism. There are interesting parts in the implementation of variant itself, but a lot of those aspects are already covered in Eggs.Variant - Part I and Eggs.Variant - Part II by Agustín “K-ballo” Bergé.

Variant

Let us get started with a minimal variant interface. This will give us a frame of reference throughout the post. We only need the following:

v.index(): Returns the index of the currently stored value.
get(v): Returns the currently stored value if v.index() == I else throws std::bad_variant_access.

Visitation

Here is the signature of visit:

template <typename F, typename... Vs>
decltype(auto) visit(F &&f, Vs &&... vs);

It invokes f with the currently stored value of each of the vs....

Consider the following function:

// `F` and `Vs...` is in context from outer scope.
template <std::size_t... Is>
constexpr decltype(auto) dispatch(F f, Vs... vs) {
  static_assert(sizeof...(Is) == sizeof...(Vs));
  std::invoke(static_cast<F>(f), get<Is>(static_cast<Vs>(vs))...);
}

Since get(v) returns the currently stored value of v for us, we ultimately want to invoke dispatch<Is...>(f, vs...) where Is... are the compile-time values of vs.index()....

How do we do that?

`N`-dimensional Matrix of Function Pointers

The approach is to build an N-dimensional matrix of function pointers (representative of the N-ary cartesian product), then use vs.index()... to index into the matrix at runtime where the appropriate &dispatch<Is...> will be waiting for us.

For example, given variant<A, B> we have the following function matrix:

`A`	`B`
`&dispatch<0>`	`&dispatch<1>`

given variant<A, B> and variant<X, Y, Z>, we have:

	`X`	`Y`	`Z`
`A`	`&dispatch<0, 0>`	`&dispatch<0, 1>`	`&dispatch<0, 2>`
`B`	`&dispatch<1, 0>`	`&dispatch<1, 1>`	`&dispatch<2, 2>`

Implementation

`make_fmatrix`

The base case should look familiar. Given F, Vs... and Is..., it returns the function pointer &dispatch<Is...> from above.

// Base case for `make_fmatrix_impl`.
template <typename F, typename... Vs, std::size_t... Is>
constexpr auto make_fmatrix_impl(std::index_sequence<Is...>) {
  struct dispatcher {
    static constexpr decltype(auto) dispatch(F f, Vs... vs) {
      return std::invoke(static_cast<F>(f), get<Is>(static_cast<Vs>(vs))...);
    }
  };
  return &dispatcher::dispatch;
}

The recursive case implements the N-ary cartesian product resulting in the N-dimensional matrix. We build this recursively, keeping the first std::index_sequence as our accumulator. For each given list, we make a recursive call with each of its elements appended onto the accumulator, and the rest of the lists.

// Recursive case for `make_fmatrix_impl`.
template <typename F,
          typename... Vs,
          std::size_t... Is,
          std::size_t... Js,
          typename... Ls>
constexpr auto make_fmatrix_impl(
    std::index_sequence<Is...>, std::index_sequence<Js...>, Ls... ls) {
  return std::experimental::make_array(
      make_fmatrix_impl<F, Vs...>(std::index_sequence<Is..., Js>{}, ls...)...);
}

$\definecolor{x}{RGB}{250,128,114} \definecolor{y}{RGB}{34,139,34} \definecolor{z}{RGB}{65,105,225}$

Let’s go through an example with three lists $[\color{x}0\color{black}, \color{x}1\color{black}]$ , $[\color{y}0\color{black}, \color{y}1\color{black}, \color{y}2\color{black}]$ , $[\color{z}0\color{black}, \color{z}1\color{black}]$ :

$\operatorname{make\_fmatrix\_impl}([], [\color{x}0\color{black}, \color{x}1\color{black}], [\color{y}0\color{black}, \color{y}1\color{black}, \color{y}2\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}])$ $\Rightarrow \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}], [\color{y}0\color{black}, \color{y}1\color{black}, \color{y}2\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}], [\color{y}0\color{black}, \color{y}1\color{black}, \color{y}2\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix}$ $\Rightarrow \begin{bmatrix} \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}0\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}1\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}2\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}0\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}1\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}2\color{black}], [\color{z}0\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \end{bmatrix}$ $\Rightarrow \begin{bmatrix} \begin{bmatrix} \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}0\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}0\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}1\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}1\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}2\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}0\color{black}, \color{y}2\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \end{bmatrix} \begin{bmatrix} \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}0\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}0\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}1\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}1\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}2\color{black}, \color{z}0\color{black}]) \\ \operatorname{make\_fmatrix\_impl}([\color{x}1\color{black}, \color{y}2\color{black}, \color{z}1\color{black}]) \\ \end{bmatrix} \\ \end{bmatrix} \end{bmatrix}$ $\Rightarrow \begin{bmatrix} \begin{bmatrix} \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}0\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}0\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}1\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}1\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}2\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}0\color{black}, \color{y}2\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \end{bmatrix} \begin{bmatrix} \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}0\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}0\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}1\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}1\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \begin{bmatrix} \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}2\color{black}, \color{z}0\color{black}\mathclose{>} \\ \operatorname{\&dispatch}\mathopen{<}\color{x}1\color{black}, \color{y}2\color{black}, \color{z}1\color{black}\mathclose{>} \\ \end{bmatrix} \\ \end{bmatrix} \end{bmatrix}$

make_fmatrix bootstraps the above with the empty list [] as the initial accumulator, and index sequences [0, tuple_size_v<V_i>) for each of the V_i in Vs....

template <typename F, typename... Vs>
constexpr auto make_fmatrix() {
  return make_fmatrix_impl<F, Vs...>(
      std::index_sequence<>{},
      std::make_index_sequence<std::tuple_size<std::decay_t<Vs>>::value>{}...);
}

Now we can construct a static constexpr instance of fmatrix within visit.

template <typename F, typename... Vs>
decltype(auto) visit(F &&f, Vs &&... vs) {
  static constexpr auto fmatrix = make_fmatrix<F &&, Vs &&...>();
  /* ... */
}

We’re now left with the task of accessing the fmatrix with vs.index().... Since we can’t say something like: fmatrix([vs.index()]...) to mean fmatrix[i_0][i_1]...[i_N], we need to introduce a helper function.

`at` for `N`-dimensional arrays

at(array, i_0, i_1, ..., i_N) returns array[i_0][i_1]...[i_N].

// Base case for `at_impl`.
template <typename T>
constexpr T &&at_impl(T &&elem) { return std::forward<T>(elem); }

// Recursive case for `at_impl`.
template <typename T, typename... Is>
constexpr auto &&at_impl(T &&elems, std::size_t i, Is... is) {
  return at_impl(std::forward<T>(elems)[i], is...);
}

template <typename T, typename... Is>
constexpr auto &&at(T &&elems, Is... is) {
  // Commented out since `std::rank` is not defined for `std::array`.
  // static_assert(std::rank<std::decay_t<T>>::value == sizeof...(Is));
  return at_impl(std::forward<T>(elems), is...);
}

Alright, almost there! We can now use at to retrieve the &dispatch<Is...> corresponding to vs.index()... in fmatrix and invoke it like this:

template <typename F, typename... Vs>
decltype(auto) visit(F &&f, Vs &&... vs) {
  static constexpr auto fmatrix = make_fmatrix<F &&, Vs &&...>();
  return at(fmatrix, vs.index()...)(std::forward<F>(f), std::forward<Vs>(vs)...);
}

That’s it!

We’ve managed to decouple the implementation of variant and the visitation mechanism, generalized to any N. This means that we can implement parts of variant that required single visitation using visit. For example, copy construction could look something along the lines of:

template <typename... Ts>
class variant {
public:
  /* ... */

  variant(const variant &that) : variant{/* valueless_by_exception */} {
    if (!that.valueless_by_exception()) {
      visit([this](auto &&value) {
              this->construct(std::forward<decltype(value)>(value));
            },
            that);
    }
  }

  /* ... */
};

NOTE: It’s actually a little more complicated than this because duplicate types in a variant have distinct states. We therefore need to initialize the alternative in this at the same index as the one stored in that.

The full reference implementation of std::variant can be found here.

Thanks to Agustín “K-ballo” Bergé for reviewing this post!

Variant Visitation was originally published by Michael Park at Michael Park on July 07, 2015.

2016-05-11T00:00:00-00:00

Introduction

Today I want to tackle a very specific problem around proxy objects such as std::vector<bool>::reference. The general pattern here is that the object being returned could be holding references to a temporary object and therefore needs to be consumed before the next sequence point. This is roughly the wording employed to describe the behavior of std::forward_as_tuple as well.

If you need a more credible description of this problem, you can refer to Item 6 of Scott Meyers’ Effective Modern C++ titled: “Use the explicitly typed initializer idiom when auto deduces undesired types.”

The Problem

The main issue with proxy objects such as std::vector<bool>::reference and std::forward_as_tuple is that often they are designed to only live for a single statement. Suppose I have a proxy object Join which is returned from a string join function. In this case expectation is that the user immediately consumes the proxy object. They can do so by streaming it out, or actually construct a string out of it.

class Join {
  public:

  // Implicitly convert to a `std::string`.
  operator std::string() && {
    std::ostringstream strm;
    strm << *this;
    return std::move(strm).str();
  }

  explicit Join(const std::string &delimiter,
                const std::string &lhs,
                const std::string &rhs)
      : delimiter_(delimiter), lhs_(lhs), rhs_(rhs) {}

  private:

  // References to the parts.
  const std::string &delimiter_;
  const std::string &lhs_;
  const std::string &rhs_;

  // Directly stream the arguments out to the stream.
  friend std::ostream &operator<<(std::ostream &strm, const Join &join) {
    return strm << join.lhs_ << join.delimiter_ << join.rhs_;
  }
};

Join join(const std::string &delimiter,
          const std::string &lhs,
          const std::string &rhs) {
  return Join(delimiter, lhs, rhs);
}

It can be used like so:

// Construct a string and use it.
std::string str = join(", ", "a", "b");
std::cout << str << std::endl;

// Streaming it out directly avoids the temporary string unlike the above.
std::cout << join(", ", "hello", "world") << std::endl;

This is great, unless we use it incorrectly of course. One subtle pitfall here is if we were to replace std::string with auto. For example:

// Construct a string? and use it...
auto str = join(", ", "a", "b");

// Not safe! `str` could be holding references to temporary objects!
std::cout << str << std::endl;

Here we’ve arrived at undefined behavior land. The reason is because str is a proxy object which could be holding references to temporary objects (which, in this case it is). The temporary objects that str is holding references of have gone out of scope by the time we get to using it.

How Can We Help?

Our goal is to make the interface harder to use incorrectly by disallowing statements of the following form:

auto str = join(", ", "a", "b");

Implementation

We need to disallow the public use of any of the constructors of Join, but allow join to access them since it returns Join by value. Well, friend sounds like the right candidate for the job. We make all the constructors private and then make join a friend.

class Join {
  public:

  // Implicitly convert to a `std::string`.
  operator std::string() && { /* unchanged */ }

  private:

  explicit Join(const std::string &delimiter,
                const std::string &lhs,
                const std::string &rhs)
      : delimiter_(delimiter), lhs_(lhs), rhs_(rhs) {}

  Join(const Join &) = default;
  Join(Join &&) = default;

  // References to the parts.
  /* unchanged */

  // Directly stream the arguments out to the stream.
  friend std::ostream &operator<<(std::ostream &strm, const Join &join) {
    /* unchanged */
  }

  friend Join join(const std::string &delimiter,
                   const std::string &lhs,
                   const std::string &rhs);
};

Join join(const std::string &delimiter,
          const std::string &lhs,
          const std::string &rhs) {
  return Join(delimiter, lhs, rhs);
}

Now the attempts to “save” an instance of Join will be disallowed.

// error: calling a private constructor of class 'Join'
auto str = join(", ", "a", "b");

That’s it! This approach works for cases where the expected result from a function is a value. In our case, it’s probably helpful since we’re essentially expecting a std::string as the result of join, Join works seamlessly with that expectation, with a compile-time error when you try to capture it with auto.

Limitations

As of now, I don’t know of a way to completely prevent bad behavior. But in a language where we can bind references to a temporary object, there’s not much we can do: const auto &ref = join(", ", "a", "b");

You may look at the above code and say, “but the lifetime of the temporary is extended to the lifetime of the reference!” and yes, it absolutely is. However, it does not extend the lifetime of the temporary we want to extend. In our case, we simply extend the lifetime of the temporary proxy object. Not the temporary objects that Join holds! If join were to return a std::string, this approach would work. Binding a reference to a temporary object however is bad practice in general, so this limitation doesn’t worry me too much.

Safer Proxy Idiom was originally published by Michael Park at Michael Park on May 21, 2015.

2016-05-11T00:00:00-00:00

In this post, I want to talk about a fast exponentiation algorithm that I learned recently.

Our goal is to write a function double exp(double x, int n); which returns $x^n$ .

Naive Implementation

double exp(double x, int n) {
  if (n < 0) return 1 / exp(x, -n);
  double result = 1;
  while (n--) result *= x;
  return result;
}

We have an $O(n)$ algorithm here. Let’s improve it to be $O(\lg n)$ . The algorithm is called Exponentiation by Squaring.

Recursive Approach

In this approach we derive the recursive relation and the implementation is quite straight forward.

Key Property

$x^n = \begin{cases} \frac{1}{x^{-n}} & \text{if $ n $ < 0}\\ 1 & \text{if $ n $ = 0}\\ x(x^2)^\frac{n-1}{2} & \text{if $ n $ is odd}\\ (x^2)^\frac{n}{2} & \text{if $ n $ is even} \end{cases}$

Implementation

double exp(double x, int n) {
  if (n < 0) return 1 / exp(x, -n);
  if (n == 0) return 1;
  return (n % 2 == 1 ? x : 1) * exp(x * x, n / 2);
}

Since we divide the problem in half at each step, we get our $O(\lg n)$ algorithm.

Iterative Approach

In this approach, we iterate through the bits of $n$ and accumulate the result to $x^n$ .

Key Property

Consider the binary representation of $n = b_k \ldots b_2 b_1 b_0$ where each $b_i$ are binary digits.

$n = b_0 \times 2^0 + b_1 \times 2^1 + b_2 \times 2^2 + \ldots + b_k \times 2^k$

Plugging this into $x^n$ we get,

$\begin{align*} x^n &= x^{b_0 2^0 + b_1 2^1 + b_2 2^2 + \ldots + b_k 2^k}\\ &= x^{b_0 2^0} \times x^{b_1 2^1} \times x^{b_2 2^2} \times \ldots \times x^{b_k 2^k}\\ &= (x^{2^0})^{b_0} \times (x^{2^1})^{b_1} \times (x^{2^2})^{b_2} \times \ldots \times (x^{2^k})^{b_k}\\ &= (x)^{b_0} \times (x^2)^{b_1} \times (x^{2^2})^{b_2} \times \ldots \times (x^{2^k})^{b_k} \end{align*}$

We notice 2 things here.

A term contributes to the result only if $b_i$ is 1, since if $b_i$ is 0, then the term becomes 1.
As we iterate through $i$ starting from 0, $(x^{2^i})$ starts at $x$ and gets squared every iteration.

Implementation

double exp(double x, int n) {
  if (n < 0) return 1 / exp(x, -n);
  double result = 1;
  while (n > 0) {
    if (n % 2 == 1) result *= x;
    x *= x;
    n /= 2;
  }  // while
  return result;
}

n % 2 represents our bit $b_i$ . At each iteration, we only contribute the term to the result only if n % 2 is 1.
The variable x represents the $(x^{2^i})$ . It starts at $x$ and gets squared on every iteration.

Some Numbers

These are performance numbers for computing $x^{35}$ for $x = [0 \ldots 100,000,000)$

Approach	Time (ms)
Naive	1733
Recursive	1670
Iterative	267
`std::pow`	7099

Clearly the iterative $O(\lg n)$ algorithm is the most efficient and it seems that even though the recursive algorithm is also logarithmic, it’s not actually that much better than the naive version at $n = 35$ .

Exponentiation By Squaring was originally published by Michael Park at Michael Park on August 18, 2014.

2016-05-11T00:00:00-00:00

UPDATE: My concern discussed here has been answered on Stackoverflow.

What’s `std::decay`?

decay is a metafunction added to the <type_traits> header in C++11. A metafunction is a function (in the mathematical sense) that takes types as arguments rather than values. A simpler metafunction to describe is add_const which takes any arbitrary type and adds const to it. For example:

static_assert(std::is_same_v<std::add_const_t<int>, const int>);
static_assert(std::is_same_v<std::add_const_t<int *>, int * const>);

decay applies type transformations as if it were being passed as a function argument by value. For example:

static_assert(std::is_same_v<std::decay_t<void ()>, void (*)()>);
static_assert(std::is_same_v<std::decay_t<int [3]>, int *>);
static_assert(std::is_same_v<std::decay_t<const int>, int>);

Current Implementation

Here’s a possible implementation as given in by cppreference.com. This is also roughly the implementation used in both libstdc++ and libc++.

template< class T >
struct decay {
  typedef typename std::remove_reference<T>::type U;
  typedef typename std::conditional<
    std::is_array<U>::value,
    typename std::remove_extent<U>::type*,
    typename std::conditional<
      std::is_function<U>::value,
      typename std::add_pointer<U>::type,
      typename std::remove_cv<U>::type
    >::type
  >::type type;
};

Alternative Implementation

The idea here is to leverage the compiler which already defines the type transformations necessary for pass-by-value semantics, rather than manually writing them out for decay.

Here it is:

template <typename T>
struct decay {
  template <typename U> static U impl(U);
  using type = decltype(impl(std::declval<T>()));
};

The function impl takes an argument by value, so any argument of type T that gets passed to it will go through the type transformations necessary for pass-by-value sematics. Notice that this is exactly what we want for decay!

I pass an rvalue reference of T to impl, and the deduced type U is the result we want for decay.

So What?

Not only is the implementation simpler this way, but it also follows the DRY (Don’t Repeat Yourself) principle. Suppose the definition of pass-by-value transformations were to change in the standard. In the current state, at least 4 modifications are required.

Rules for template type deduction
Definition of decay
Implementation of template type deduction in the compiler
Implementation of decay in the standard library

If we were to piggy-back on the rules of template type deduction to define decay instead, (1) and (3) still needs to be done but we get (2) and (4) for free.

I also think it allows for stronger claims about what decay does. Here’s a note about decay from N3797:

[ Note: This behavior is similar to the lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) conversions applied when an lvalue expression is used as an rvalue, but also strips cv-qualiﬁers from class types in order to more closely model by-value argument passing. — end note ]

What does “more closely model by-value argument passing” mean here? It sounds to me like it doesn’t exactly model by-value argument passing. I think leveraging the existing rules of template type deduction would allow us to claim that it exactly models by-value argument passing.

Am I off base here? Let me know what you think!

Alternative `std::decay` Implementation was originally published by Michael Park at Michael Park on August 17, 2014.

2016-05-11T00:00:00-00:00

The lambda expression is one of my favorite C++11 features next to variadic templates. I won’t talk about the lambda expressions in particular in this post, but I want to talk about the mutable keyword in the context of lambda expressions.

`const` by Default

C++’s lambdas are technically closures, since it has the ability to capture (save) the surrounding context. Similar to how we need to decide whether to pass function arguments by value or by reference, we need to decide whether we want capture by value or by reference. If we capture by value, the saved context is now part of the lambda’s state and we need to decide whether the operator() is allowed to modify it or not. Let’s see an example:

int n = 42;
auto good = [n]() mutable { n = 45; };  // ok, mutable lambda.
auto bad = [n]() { n = 45; };  // error: cannot assign to a variable captured by
                               //        copy in a non-mutable lambda

As you can see, the default for lambdas is to be non-mutable, or const. That is, a lambda needs the mutable keyword to be able to modify its internal state.

This is New…

Throughout C++, the language consistently chooses mutable by default. For example, variable declarations (local, member, etc) and member function declarations need const tacked onto them in order to make them non-mutable. The fact that lambdas have the opposite default behavior is new to the language.

Partial Improvement

The improvement here is that const by default is actually the better choice. I suspect that this is a lesson learned from functional languages such as ML and OCaml which provide immutable values by default. As a result, we get referential transparency more often which helps programmers and compilers to reason about a program. Andrej Bauer also talks about this topic in his blog post, On programming language design, in which he says:

We should design the language so that the default case is an immutable value. If the programmer wants a mutable value, he should say so explicitly.

We also don’t want to be restrained by the decisions made in the past, of course we want to keep on improving… but we still need backwards-compatibility.

But… Consistency…

I have a big thing for consistency. I think keeping consistency in a language makes it so that there’s less to remember and therefore easier to learn and use. This is no different in programming languages than human languages such as… English. English has a ridiculous number of special cases to the point where one has to learn the language almost on a phrase-by-phrase basis. Learning a pattern and applying it consistently will certainly lead you to sound like a foreigner in no time.

I think the language becomes unnecessarily complicated and harder to teach when we introduce special cases like these.

So which is better?

I’ve argued both sides against myself and there doesn’t seem to be a definitive answer. I want to be able to make improvements going forward, but I’m tired of saying and also hearing “They’re the same, pretty much. They’re almost always the same. Um, one case where it’s different…”

In this specific case, I think I would’ve preferred to keep consistency. The committee members voted otherwise however, so who am I to disagree.

Improvement vs Consistency was originally published by Michael Park at Michael Park on August 14, 2014.

2016-05-07T00:00:00-00:00

The Problem

Suppose we want to write a wrapper class in modern C++. Of course we want to take advantage of move-semantics along with perfect forwarding. So let’s provide a move constructor as well as a templated constructor which perfectly forwards an argument to initialize our wrapped value. Something like:

template <typename T>
class wrapper {
  public:

  wrapper() = default;

  wrapper(const wrapper &/* that */) /* : value(that.value) */ {
    std::cout << "wrapper(const wrapper &)" << std::endl;
  }

  wrapper(wrapper &&/* that */) /* : value(std::move(that.value)) */ {
    std::cout << "wrapper(wrapper &&)" << std::endl;
  }

  template <typename U>
  wrapper(U &&/* u */) /* : value(std::forward<U>(u)) */ {
    std::cout << "wrapper(U &&)" << std::endl;
  }

  private:

  // T value;
};

NOTE: The ctor-init-lists are commented out because we want to analyze which constructors get invoked on various types, and it doesn’t compile in some of the cases we want to explore.

Let’s try passing wrapper by const &, &, const &&, and && with the intention to copy or move the object.

// const and non-const objs.
const wrapper<int> const_obj;
wrapper<int> non_const_obj;
// invoke constructors.
wrapper<int> const_lval(const_obj);
wrapper<int> non_const_lval(non_const_obj);
wrapper<int> const_rval(std::move(const_obj));
wrapper<int> non_const_rval(std::move(non_const_obj));

This outputs:

wrapper(const wrapper &)
wrapper(U &&)
wrapper(U &&)
wrapper(wrapper &&)

Huh? So passing wrapper by & and const && didn’t seem to invoke the correct constructors. Without the templated constructor, the output would be:

wrapper(const wrapper &)
wrapper(const wrapper &)
wrapper(const wrapper &)
wrapper(wrapper &&)

What’s going on here?

Explanation

It’s important to note that the parameter of the templated constructor is a Universal Reference. Without getting into too much detail, a universal reference binds to anything and preserves the qualifiers of the argument, that is, whether the argument is const, volatile, lvalue or rvalue. Let’s take a look at the second case, where we pass an instance of wrapper by &. Since universal reference preserves all the qualifiers, the templated constructor gets instantiated to wrapper(wrapper &).

NOTE: If you don’t understand how perfect forwarding works, Universal Reference by Scott Meyers illustrates how it all works. It boils down to a special rule for template type deduction in conjunction with reference collapsing, but that’s for another post.

Now overload resolution kicks in and selects between the two viable functions:

wrapper(const wrapper &); // copy constructor (user-defined / compiler-defined).
wrapper(wrapper &);       // instantiated templated constructor.

What we need to recognize is that wrapper & is an exact match for non_const_obj whereas the copy constructor requires an implicit conversion from wrapper & to const wrapper &. Since zero conversions is better than one, wrapper(wrapper &) wins overload resolution and thus the templated constructor gets invoked.

The same line of reasoning goes for the third case, where the template parameter gets instantiated to wrapper(const wrapper &&) and becomes an exact match for std::move(const_obj). For attempted move on const objects, we rely on the implicit conversion from const wrapper && to const wrapper & in order to fallback to a copy.

The bottom line of the problem is that templates can be instantiate to a better match than non-templates in some cases.

Solutions

Pass by Value

The preferred solution here is to forget about perfect forwarding and just go with the trivial pass-by-value-then-move pattern. As long as T is movable, we incur at most an extra move which is negligible in most cases anyway.

/* Pass-by-value constructor. */
wrapper(T value) : value(std::move(value)) {
  std::cout << "wrapper(T)" << std::endl;
}

NOTE: If T happens to be copyable but not movable, we incur an extra copy rather than an extra move. I was concerned with this situation but I feel better after a discussion with Sean Parent.

It’s important to note that alternative solutions should match this constructor in its behavior. I mean in regards to binding, rather than performance behavior.

Better Match

Another solution is to explicitly define the wrapper(wrapper &) constructor and delegate to the const version. But then while we’re at it we should also add another one for wrapper(const wrapper &&)… mm… not liking this already.

How does it compare to the model solution?

Suppose T is unrelated to wrapper, and that derived_wrapper is a class that publicly inherits from wrapper. If we attempt to copy-/move-construct off of a derived_wrapper, under the pass-by-value solution it would bind to the copy or move constructor. With this solution however, we would end up binding to the perfect forwarding constructor again.

The situation I described above is admittedly obscure. The point I’m trying to make here is that the templated constructor binds to anything, and attempting to hard-code the cases won’t work in general. A better approach is to constrain the templated constructor to be less greedy.

SFINAE

The last solution I’ll consider is to SFINAE out the templated constructor from the overload set. If you’ve read the standards document and have seen: “This constructor shall not participate in overload resolution.”, this is what it’s talking about. We enable the templated constructor only if U is convertible to T.

/* Constrained perfect forwarding constructor. */
template <
    typename U,
    std::enable_if_t<std::is_convertible<U, T>::value> * = nullptr>
wrapper(U &&u) : value(std::forward<U>(u)) {
  std::cout << "wrapper(U &&)" << std::endl;
}

Compared to the model solution?

This behaves equivalently to the pass-by-value pattern. For the pass-by-value pattern we have T as the parameter, which implies that we can call it with arguments that implicitly convertible to T. That semantic behavior is what we have captured here with the constraint condition.

EDIT: The solution is actually not equivalent to the pass-by-value pattern. Scott Meyers kindly pointed this out to me: “There are what I call ‘perfect forwarding failure cases’ that will succeed with pass-by-value but fail with perfect forwarding.”

Not New to C++11

It may seem like this is a new problem introduced in C++11, but it’s actually not a new problem. It’s just that it is much easier to encounter it because perfect-forwarding arguments is so tempting, whereas the C++98 way is perhaps less tempting.

In C++98 and also in C++11, the following template would also beat the copy constructor if a non-const lvalue is passed.

template <typename U>
wrapper(U &) {
  std::cout << "wrapper(U &)" << std::endl;
}

My point is that templates being instantiated to be better matching than non-templates is not a new problem. It’s not specific to perfect forwarding, nor is it specific to copy constructors. Therefore, it shouldn’t be remembered as if it’s a special case.

Summary

Avoid overloading templates and non-templates as the template could instantiateto be a better match (e.g. perfect-forwarding constructor) than the non-template which might rely on implicit conversions to handle all of its cases (e.g. copy constructor).
Prefer to use the pass-by-value-then-move pattern if possible. It’s much simpler, more readable, and only incurs at most an extra move as long as the type is movable.
If pass-by-value-then-move is not an option, (e.g. variadic templates, efficiency) then consider the constraints that the pass-by-value version would impose and satisfy those requirements with template metaprogramming techniques such as tag dispatch, SFINAE and explicit/partial specializations.

Credits

The pitfalls of perfect-forwarding constructors have been discussed by others already.

Some pitfalls with forwarding constructors by R. Martinho Fernandes
Copying Constructors in C++11 by Scott Meyers
Universal References and the Copy Constructor by Eric Niebler
Too perfect forwarding by Andrzej Krzemieński

Beware of Perfect Forwarding Constructors was originally published by Michael Park at Michael Park on June 07, 2014.

Michael Park

Introduction

Variant

Visitation

Implementation

Single Visitation: Exactly 4 Alternatives

Single Visitation: Up to 4 Alternatives

Single Visitation: Arbitrary # of Alternatives

Multi-visitation

Benchmark

Jump Table

Recursive switch

Jump Table

Recursive switch

Conclusion

Introduction

Project Structure

Title

Table of Contents

Markdown

Code Examples

Tony Tables

Proposed Wording

Code Changes

Wording Changes

Grammar Changes

References

Citations

Final Remarks

Introduction

Determining the Source

Surrogate Call Function

What’s in a Name?

Final Touch with Multiple Inheritance

Final Remarks

Introduction

Non-Type Template Parameter

Value-Encoded Type

Macros (< C++17)

Compile-Time String

C++17

Final Remarks

Talks

C++17 Features - Bryce Lelbach

Expression Templates Everywhere with C++14 and Yap - Zach Laine

constexpr ALL the things! - Ben Deane, Jason Turner

The Mathematical Underpinnings of Promises in C++ - David Sankel

Postmodern Immutable Data Structures - Juan Pedro Bolivar Puente

Type Based Template Metaprogramming is Not Dead - Odin Holmes

Call: A Library that Will Change the Way You Think about Function Invocations - Matt Calabrese

Practical (?) Applications of Reflection - Jackie Kay

Locally Atomic Capabilities and How to Count Them - Lisa Lippincott

Beyond the Talks

My Contribution

Last but not Least

Introduction

Correct Reading

Inaccurate Sources

Conclusion

Standardese

Introduction

Variant

Visitation

N-dimensional Matrix of Function Pointers

Implementation

make_fmatrix

at for N-dimensional arrays

Introduction

The Problem

How Can We Help?

Implementation

Limitations

Naive Implementation

Recursive Approach

Key Property

Implementation

Iterative Approach

Key Property

Implementation

Some Numbers

Recursive `switch`

Recursive `switch`

`N`-dimensional Matrix of Function Pointers

`make_fmatrix`

`at` for `N`-dimensional arrays

What’s `std::decay`?

`const` by Default