この記事は、

Metaprogramming is less fun in D

を自分用に翻訳したものを 許可を得て 公開するものである。 コードのコメントも翻訳してある。 誤字や誤訳などを見つけたら今すぐ Pull requestだ!


講演者の静かな声と、ほとんどC++のコードのみを映し出すスライド(通常キーノートで期待していたものではありません)にもかかわらず、 Louis DionneのMeeting C++ 2016でのメタプログラミングについてのトーク は本当に面白いものでした。

前回私がC++でメタプログラミングをしてから何年も立ち、 このトークは私が信じられないほど巧妙なテンプレートの黒魔術の数々をまとめて、ついにそれを動かした時の古い記憶、感情を思い起こさせました。 ああ、とても狡猾だった。私は最高のハッカーだ。 あなたもその気持ちを知っているでしょう。

私は状況が大きく変わったことを知って嬉しかったです。 ダブルコロンによってあちこちで装飾された何重ものネストされた山括弧でコードを散らかすことはもはや一般的ではありません。 基本的にHana で普通のランタイム関数またはオペレーターコールのように見えるコードを書きます。 しかし裏ではこれらの関数はそれらの引数の型からの情報に作用するジェネリクスです。 これらの操作は実行時の状態にかかわらず、生成されるマシンコードはすべて最適化されます。 素晴らしい。

ケーススタディ:イベントシステム

トークで議論されている例(だいたい38:30に始まります)を見てみましょう。 あなたがすでにそれを見ているならば、このパートをスキップすることもできます。 これ以降の議論で参考になるよう、私はここにサンプルの全体をコピーします。

名前でイベントを識別するイベントシステムを考えてみましょう。 好きな数、イベントが発生した時に呼ばれるコールバック(ハンドラ)を登録することができます。 その後、イベントを引き起こし、与えられたイベントに登録されたすべてのコールバックが実行されます。

int main() {
  event_system events({"foo", "bar", "baz"});

  events.on("foo", []() { std::cout << "foo triggered!" << '\n'; });
  events.on("foo", []() { std::cout << "foo again!" << '\n'; });
  events.on("bar", []() { std::cout << "bar triggered!" << '\n'; });
  events.on("baz", []() { std::cout << "baz triggered!" << '\n'; });

  events.trigger("foo");
  events.trigger("baz");
  // events.trigger("unknown"); // おっと!ランタイムエラーです!
}

Javaスタイルの実行時のみの実装から始めます。 ハッシュマップを使い与えられたイベント名を呼ぶための関数のvectorを探します。 はじめ、空のvectorが各イベントのマップに挿入されています。

struct event_system {
  using Callback = std::function<void()>;
  std::unordered_map<std::string, std::vector<Callback>> map_;

  explicit event_system(std::initializer_list<std::string> events) {
    for (auto const& event : events)
      map_.insert({event, {}});
  }

コールバックを登録するために、マップから正しいvectorを探し、その最後にコールバックをプッシュします。

  template <typename F>
  void on(std::string const& event, F callback) {
    auto callbacks = map_.find(event);
    assert(callbacks != map_.end() &&
      "trying to add a callback to an unknown event");

    callbacks->second.push_back(callback);
  }

最後に、イベントを発生させると指定されたイベントのvectorのすべてのコールバックが呼ばれます。

