プログラミングの魔導書 〜Programmers' Grimoire〜 Vol.1

ついに出ました。

自分は「Chronoライブラリで考える型システム」という題で書かせて頂きました。

内容について

どんな内容かというと、ChronoというC++0xで新しく入る時間ユーティリティを通じて、型システムがいかに素晴らしいかというのを語っています。6ページ弱しか無いので、サクッと読めると思います。
そもそもどうしてこのテーマにしたかというと、当初はChronoライブラリを解説する予定だったのですが、このライブラリの単位を型で表現するという方法が非常に素晴らしいので、このライブラリを例として、型について話すことしました。型について考える機会になればいいかなと思います。

ratio は万能じゃない

id:bleis さんが

確かに、単位を汎用的に扱えるととても嬉しい。嬉しいんですが、ratio だけじゃ解決できない単位が身近にあるんですよね・・・*2


*2:あ、記事中に「ratio さえあれば何でもできるぜ!」とか書いてあるわけではないです。ただ、「そう言えば前に単位でいろいろ苦労したなぁ」という懐古をしてるだけです。単位と言っても学生がびくびくするアレじゃないですよ。いや、まぁアレでも苦労しましたががが

プログラミングの魔導書 Vol.1 発売前レビュー - ぐるぐる~

と書いているように、ratio で何の単位でも表せるようになるわけではありません。
実は Boost には Boost.Units なんていう、単位を専門に扱うライブラリなんかもあったりします。こういったものは、要件に応じて使い分けることになるでしょう。
どうしても既存のライブラリで適切に表現できないのであれば、自分でその単位を表現する型を作り、そして、その後に適切な変換子を用意することになると思います。

これだけならまだ対処のしようはあるのですが、更にやっかいなのが、ある単位からある単位に変換するために、標高だとか、密度だとか、温度だとかの情報が必要になる場合です。

ここまでくると、「じゃぁ SI 基本単位全部持つか」みたいな話に・・・うーん、どうするのがいいんでしょうね。

プログラミングの魔導書 Vol.1 発売前レビュー - ぐるぐる~

この場合であればその変換したい単位や、標高や、密度や、温度をそれぞれ型で表し、目的の型へ変換する関数を作ることになると思います。もしかしたらもっと細かい形で単位を作るかもしれませんし、もし標高や密度というのがコンパイル時に決定する(そんなことあるのかどうか知りませんが)のであれば静的に解決できる可能性もあります。ここらは要件によって変わってくると思うので、既存のを改造するなり新しく作るなりで自分が本当に表現したいものを正しく作るのがいいんじゃないかなと思います。

反省点とか

型を使った有用な例として単位を出していますけど、この例が出しゃばりすぎて、型システムという部分についてはあまり書いてなかったなぁとか思ったり。まあ概念的な話ばっかりしても楽しくないだろうし、これはこれで良かったのかもしれません。
あと、どうやら自分は長文を書くのが非常に苦手みたいで、かなり長く書いたつもりの文章が、後から読んでみるとすごく急いで説明しているようにしか見えないんですよね。ここは直したいところなのですけど、どう直せばいいのかよく分からなかったり。
次また何か書く機会があるときは、この辺を何とかしたいなぁと思っていたりします。

他の方の記事の感想とか

創刊に向けて

魔導書が出ることになった経緯とか書かれています。

私の発想に端を発しています。

つまり id:uskz さんが主犯です。

Bjarne Stroustrupへのインタビュー

C++ を作った張本人である禿Bjarne御大の素晴らしいインタビューです。
個人的に素晴らしいと思ったのは、

初心者は、言語の技術上の詳細よりも、プログラミング自体に集中するべきだ。

という部分。これを読んで、

言語は、問題を解決するための自分の考えをプログラムにマッピングするための道具でしかない。で、プログラマは問題解決の方法を考えるのに大半を費やすわけで、言語云々より前にそっちを勉強する方がよっぽどいい。

http://twitter.com/melponn/status/16545042199

とか考えるようになりました。

boost::serializationの紹介 前編

リアライゼーション、特にポインタ周りのシリアライゼーションはいつもすごく苦労して、それのせいで設計まで結構嫌な感じになってしまうことがあったりするのですけど、Boost.Serialization を使うとその辺まで綺麗に解決するというのは素晴らしいですね。
あとデフォルトコンストラクタを持っていないクラスでも(面倒ですけど)デシリアライズできるというのは驚きでした。さすが Boost。

Variadic Template -お前を待っていた-

Variadic Templates を使って、WindowsEnum 系関数に関数オブジェクトを使えるようにするためのラッパーを簡単に作るためのジェネレータを作っています。こういった既存の似たような(でも引数の数が違う)関数をうまくラップするのにも Variadic Templates が使えるというのは驚きです。
まあ1つのプロジェクトでそんなに大量の種類の Enum 系関数を使うことは無いですし、1個1個ラップしていってもそんな手間にはならないのでこれぐらいなら手で書いてもいいような気もしますが、この手法自体は結構いろんな場所で使えそうです。

