C++17の標準ライブラリの参考書を書く

江添がドワンゴに入社してから、もうかれこれ3年目になる。そろそろ、「江添ごときがC++の規格で飯を食っているのはけしからん。俺はC++の規格にも詳しいしC++コンパイラーも実装できる。俺が代わりにやる」という強者が出てきて私の仕事が楽になって欲しいのだが、残念ながら、そのような状況にはなっていない。より一層のC++の啓蒙活動が必要だ。

ところで、2017年に制定される予定のC++17規格が迫っている。すでにドラフトには多くの新機能が入っている。C++17の参考書を書くのであれば今から始めるしかない。まだ紙の本として出すかどうかはわからないが、とにかく書き始めることにする。

前回のC++11のコア言語の参考書の執筆と、Bjarne Stroustrupのプログラミング入門書の査読を経て、私はいくつかの教訓を得た。

• 不必要に堅苦しく難しい文章を書くな。簡潔で必要最小限の文章を書け
• 参考書のソースコードはファイルを分割しろ
• 参考書のサンプルコードは自動でテストしろ

私の最初の本も、Bjarne Storustrupのプログラミング入門書も、必要以上に文章が堅苦しく複雑で読みづらかった。これは改善しなければならない。

私の最初の参考書のソースコードは、単一のXHTMLで書かれた。最終的にはファイルサイズが1MBを超えてしまい、テキストエディターでの編集が難しくなってしまった。

Bjarne Stroustrupのプログラミング入門書のサンプルコードは、数割がコンパイルすら通らないお粗末なものであった。これは一度書いたソースコードを手で修正したにもかかわらず、コンパイラーによるチェックを行わなかったためである。参考書は、何度もの修正編集を経て完成する。そのため、参考書の中のサンプルコードは、参考書のソースコードから自動で抽出して自動でコンパイルにかけてテストする仕組みを作る必要がある。

そこで今回、上の3つの教訓を元に、以下のような対策を講じた。

• textlintを使って日本語の文章に制約をかける
• Markdownで書いてPandocで他のフォーマットに変換する
• 参考書のソースコードからサンプルコードを抽出してGCCとClangでコンパイルにかける仕組みを作る

textlintは、node.jsで書かれた日本語の文章を形態素解析して特定のルールに従っているかどうかをチェックするためのツールである。あらかじめ技術文書用のルールが用意されているので、今回はこれをそのまま使う。デフォルトのルールはやや厳しいと思うのだが、文章を簡潔にするための制約として甘んじて受け入れる。

PandocはMarkdownなどの様々な入力フォーマットから、更に多数の様々な出力フォーマットへの変換を行うツールだ。アスキードワンゴ編集部はtexを使っているが、作業用のtexを生成するのもMarkdownからPandoc経由で生成している。

参考書のソースコードからサンプルコードを抽出してコンパイルするテストは、適当なツールがなかったので適当に実装した。C++で書いて200行ぐらいだった。

あとは通常のプログラムと変わらない。参考書のソースコードはテキストファイルであるのでgitでバージョン管理できる。アスキードワンゴ編集部の編集者はgitもGitHubも使えるので、修正作業などはgitとGitHubのPRを経由して行うことができる。ソースコードから参考書のビルドにはMakeを使う。

思うに、すべての作家はgitを使うべきである。また、簡単なコードのひとつぐらいは書けたほうが執筆に必要な作業のやテストの一部を自動化できてよい。

さて、ここまでは理想通りだ。しかし、現実は理想通りには行かない。

私がこれから書くのは、C++17規格に準拠した参考書である。しかし、C++17は2017年の年末になるまで制定されない。当然、執筆中にドラフトの内容が変わっていくので、執筆当時のドラフト段階の規格は、正式な規格とは異なる可能性がある。もちろん、サンプルコードのテストは用意したので、規格準拠のC++17コンパイラーが出れば検証できる。しかし、ここに最大の問題がある。

現在、ドラフトに完全準拠しているC++17コンパイラーは存在しない。したがって、いま執筆している部分のサンプルコードは、コンパイラーによるチェックができない。私の予想では、C++17のコア言語の規格に準拠したC++コンパイラーのリリースには、まだ2年ほどかかると見ている。C++17の標準ライブラリの規格準拠の実装はさらに遅れるだろう。

状況は2009年ごろにC++11のコア言語の参考書を書いていた時と同じだ。ただし、当時と違って今はClangがある。Clangの規格準拠度と実装速度は素晴らしいので、当時よりはマシだ。例えば、Clangは最新の構造化束縛を不完全ながら実装し始めている。

std::tuple< int, float, double > f()
{
    return { 1, 2.0f, 3.0 } ;
}

int main()
{
    auto[ a, b, c ] = f() ;
}

ただし、コンストラクターからのクラステンプレートのテンプレート実引数推定はまだ実装していない。

// std::tuple<int, float, double>
std::tuple t( 1, 2.0f, 3.0 ) ;

そして、ライブラリの参考書の執筆はコア言語以上に難しい。