2012年から今年(2014)にかけて、C++ Advent Calendarに3回参加した感想のような忘備録のような話。
- C++ Advent Calendar 2012 15日目「本当は怖くないムーブセマンティクス」
- C++ Advent Calendar 2013 15日目「スレッドセーフという幻想と現実」
- C++ Advent Calendar 2014 21日目「メモリモデル？なにそれ？おいしいの？」
参加の経緯
C++ Advent Calendar jp 2010やC++11 Advent Calendar 2011, Boost Advent Calendar 2011に上がっている記事を読んで、同じ技術分野でまとめて多様な投稿者／テーマの記事が読めるのって凄いなーと思ったのが発端だった気がする。
数年前までオレオレWikiサイト上に適当なメモを書き散らしていたけど、最近(当時)そういうアウトプットしてない事にあまり宜しくないなと思い立って、はてなダイアリーにアカウント作ったのが2012年のお正月。昔から作文や読書感想文のような文章を書くのが苦手＆嫌いだったこともあり、はてダは自分向けの無機質な技術調査忘備メモという雰囲気に。その後はてなブログにもアカウントだけ確保し、せっかくなのではてダとトーンを変えて文章として読める記事置き場にしようと使い分けを決める。
2012秋冬頃に自分でもAdvent Calendarで役に立ちそうな内容を書いてみようかなーと思ったのが先か、既存のムーブセマンティクス解説って右辺値参照と同時に説明してて初学者には分かり辛いなーと思ったのが先か、とりあえずこの頃から構想を練り始めたような記憶がある。
記事をかく
その記事で想定する対象読者の技術レベル（想定読者）、読了後に分かったつもりになってほしい理解度（到達点）、記事全体を通しての主張一文（要旨）を設定するようにしている。想定読者が到達点にたどり着くまでの骨子（もくじ）を作って、そこからは実際に各節を書いていきながら随時調整という感じ。要旨と関連があるが少し外れた話や、説明で取り上げない技術キーワードはできるだけ削ぎ落とすようにしている。図やコードだけの解説は基本避け、あくまで文字のみで概念を説明しようとがんばるも、複雑で伝わる気がしない部分は日和ってイメージを併置する。
一度書き終わったあと可能な限り全体を通して読み直し、ストーリー展開を考慮してギャップが大きい箇所の穴埋め、要旨から外れた事項の冗長説明を削除、技術用語の分離／統合と表記統一、翻訳語／カタカナ表記の選択や英語注記の必要有無、語句選択や語順入れ替えによる読みやすさ、否定的・攻撃的なネタをなるべく使わない、等に気を付けて推敲する。最終的には公開前に10回以上は読み返していると思う。それでも公開後、2～3日は細かい調整を結構している。初日に読まれた方、すんません。
文章ボリュームは9500字前後に落ち着いているが、特に測ってるわけではもなく、このくらいがコントロールできる限界みたい。現状は、これ以上多いと時間的にも構成的にも難しい。
2012年：ムーブセマンティクス
- 想定読者：既にムーブセマンティクスや右辺値参照の解説記事をいくつか読んでいて、結局ムーブセマンティクスって何なのかいまひとつピンと来てない人（＝昔の自分）。
- 到達点：ムーブセマンティクスという考え方は分かったので、右辺値参照の記事をもう一度読んでみたら分かりそうな予感。
- 要旨：ムーブセマンティクスそれ自体は難しくないよ。
要旨が単純で到達点を低めに設定したこともあり、想定読者の到達点までの学習曲線を可能な限り緩やかにした。このときのねらいは2つあって、初学者向けに「ムーブセマンティクス知らなかったけど分かった気になれること」と、知ってる人向けに「右辺値参照に言及せずムーブセマンティクス解説をここまでできること」を頑張ったつもり。
（細かいところは2年前なので忘却の彼方）
2013年：スレッドセーフ
- 想定読者：ミューテックスの使い所をなんとなく理解している、マルチスレッド・プログラミングの中級者くらい。「並行アクセスするなら絶対に排他制御が必要でしょ？」
- 到達点：C++マルチスレッド処理でいつミューテックスを使うべきか、どのような条件なら使わなくても良いかを判断できる。
- 要旨：マルチスレッドではReadOnlyのみという捉え方、C++構文上では
const修飾がとても大事。
C++11マルチスレッド対応紹介だと新規追加クラス説明で終わっちゃうので、最初から地味な縁の下にフォーカス。要旨は記事前半で言い切った。とはいえ前半だけではあまりに形式的すぎるので、後半に実践的な具体例を追加してある。元ネタはStack Overflow(en)での頻出質問から。
前半の学習曲線が直線的になるようにしたため、分かっている人には最初は当たり前すぎてつまらないと思う。途中から新しい知見が得られて合流できればOK。最後まで当たり前じゃねーかと感じるなら、既に到達点を超えている人なのでスコープ外。当初はスレッドセーフなクラスの実装方法やmutableデータメンバにも言及しようと思っていたたが、分量的に多すぎるのと時間の都合でばっさりカット。
2014年：メモリモデル
- 想定読者：C++メモリモデルについて興味を持っていて、x86やARMなど既存マルチプロセッサでのメモリモデルとの差異について混乱している人（＝つまり自分）。
- 到達点：ソフトウェア／ハードウェアの両メモリモデルと、コンパイラ／プロセッサとの関係性を整理できる。
- 要旨：ソフトウェアとハードウェアのメモリモデルは対象レイヤが違う。前者はコンパイル時と実行時の両者に影響を及ぼす。
選んだテーマがヘヴィなぶん、敷居が低くみえる雰囲気を目指した。絞った想定読者だけではターゲットが狭すぎるので、ハードウェアの話が分からなくても通して読めば雰囲気が伝わるようにしたつもり。逐次一貫性について分かった気分になってもらえれば良し。セクション間で大きなギャップが出来ないよう努力したが、その代償として言及する技術範囲に対してやたら簡素な説明の連続になっている。仕方ないね。
初期には「Boost.Atomicの参照カウンタ実装を題材にacquire/release, relaxed+fenceの説明」という案もあったが、seq_cstへの拡張をスムースに説明できる気がしない／理解できてないのと、この手の際どい処理を書く状況自体が相当ニッチなため、最終的には今回の要旨にかえた。
公開したあと
記事公開後は、はてなブックマークのコメントとかTwitterでエゴサーチしてニヤニヤしてます。はてブ数的にはスレッドセーフの話題が一番反響が良かったみたい。ミドル層がターゲットなので、妥当な結果かなぁとは思う。書くのに一番苦労したのはムーブセマンティクスかもしれない。メモリモデルは正直ニッチすぎてどうかなと思っていたけど、はてブ数ではムーブセマンティクスを超えてた。何てこったい。それぞれの要旨にマッチする感想もあれば、違う解釈での反応もあったりして楽しい。
Advent Calendarに求めるものは人ぞれぞれだと思いますね（特に今年の某言語界隈とか）。来年以降もネタができれば参加するつもり。
予定は未定。