  void trigger(std::string const& event) {
    auto callbacks = map_.find(event);
    assert(callbacks != map_.end() &&
      "trying to trigger an unknown event");

    for (auto& callback : callbacks->second)
      callback();
  }

これでもいいのですが、発生しうるイベントには何があるか、それがいつ発生するべきかはたいてい設計時点でわかっています。 ならば、なぜイベントが発生するたびに毎回マップを検索するコストを払わなければならないのでしょう? 更に悪いことに、イベントの名前を打ち間違えた場合、それがわかる頃は不幸にも遅すぎるかもしれません。

コンパイル時ルックアップ

Hanaは上のコードの見た目を変えるだけで、コンパイル時にルックアップをできるようにすることで、そのような苛立ちから我々を救うことができます。 まず、実行時のそれと同じ場所のコンパイル時文字列リテラルによってコールサイトをアップデートします。

int main() {
  auto events = make_event_system("foo"_s, "bar"_s, "baz"_s);

  events.on("foo"_s, []() { std::cout << "foo triggered!" << '\n'; });
  events.on("foo"_s, []() { std::cout << "foo again!" << '\n'; });
  events.on("bar"_s, []() { std::cout << "bar triggered!" << '\n'; });
  events.on("baz"_s, []() { std::cout << "baz triggered!" << '\n'; });
  // events.on("unknown"_s, []() {}); // コンパイルエラー!

  events.trigger("foo"_s); // オーバーヘッドはありません
  events.trigger("baz"_s);
  // events.trigger("unknown"_s); // コンパイルエラー!
}

すべてのイベント名の_sサフィックスに注目してください。 それはおそらく2020年にC++標準になるであろう 特殊文字列リテラルオペレータ を必要としますが、ClangとGCCではすでに実装されています、ならなぜ使わないのでしょう? このオペレータは文字列それ自身がオブジェクトの型に保存されるステートレスなオブジェクトをビルドします。 たとえば"foo"_shana::string<'f', 'o', 'o'>のインスタンスになります。

hana::mapでの実装

実行時マップを、各イベントにコールバックのvectorを テンプレートパラメータパック拡張マジック で宣言するhana::mapで置き換えましょう。

template <typename ...Events>
struct event_system {
  using Callback = std::function<void()>;
  hana::map<hana::pair<Events, std::vector<Callback>>...> map_;

これでデフォルトでevent_systemが構築し、デフォルトでmap_を構築することができ、 その結果として含まれるすべてのコールバックのvectorが空のvectorに初期化されます。

template <typename ...Events>
event_system<Events...> make_event_system(Events ...events) {
  return {};
}

最終的に、実行時ルックアップをコンパイル時の同等物と置き換えます。

  template <typename Event, typename F>
  void on(Event e, F callback) {
    auto is_known_event = hana::contains(map_, e);
    static_assert(is_known_event,
      "trying to add a callback to an unknown event");

    map_[e].push_back(callback);
  }

  template <typename Event>
  void trigger(Event e) const {
    auto is_known_event = hana::contains(map_, e);
    static_assert(is_known_event,
      "trying to trigger an unknown event");

    for (auto& callback : map_[e])
      callback();
  }

アクセスすべきvectorはコンパイル時に決定され、上記の各関数テンプレートのインスタンス化はそのvectorにアクセスするだけです。 たとえば下のように各イベントの関数を手書きするのと比べて追加の実行時コストはないでしょう。

  template <typename F>
  void trigger_foo(F callback) {
    for (auto& callback : callbacks_foo)
      callback();
  }

アプリケーションがイベントを頻繁に発生させるとき、ディスパッチの静的から動的への変更は顕著な高速化を引き起こします。 下のチャートは1つのコールバックが登録されているイベントのtriggerを呼ぶ時間を表しています。 hana::mapを基にしたコンパイル時ルックアップは大体unordered_mapの実行時ルックアップの14倍速く、 ただstd::functionを呼び出すことと比べて15%遅いだけです。

Event system performance: D vs. C++

両方を同時に得る

発生するイベントが実行時にのみ決まる場合があります。たとえばこのように:

  std::string e = read_from_stdin();
  events.trigger(e);

我々のイベントシステムはこのようなケースをハンドリングするために容易に拡張ができます。 ちょうどはじめのバージョンの実行時のみのルックアップのように、順序付けされていないマップを使います。 コールバックvectorを2度も保存したくないため、マップの値はすでに静的マップに保存されているvectorへのポインタです。

  std::unordered_map<std::string, std::vector<Callback>* const> dynamic_;

  event_system() {
    hana::for_each(hana::keys(map_), [&](auto event) {
      dynamic_.insert({event.c_str(), &map_[event]});
    });
  }

実行時に決定するイベントを発生させられるようにするには、純実行時実装と同じようにトリガメソッドをオーバーロードすれば良い話です。