オーブンレンジクッキング

自分は C# の拡張メソッドとか大好きな人なので、Oven のような書き方は結構好きだったり。
ただまあ、やっぱり言語側のサポートが欲しいなぁとか思ったり・・・。

Hello, C++ World!

結構基本的なことばっかり扱っているのですが、using 宣言をするとそのスコープに属するようになるとか、cout のデストラクタではフラッシュされずに ios_base::Init で行われているとか、知らなかったこともあったりして結構勉強になりました。

Crawling in the Stream

C++ の標準で用意されている基本的な入出力にも関わらず不遇の扱いを受けている iostream さん。ちゃんと使えば結構まともに使えるライブラリなのかなとか思いました。
詳しく知るために Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference とか英語リーディングの勉強がてら読んでみようかなって気分になりましたが、まだ買ってすらいないですはい。

メタプログラミングノキワミ アッー!

タイトル通りの内容ですよね。こういうぶっ飛んだ内容は流し読みする分には結構好きだったりするのですけど、査読のために真面目に読んだので結構疲れました。いやまあ書いた本人が一番疲れるのでしょうけど。
でも目的としては十分よくあるケースだと思います。というかですね、sizeof が「式の計算結果の型のサイズ」を返すくせに、「式の計算結果の型」を返す仕組みが存在しない C++ がおかしい気も。
あとまとめの文章でどうしても笑ってしまいます。こういう書き方してみたい!

Boost.AsioによるHTTP通信入門

個人的に、こういう「実際の問題を解決するために〜を使う」というのは、単にライブラリを解説しているものより好きだったりします。問題は自分が HTTP のことなんて全く知らないということだったりするのですけど。
ただ全体的に非常に綺麗なプログラムになっていると思います。実際のコードでこういうのが書けたらかっこいいですよね。

C++の歴史

Bjarne 御大も昔は人間だったんだなぁと思いました。

標準化委員会は、テクニカルリポートを発行した。その主な内容は、C++の多くの機能は、実行時のパフォーマンスに、影響を及ぼさないということの説明である。

しかしこの資料を日本人で、特に組み込みをやっていて better C みたいな使い方をしている人で、実際にこれを読んでいる人はどれだけいるんだろうかとか思ったり。

BoostCon2010体験記

やっぱり日本から参加しようと思うとかなりお金が掛かるんだなぁと思いました。飛行機代やもろもろを含めて、全部で30万ぐらいいるそうな。
Boost.Serialization の人に素晴らしいとか言われたり Boost.Spirit の人と知り合いになったり、近藤さんすごいなぁとか思ったりしました。

編集後記

思い起こせば約半年前、法務局での会社登記手続きの帰り道に「一年後ぐらいには雑誌を出したい」と発したuskzさんの目には、弊社が刊行したこの魔導書が予知能力で見えていたのかもしれません。

とか書いてあって、uskzさんパネェとか思いました。本を出すとかそんな簡単にできないと思うのですけど、さすがというか意外というか。

レビューについて

記事を書く人は相互にレビューを行います。でまあ、

他人のプログラムはアラを探して指摘するためにあります。

http://twitter.com/melponn/status/18670097360

とか書いているように、自分はこういうのが結構好きだったりします。自分がレビューを行う際は、

査読(ブックレビューと言うべきか)とはこのように自分の意見を著者にぶつけていく作業である。

2009-06-18

というのを心がけているので、ちょっとしたことでもすぐに指摘しました。でまあ、どうでもいいような指摘や間違った指摘をして迷惑を掛けたりもしましたが、少しでもクオリティが上がっているのなら嬉しいなぁと思います。
それにしても指摘でやっかいなのが、何か違和感がある文章だなーとか思うけど、それを系統立てて説明できない場合ですね。それも一応何か違和感があるよーと指摘するのですけど、修正されたらされたで「ほんとにこれ修正してもらってよかったのかな?実は自分の感覚がおかしいだけじゃね?というかこんな些細な部分てどうでもよくね?むしろ著者の文章のリズムを狂わしただけなんじゃね?」とか考えることになっていろいろ悩んだりもしますが、今日も元気にレビューレビュー。


そういえばレビューと言えば、Bjarne がインタビューで言っているように

初心者は、言語の技術上の詳細よりも、プログラミング自体に集中するべきだ。これは難しい。数年前、テキサスA&M大学でプログラミングの講義をしたときに直面した問題だ。その努力の結果を、「Programming: Principles and Practice using C++」という本として出した。これは今、日本語への翻訳作業が進められている。

とあるように、「Programming: Principles and Practice using C++」が日本語で出ます。これにチョロっとだけ関わってるので中身読んだのですけど、めちゃめちゃいい本ですこれ。まさに『プログラミング』の本です。


とまあ、関係ない話をしちゃいましたが、魔導書vol1に参加できて楽しかったです。vol2もまた、レビューだけでもいいので参加してみたいです。