  void trigger(std::string const& event) {
    auto callbacks = dynamic_.find(event);
    assert(callbacks != dynamic_.end() &&
      "trying to trigger an unknown event");

    for (auto& callback : *callbacks->second)
      callback();
  }

もっとうまくできないか?

トークのこの時点(59:30)で、Louisがこう言っています:

コンパイル時と実行時のルックアップのサポートに必要なのはシングルオーバーロードです。 それは非常に強力で、私は他にそれが可能な言語を知りません。

Dがそれをもっとうまくできるのは明らかでした、10分で同等の実装を作ることができました。 しかし私は理解できます: もし私が何年もの努力の積み重ねの結果を宣伝するならば、私は人々が他のものを探すことを望みません。 ;)

Dをごぞんじでない? 「正しく行われたC++」として聞いたことがあるかもしれませんが、それは完全には真実ではありません。 Dは悪い決定と癖の荷物を抱えてもいます。 時間の経過とともに、全く異なるスタイルの追加がアドホックな標準ライブラリに集まってきます。 ドキュメントは時に時代遅れになっているか、探しているものが抜けています。 そのコミュニティもそれが業界から受けたサポートもC++で受けたそれとは比較にならないほど小さなものです。 しかしそのすべてをさておいて、何年もDを様々なタスクに使用した上で、 “信頼性・保守性の高い・読みやすいコードを書いて仕事をサクサク進める必要のある 現実的なプログラマのための、 現実的な言語” 1 であるという約束に恥じないものであるということに私は同意せざるを得ません。

そこで、Dがこのオーバーロードトリックをすることができ、表現力でC++/Hanaの組と少なくともこのユースケースで肩を並べるものかどうか見てみましょう。

インターフェース

コールサイトで期待されるものから始めましょう。

void main() {
  EventSystem!("foo", "bar", "baz") events;

  events.on!"foo"(() { writeln("foo triggered!"); });
  events.on!"foo"(() { writeln("foo again!"); });
  events.on!"bar"(() { writeln("bar triggered!"); });
  events.on!"baz"(() { writeln("baz triggered!"); });
  // events.on!"unknown"(() {}); // コンパイルエラー!

  events.trigger!"foo";
  events.trigger!"baz";
  events.trigger("bar"); // 動的ディスパッチのオーバーロード
  // events.trigger!"unknown"; // コンパイルエラー!
}

C++でやったのとなかなか良く似ています。 Dでの最も重要な違いは、コンパイル時文字列のための特殊なシンタックスはなく、普通の文字列がテンプレートパラメータとして渡せることです。 そのため、型でエンコードされた文字列によるステートレスなオブジェクトのアイデアはここに値を追加しません (しかし実装することは技術的に可能です。下を見てください)。

EventSystem構造体テンプレートはただイベント名を引数として渡すだけでインスタンス化でき、 すべてのメンバがデフォルト静的初期化子で事足り、ファクトリ関数を必要としません。

関数テンプレートontriggerはコンパイル時stringも受け入れます。 各文字列はシングルトークンのため、空の実行時引数リストと同じように、テンプレート引数リストの括弧は省略することができます。 この小さな構文の癖はtrigger!("foo")()をより乱雑さのないtrigger!"foo"にします。

実行時とコンパイル時引数の区別は、標準の言語規則で保持されます。 _sサフィックスがコンパイル時エンティティを暗示する特殊なケースを覚えておく必要はありません。 foobazを静的ディスパッチで発生させることに注目してください。 しかしbarを発生させるとき、実行時に評価されるイベント名を受け入れるオーバーロードも利用できるでしょう。

コンパイル時ルックアップ

今から実装です:

struct EventSystem(events...) {
  alias Callback = void delegate();
  Callback[][events.length] callbacks_;   // C++の std::array<std::vector<Callback>, sizeof...(events)> のようなもの

Phobosにはhana::mapと同等のものはありません。 しかしマップ内のすべての値は同じ型のため、その固定長配列を宣言し、イベント名を配列のインデックスにマップするために staticIndexOfを使うことができます。 events...としてこの構造体テンプレートが受け取る引数リストは型や、 テンプレート名、異なるプリミティブまたはコンポジット型の定数を含む様々なコンパイル時エンティティを含みます。 特に、文字列はうまく行くでしょう。

このontriggerの実装もC++バージョンとよく似ています。 最初に要求されたコールバックのvectorのインデックスを探し、そのインデックスを介して配列からvectorを取得します。

  void on(string event)(Callback c) {
    enum index = staticIndexOf!(event, events);
    static assert(index >= 0,
      "trying to add a callback to an unknown event: " ~ event);

    callbacks_[index] ~= c;
  }

  void trigger(string event)() {
    enum index = staticIndexOf!(event, events);
    static assert(index >= 0,
      "trying to trigger an unknown event: " ~ event);

    foreach (callback; callbacks_[index])
      callback();
  }

C++バージョンでautoを使用していた場所のenumに注目してください。 この型も自動的に推測されますが、enumを使うとindexをコンパイル時に計算することが強制され、 static assertでのみ使用することができます。

このルックアップ(staticIndexOfによるコンパイル時線形探索)はインスタンス化あたり(つまりキーあたり)一度のみ行われ、 結びつける実行時コストはありません。 また、静的に既知のインデックスによる配列のインデクシングは実行時のオーバーヘッドを追加しません。

trigger()のオーバーロード

そして、動的なキーを受け付けるようtriggerをオーバーロードします。 テンプレートと非テンプレートオーバーロードの両方が隣り合って有るのは珍しいことではないため、 実行時ルックアップの実装のみに専念しましょう。 1つの方法としては、マップオブジェクトの構築中にある(自分で試すことができます) 組み込み連想配列を使うというのがありますが、 数の少ないキーについては、既知のすべてのキーと要求されたキーとを比較する線形探索はそんなに悪くはないはずです。

  void trigger(string event) {
    foreach (i, e; events) {
      if (event == e) {
        foreach (c; callbacks_[i])
          c();
        return;
      }
    }
    assert(false, "trying to trigger an unknown event: " ~ event);
  }

何が起きているのでしょう? 外側のforeachは、stringのコンパイル時タプルであるeventsをイテレートしています。 これは本当はループではありません – コンパイラはこの静的foreachの本文を一度タプルの各要素に対してペーストし、 その要素をeに、インデックスをindexに置き換えます。 結果としてまるで3つのifが連続してあるようになります:

      if (event == "foo") {
        foreach (callback; callbacks_[0])
          callback();
        return;
      }
      if (event == "bar") {
        foreach (callback; callbacks_[1])
          callback();
        return;
      }
      if (event == "baz") {
        foreach (callback; callbacks_[2])
          callback();
        return;
      }

1対1

これで全てです。 両方のバージョンをダウンロードし、しばらくコードを眺めコンパイルすることができます。 DバージョンはDMD、GDCまたはLDCでコンパイルできます。 私のマシン上で、C++のそれと比べて著しく速くコンパイルされます(最低10回の連続試行、すべてx86_64で-O3でコンパイル):

  C++ (g++, clang++) D (gdc, ldc2)
GCC/GDC 6.2.0 0.98s 0.45s
Clang 3.9.1/LDC 1.1.0 1.09s 0.67s

小さなトイプログラムのコンパイルにかかる時間から重要な結論を引き出すことはできませんが、一般的に、 Dは高速なコンパイルができるよう設計されており、取り込まれるライブラリコードの量がはるかに少ないことは言うまでもありません。

そしてイベントの名前を打ち間違えた時どうなるか? Dフロントエンド(3つの主要なコンパイラ全てで共通)はエラーメッセージの量と有用性のバランスを取ろうとし、ここでは非常にうまく機能します。 我々が見ることになるのはこれだけです:

es.d(23): Error: static assert  "trying to trigger an unknown event: unknown"
es.d(102):        instantiated from here: trigger!"unknown"

C++ではどうでしょう? 私のシェルでは、static_assertからの重要なメッセージを見るために大体100行の大きく強調されたメッセージをスクロールしなければなりませんでした (ClangのハイライトはGCCのものよりは悪くなかったですが)。 昔はC++のエラーメッセージを人が消化できるものに変換するツールがありました。 あれはまだあるんでしょうか?

最後にチェックするのはパフォーマンスを失っていないかどうかです。 下のグラフで静的、動的ディスパッチのDバージョン vs. C++バージョンの比較を見ることができます。 Dバージョンは両方のケースで速いように見えますが、これは限られたマイクロベンチマークです。 Dの動的ルックアップは小さなセットを好む違うアルゴリズムを使っているためより良い結果を出しているのかもしれません。 静的ルックアップの~10%のスピードアップは、std::functionが各コールでdelegateがするよりも少し多くの仕事をしている可能性が高いです (アセンブリをチェックしてください: DC++)。 より大きなアプリケーションではコールバックでなにか意味のあることをしていることには気づきません。 ので、2つのバージョンは同等に良い結果を出していると仮定しましょう。

Event system performance: D vs. C++

結論として、Dでは複雑なライブラリに頼ることなくC++と同様の結果が得られました。 Dの実装は明快で、少ない言語の基本機能と標準ライブラリのみを使っています。 超絶クレバーになった感じはせず、新しいことを学ぶ必要もありませんでした。 しかしそれはまさに保守性の高く、理解しやすいコードに期待することではないですか?

本当により良いのでしょうか?それについて絶対的なスケールはありません、しかし他の要素が比較的重要でない場合は、 おそらく私は外部ライブラリに依存せず、コンパイルが速く、 なにかうまく行かなかった時に恐ろしいエラーメッセージを大量に生成しないソリューションに賛成するでしょう。

Dでのhana::map相当のもの

しかしDでhana::mapのように振る舞うデータストラクチャが必要になったらどうでしょうか? 結局、常に同じ型の値を持つとは限りませんし、整数インデックスを介して使うのはちょっとプロフェッショナルな感じがしません。 これは可能なのでしょうか?

前提条件

唯一の障害はコンパイル時エンティティ(型または値)はオーバーロードされたインデクシングオペレータへの実行時引数として使えないことであることがわかりました。 これを克服するため、Hanaが使うのと同じ技術をDに適用することができます。 単一の値または型でパラメータ化された構造体テンプレートを考えてみましょう。 私はそれをなんと呼ぶか知らないため、Entityとしましょう。

struct Entity(arg...)
  if (arg.length == 1)
{
  static if (is(arg[0])) {
    alias Type = arg[0];
  } else static if (is(typeof(arg[0]) T)) {
    alias Type = T;
    enum value = arg[0];
  }
}

たとえばEntity!"foo"()またはEntity!double()と書くことで具体的な構造体型をインスタンス化し、オブジェクトを生成できます。 そのようなオブジェクトは状態を持ちませんが、異なるテンプレート関数のインスタンス化を選びます。

普通の関数呼び出しと異なり、構造体オブジェクトの構築には括弧が必要で、Hanaの_c_sサフィックスと比べて少し冗長になります。 より簡潔にするにはいくつか方法があり、パラメータ化されたenumはそのひとつです:

enum c(arg...) = Entity!arg();

static assert(is(c!int.Type == int));
static assert(is(c!"foo".Type == string));
static assert(c!"foo".value == "foo");
static assert(c!42.value == 42);

ユーザ定義リテラルのよく似たシンタックスがstd.conv.octal で最初に使われたと伝えられています。

値の格納

マップそのものに取り掛かりましょう。 異なる型の値を保持でき(std.typecons.Tupleのように)、 キーは型かコンパイル時の値で、このようにインスタンス化される何かがほしいです:

struct Bar {}
Map!(
  "foo",  int,           // 文字列 "foo" をint型の値にマップします
  Bar,    string,        // 型 Bar をstring型の値にマップします
  "한",   string[]) map; // 文字列 "한" をstring[]型の値にマップします

インターリービングキーと値を分割し、値自体の記憶域を宣言する必要があります:

struct Map(spec...) {
  alias Keys = Even!spec;
  alias Values = Odd!spec;
  Values values;

EvenOddは標準のものではありませんが、素早く実装することができます:

template Stride(size_t first, size_t stride, A...) {
  static if (A.length > first)
    alias Stride = AliasSeq!(A[first], Stride!(stride, stride, A[first .. $]));
  else
    alias Stride = AliasSeq!();
}

alias Odd(A...) = Stride!(1, 2, A);
alias Even(A...) = Stride!(0, 2, A);

valuesは型リストValuesのすべての型の要素からなる組み込みタプルです。 これはmap.values[2]のように整数定数を使ってインデックスできます。 先ほど見た「静的foreach」を使いイテレートすることもできます。 これはキーまたは値を自由にイテレートすることができるということを意味します。 やってみましょう:

  // 構造体リテラル構文で初期化
  auto map =
    Map!("foo", int, Bar, string, "한", string[])(
      42, "baz", ["lorem", "ipsum", "dolor"]);

  // キーでイテレート
  foreach (K; map.Keys)
    writeln(K.stringof);

  // 値の型でイテレート
  foreach (V; map.Values)
    writeln(V.stringof);

  // 値でイテレート
  foreach (value; map.values)
    writeln(value);

オペレータ

Hanaは与えられたキーがマップに存在するかをチェックするための自由な関数テンプレートcontainsを提供します。 Dでは、ふつうinオペレータが使われます。 これはopBinaryRight を実装することでオーバーロードすることができます。 それはコンパイル時の情報(引数の型)のみに依存するため、staticとして宣言できます:

  static bool opBinaryRight(string op, Key...)(Entity!Key key)
    if (op == "in")
  {
    enum index = staticIndexOf!(Key, Keys);
    return index >= 0;
  }

動作するのを見てみましょう:

  static assert(c!"foo" in map);
  static assert(c!Bar in map);
  static assert(c!"한" in map);
  static assert(c!42 !in map);

コンパイル時キーを使って値をルックアップするには、staticIndexOfを使い、もしキーが見つからなかった時は意味のあるメッセージを添えます:

  private template IndexOf(alias Key) {
    enum IndexOf = staticIndexOf!(Key, Keys);
    static assert(IndexOf >= 0,
      "trying to access a nonexistent key: " ~ Key);
  }

これはインデクシングオペレーターたちを実装するのに使えます。 なぜ1つではなく「たち」と言ったのか? operator[]が代入演算子のように更に操作できる左辺参照を返すC++とは違い、 Dでリードオンリーインデクシング単純な代入のインデクシング複合代入のインデクシング、 のオペレータは別々にオーバーロードされます。

  auto opIndex(Key...)(Entity!Key key) const {
    return values[IndexOf!Key];
  }

  auto opIndexAssign(T, Key...)(auto ref T value, Entity!Key key) {
    return values[IndexOf!Key] = value;
  }

  auto opIndexOpAssign(string op, T, Key...)(auto ref T value, Entity!Key key) {
    return mixin(`values[IndexOf!Key] ` ~ op ~ `= value`);
  }

すべてのケースで、TKeyは引数の型から推測されます。 IndexOf!Keyの評価とvaluesのインデクシングはともにコンパイル時に完了します。 テストしてみましょう:

  // コンパイル時ルックアップ、実行時代入
  map[c!"foo"] = 42;        // opIndexAssign
  map[c!Bar] = "baz";
  map[c!"한"] ~= "lorem";    // opIndexOpAssign!"~"
  map[c!"한"] ~= "ipsum";
  map[c!"한"] ~= "dolor";

  // コンパイル時ルックアップ、実行時比較
  assert(map[c!"foo"] == 42);  // opIndex
  assert(map[c!Bar] == "baz");
  assert(map[c!"한"] == ["lorem", "ipsum", "dolor"]);

パフォーマンス

これで全部です! 我々はhana::mapのように、実行時風シンタックスでコンパイル時にルックアップとイテレーションができるマップを手にしました。 それは何ら特別なものではありません。 ただの日々の何でもないワンライナーの集まりです。

実装したMapを使ってEventSystemを修正してみたいかもしれません。 我慢できないなら、同じアーカイブに実装があります。 このバージョンと前のバージョンの間でコンパイル時間の計測可能な違いは私には検出できません。 そして下のグラフでわかるように、実行時のパフォーマンスも同じです。

Event system based on static Map in D vs. previous solutions

問題はこれがDでの正しいデザインチョイスかどうかです。 オペレータ[]ingetcontainsのような「普通の」テンプレート関数で簡単に置き換えられる糖衣構文で、 厄介なc!argを作る必要はありません。 コンパイル時エンティティのリストや、値のタプルの要素のイテレーションは組み込み言語機能で、どちらも必要ありません。

要約

これはDでHanaのエミュレートを試みる最初のものではありません。 たとえば型オブジェクトに関するこの投稿 を見てください、型のクイックソートの興味深い例があります。 普通の実行時のコードのように見えるメタ関数を作るHanaのトリックはDにも適用できますが、Dの組み込みメタプログラミング機能のせいで、 それでコードの可読性やプログラマの生産性が大幅に向上したりはしません。 新しいCTFEエンジン が完成しマージされるまでは、おそらく無用に ビルド時間を長くする だけです。

トークはC++20の提案された機能で可能になることのいくつかの例で結論付けられます。 名前付き引数、型リストのforeach、リフレクションによるJSONへのシリアライズ。 その全てが何年も前にDで、より洗練された構文に、より少ない知的努力によって、メタプログラミングからC++でそれをする時の面白さをすべて取り除いた上で可能だったことなのであなたは驚かないかもしれません。

  1. 訳注: 訳をこちらから引用しました