（以下、カノッサの屈辱（テレビ番組）のノリでお願いします）

コンピュータの理論を確立したチューリング。彼は、無限のテープの長さを持ち、単なる計算を行うだけのチューリングマシンを夢想した。

しかし、我々の生きる現実世界におけるコンピュータでのプログラムに於いては、計算の失敗＝エラーが発生するのは避ける事ができない宿命である。ネットワーク接続失敗、ファイルが見つからない、メモリが確保出来なかった…等々。すべてのエラーを書き出すには、それこそ無限の長さの紙が必要であろう。プログラム進化の歴史は例外との戦いであると言っても過言ではない。今回の講義では、プログラミング言語の様々な進化のうちの「エラー処理」に着目し、その長い戦いの歴史を概観する。

まずは、いにしえの先エクセプション紀におけるエラー処理を見てみよう。

先エクセプション紀：エラーコード-1の時代

エクセプション（exception）と呼ばれる隕石が衝突する以前の時代は先エクセプション紀と呼ばれている。この時代での例外処理の特徴は、エラーコードという概念の存在である。数学の関数を模したプログラム言語の「関数」とよばれる生物は、値を一つだけ戻すことができる。当時地球を支配していたAPI関数たちはこの「戻り値」を用いてエラーが発生した旨を伝えることで、上位のプログラマにその処理を託した。

//int readNumberFromFile(const char* filename);
// ファイルを読んで、そこに書かれた数字を返す。失敗した場合は-1を返す。
// ex) number.txtに"12"と書かれていれば、12を返す。
int status = readNumberFromFile("number.txt");

これがこの時代における典型的な「失敗する可能性のある関数」の姿である。戻り値として計算が失敗した場合に特別な値を返すことでその旨を表現し、多くの場合、-1などマイナスの値が好んで使われた。これを「エラーコード」と呼ぶ。

しかし、上記の例を見れば分かる通り、正常な結果と失敗した結果を同じint型の変数一つで表してしまうことで、いくつか問題が発生した。例えば、上記のプログラムでは、もしもファイル中に「-1」と書かれていた場合、このAPI関数は「正常な結果として」-1を返してしまうかもしれない。プログラマにはそれを区別する事ができない。必ず非負の数値が書かれていることを要請し、マイナスの場合はすべてエラーとすれば問題は解決するが、APIに要求とされる機能によってはそれは許されないかもしれない。そのような場合、このように苦肉の策として追加のポインタを使うケースがあった。

// ファイルを読んで、そこに書かれた数字を返す。
// 失敗したか否かの情報がstatus内に格納され、失敗したら-1が格納される。
// int readNumberFromFile(const char*filename, int* status);
int status = 0;
int result = readNumberFromFile("number.txt", &status);
if(status == -1)....

このポインタを用いて間接的に値を返す手法によって、プログラマに結果の値を一つしか伝えることができない、という関数の問題を回避することができた。しかし、この方法には明らかに欠陥がある。「処理が失敗したか否か」も、「成功した場合のその結果」もどちらも「関数から返ってくる値」のはずであるが、この方法ではその対称性が崩れてしまっており、あたかもstatusは入力値のようにも見えてしまっている。このおかげで、せっかくエラーを報告しても無視されてしまう悲しい事故が散見された。また、どちらをポインタとして渡して格納させるかはライブラリごと、関数ごとに違い、勘違いして双方を入れ替えてしまう悲劇も発生していた。また、Javaなどのように「参照型」を渡すことができない言語においては、この方法を（直接は）使うことができない。

Windowsの一部のAPIやOpenGLなどでは、別の関数を呼びエラーの発生を確認するという方式も考えだされた。

// int readNumberFromFile(const char* filename);
int result = readNumberFromFile("number.txt");
int status = getError();
if(status == -1) ....

この方法では、失敗する可能性のあるAPI関数の呼び出しの直後に特定の関数を呼ぶことでエラーの発生を確認した。当然、エラーを確認するまえに別のAPI関数を呼び出してしまうと、エラーを正しく処理することができない。

// int readNumberFromFile(const char* filename);
int result = readNumberFromFile("number.txt");
int result2 = anotherFunction(); /* !ここでもエラーが発生するかもしれない ! */
// readNumberFromFileのエラーをもはや反映しない
int status = getError(); 
if(status == -1) ....

保守や機能拡張時などにおいては、その事をすっかり忘れてしまい、明後日なエラーメッセージを前に途方に暮れるという事態も珍しいことではなかった。

また、別の関数をわざわざ呼ばなければならない点はやはり手間が大きく、この方式ではポインタ方式よりも、さらに輪をかけてエラーが無視されることとなった。

エラーコード-1の亜種として、nullを返すAPIが棲息する地域もあった。Java大陸や、C++海溝の一部などに見られる化石などから明らかになっている。このような関数呼び出しの場合、一見エラーを返さないような計算に見える：

String data = client.readDataFromFile();

dataがnullであれば失敗である事を示し、そうでない場合は成功した結果を表すという方式である。

この方式も、エラーコードと同様、正しい結果としてnullが返ってくる可能性がある場合にうまく対処できない。さらに「null」というただひとつの値しか返すことができないため、結局失敗した理由を他の方法を用いてAPI使用者に伝えなければならないという問題があった。多くのAPIでは実装工数がないの魔法の一声で、その方法は提供しないこともあった。

エラーコードの体系や伝え方(nullを返す・関数を呼ぶ・エラーコードを使う・ポインタを渡す）は当然、APIの創造主や、APIごとにまちまちであり、APIを消費するプログラマはそれらを個別に理解し、正しく対処することが求められた。そしてもちろん、そこには言語処理系のサポートは一切ない。

結果、そのエラー判定コードが正しいことをコンパイラで事前に判定することができないため、プログラマのその日の体調や気分によってはバグが発生することとなった。

エクセプション隕石の衝突

地球上でエラーコードを持つ多様な生物が棲息していたある日、ついに事件は起こった。エクセプション隕石の衝突がそれである。エクセプション隕石は地球上の多種多様な生物に深刻なダメージを与えたが、特に構造化の三要素へのダメージは深刻であった。

当時のプログラミング言語の構文細胞において、順次・反復・分岐の三生物が共生し、細胞小器官となる進化が発生していた。この三つの器官をまとめて「構造化の三要素」と呼ぶ。

/* 順次（上から下に実行） */
int a=10;
int b=a*10;

/* 反復（繰り返し） */
int sum = 0;
for(int i=0;i<100;++i){
    sum += i;
}

/* 分岐 */
if( isOdd(x) ){
    printf("odd number!\n");
}

しかし、一部の言語はそれよりも原始的なgotoと呼ばれる器官を退化させることなく持ち続け、APIを消費する一部の生物種は、例外の処理に好んでgotoを用いた。

if( mayFail() == ERROR_FAIL ){
    goto fail1;
}
...
fail1:
    /* 失敗時の処理 */

エクセプション隕石は、この原始的なgotoと構造化の三要素との悪魔融合合体進化を発生させた。なぜこのような奇妙な進化が起こったのかは、未だに議論のあるところである。この合体進化した新たな器官は、隕石の名前にちなんで「エクセプション」と呼ばれた。

try {
    int result = mayFail();
    int result2 = mayFail2();
    ....
} catch (Error const& e) {
    /* 例外時の処理 */
}

エクセプションは構造化の三要素のような姿を持ちつつ、goto文のような文脈を跳躍する特性も有する。APIを消費する上位のプログラマは、エラーの発生があたかも無いかのように処理を記述しつつ、最後にエラーに纏めて対処する事となった。

構造化の三要素とエラーコードを用いたAPI消費の多くのケースでは、ひとつでもエラーが発生した場合、次の処理を行うことは通常不可能であったため、多くのプログラムではエラーが発生したら、すぐにgoto文で失敗時の処理に移るということが見られた。

if( mayFail() == ERROR ){
    goto error;
}
if( mayFail2() == ERROR ){
    goto error;
}
if( mayFail3() == ERROR ){
    goto error;
}
error:
return -1;

エクセプションでは、これらをcatch節 という仕組みを使うことで共通化した。すなわち、エラーが発生したら移行の処理は全てスキップし、catch節の中でそのエラーに纏めて対処するということである。

try {
    int result = mayFail();
    int result2 = mayFail2();
    int result3 = mayFail3();
   ....
} catch (Error const& e) {
    /* 例外時の処理 */
}

エクセプションを持つ言語は地球上で広く繁栄することとなった。エクセプション器官を持つプログラミング言語は、オブジェクト指向と呼ばれる骨格も同時に持つことが多く、オブジェクト指向とエクセプションには関係があると考えられているが、先述の議論から構造化プログラミングとの関係の方が深いという異論も存在する。

しかし、このエクセプションは悪魔融合合体であるがゆえに、黒魔術的弱点を有する。

多くのプログラムでは、構造化の三要素が守られる事を暗黙の前提としてソフトウェアが構築されていくが、エクセプションの仕組みではエラーが発生するとそれがgoto由来の文脈跳躍生によってほぼ無化されてしまう。

またエクセプションの仕組みは処理の流れを変えることに依存しているため、処理の流れが複数存在するスレッド環境などではさらに技巧を用いることが必要とされ、多くの場合それはうまく動作することは無かった。

これらの事に端を発した多臓器不全で亡くなる生物は少なくなく、「More Effective C++」などの当時を研究する古医学書では１章をこのエクセプション由来の疾患に割かれている。

さらに、「で、結局纏めて対処しろって言われてもどうすれば良いんだ…」との声も根強く、catch節には何も書かれない事態も珍しい物では無くなった。これを「例外潰し」と呼ぶ。

エラーコードの復権：地殻内空洞での”数学”との遭逢、そしてMaybe種とEither種

エクセプション隕石はエラーコード種を概ね絶滅させたが、地下3000mではほそぼそと生きながらえる事となった。地下3000mには酸素がほぼ存在しないため、好気性生物であったエラーコード種には進化が求められた。そのための遺伝子を提供したのが、地殻内空洞に棲息する「数学」と呼ばれる、一連の生物群である。

この生物種がエラーコード種に提供したのは、「モナド」と呼ばれる強力な遺伝子である。この特徴を詳しく見てみよう。

エラーコード種に起こった問題である「同じ型で成功と失敗を表されるので、正しい結果の”-1″と失敗を表す”-1″の区別がつかない」という欠点を、値の上位に成功か失敗かを表す仕組み1である「Maybe」や「Either」を加えることで表現。さらに、nullの持つ「失敗としてただひとつの値しか返すことができない」という問題も、失敗時の型にその情報を付加できるようにすることで解決することとなった。

-- Leftが失敗、Rightが成功
data Either a b = Left a | Right b
--引数に応じて処理、失敗するかもしれない
mayFail :: ArgType -> Either String Result
-- ----------------
case mayFail arg of
    Left a -> ... --aにはエラーの理由が
    Right b -> ... --bには成功した結果が

思わぬ副作用として、エラーを無視することが出来なくなった。戻り値のMaybe/Eitherから結果を取り出すには、必ずエラーか否かをチェックする必要がある2。

これは今までのプログラミング言語種でも可能であった。Cなら構造体と共用体で、C++ならクラスの仕組みを用いることで実現できる。しかし、それだけではエラーコードかどうかをチェックする今までの方法とあまり変わらず、煩雑なエラーチェックが必要になる。

すなわち、MaybeやEitherの導入だけでは、次のような非常に煩雑な記述が必要になってしまう、ということである。

--mayFailとmayFail2とmayFail3を使った処理
--この三つの関数は、どれも失敗するかもしれないのでEitherを返す。
func = case mayFail arg of
	Left err -> return (Left "error on maybeFail")
	Right ok -> case (mayFail2 ok arg2) of
		Left err2 -> return (Left "error on maybeFail2")
		Right ok2 -> case (mayFail3 ok2 arg3) of
			Left err3 -> return (Left "error on maybeFail3")
			Right ok3 -> return (Right ok3)

この状況に力を与えたのが、かの有名な「モナド」遺伝子である。

モナド遺伝子のbindの力とMaybeやEitherが共生することで、上のような煩雑なエラー処理は次のように至極単純化された。

func = do
    ok <- mayFail arg
    ok2 <- mayFail2 ok arg2
    ok3 <- mayFail3 ok2 arg3
    return (Just ok3)

表層を見ると、エラー処理が全て消え去ってしまっている。エクセプションではエラーを処理するために存在するcatch節が、完全に消滅している。しかし、エラーを「潰した」りはされない。もし、この関数を実行した際にmaybeFail2でエラーが発生した場合、その下位関数のエラー値がそのまま返され、続くmaybeFail3はスキップされる。

-- 途中でエラーが発生すれば、その結果が返される。潰れされない。
func -- -> Left "error occur on maybeFail2"
-- 最後まで成功すれば、最後にreturnした値が返される
func -- -> Right result

エクセプションにあった、構造化の三要素が無化されてしまう事によって生じうる問題はここでもまだ残っているが、MaybeやEitherは制御構造ではなく、単なる値であるため、エクセプションに比べて柔軟である。例えば、エクセプションを用いたプログラミング言語種では「何度か実行し、成功を試行する」といった仕組みを作るのは一般的に面倒であるが、Maybeを使えばこのように簡単である。

-- 渡された関数を何度か実行し、一度でも成功すればその結果を、
-- n回実行しても失敗するならNothingを返す
tryFunc :: Int -> ( Int -> Maybe Result ) -> Maybe Result
tryFunc n thunk =
    if n <= 0 then Nothing
    else
        case (thunk n) of
            Nothing -> tryFunc (n-1) thunk
            Just x -> Just x

この関数を用いてラップすることで、既存のMaybeを返す関数も簡単に「N回試行」させることができるようになる。

func = do
    ok1 <- mayFail
    -- maybeFail2だけは10回だけ試行する。一回でも成功すればよい。
    ok2 <- tryFunc 10 mayFail2
    ....
    return (ok3)

このように、「失敗するかもしれない」処理の内側と外側の行き来が非常に簡単になったことで、エクセプションの問題も対処しやすくなっている。

まとめ

• エラーコードでは…
  • 正しい結果の-1と、エラーコードの-1を区別するのが困難
  • エラーコードのチェックが面倒くさい
  • 大体エラーコードのチェックなんてしなくなってくる
• JavaやC++の例外機構では…
  • 例外が発生すると以降の処理が全部スキップされてしまうことに起因するバグ
  • 例外は潰されるもの
• MaybeやEitherでは…
  • エラーを無視できない
  • 下位で発生したエラーをそのまま上位に渡すのが簡単
  • エラーが発生する処理とその周囲との行き来が簡単

私が現在理解したところによるMaybe/Either/Optionalの利点はこんな感じです。あと文中のHaskellがIOがどこでも起こせるかのような書き方ですが、IOと組み合わせると論点がぼやけそうなんです、ごめんなさい。ツッコミ、お待ちしています。

ちなみに

JavaでもC++でも、匿名クラスやlambda式を多用することでMaybe/Eitherモナドは使うことができます。C++だとこんな感じで実装できます。Javaでもバイトで書いたことがあるのですが、バイトで書いたので手元にコードはありません（ぉ

1. 多くの場合、型によって提供された [↩]
2. Just x <- maybeFailは邪悪なので無視 [↩]

有名な「Effective C++」の続編の本です。未踏の期間が終わったこともあり、読む時間を作ることができました。

この本は英語版で、一応日本語版もあるのですが、訳の評判はあまり良くありません。英語版の方も非常に読みやすい英語で、JavaDocレベルの英語が読めればなんとかなると思います。気のきいたジョークに使われる日常単語がいまいち分からなくて全部調べてたので、いまいち笑えませんでしたが…（ーー；

 Effective C++に比べて枝葉の話が多い

続編ということもあり、前編であるEffective C++では言語の根本的な部分のと比較して、Moreの方では細かい話が多いです。

前著の方では、例えば

• コピーコンストラクタやデストラクタ、operator =を定義しないと勝手にコンパイラが定義してしまいますよ
• 値渡しよりconst参照渡しを考えた方がいいですよ
• newしたものはdelete、new []　したものはdelete[]、と対応させないといけません。
• private継承や多重継承は注意深く使ったほうがいいですよ

といった内容が多く、他言語を使っていたプログラマがC++の世界を理解するには丁度良かったと思うのですが、今回のMoreの方では、

• 関数の引数で暗黙的な変換が起こるのは値渡しかconst参照渡しの時だけで、しかも変換は一度しか起きません
• 参照カウントなスマートポインタ
• デストラクタは例外が起こってもちゃんと実行されるのでリソースリークを避けるのに使えます。
• 多重継承・virtual継承する時のオブジェクトのデータフォーマットはこうなっている（事が多い）ですよ

といった内容です。最後の項目はvtableやvptrの実態がよくわかったので参考になったのですが、その他の項目は今ではインターネット上のC++に関する文章や、STLをある程度使っていると「そらそうよ…」「せやな…」と思ってしまう内容が多く、Effective C++を読んだ時に感じた、あの驚きをもう感じることはできませんでした。Effective C++を読んで少しC++を書き始めた時期に読めばもっと参考になったのでしょうが、数万行書いた後となると…。

改訂が繰り返されているEffective C++と違い、Moreは95年から一度も改訂されていません。STLは出たばかりの時期だったようです。

本を読むよりソースを読んで書いてWebのリソース読むのが好きな人は、まあ読まなくても…。

この本の中で特に一番大きく扱われているのは、参照カウント・スマートポインタです。sharedされている値そのものが参照カウント数を管理する、boostでいうところのintrusive_ptr相当のものをじっくり実装したあと、階層を一個上げてshared_ptr相当のものを実装します。が、相当のものがある事からも分かる通り、どちらも既に有名なもので、いまいち読んでも驚きがありません。しかもweak_ptrを扱っていませんし、参照カウントで問題になる「自分へのshared_ptrを基本的に持てない」という問題も扱っていません。

もしも読むなら、Effective C++を読んでちょっとC++を書いたらすぐに読むことをお勧めします！

JavaScriptでパフォーマンスを出すことを…強いられるんだ！！！（ｶｯ

で、今回はその関係で色々試したことの一つについて、昔やった結果を纏めたのを書きました。

TypedArray

最近のJavaScriptにはTypedArrayというのがあります。通常のJavaScriptの配列は、要素にどんな型でも入れられる上、厳密には配列ではなくハッシュであるため効率が悪いのですが、このTypedArrayでは配列の型を指定した本物の配列であるため、高速・効率的に処理できます。

もともとはJSでOpenGLを使うWebGLという技術向けに策定された仕様なのですが、別にWebGLでなくても使用できて、以前開発したJSのファミコンエミュレータでも、ファミコンのRAMやフレームバッファをこれで表現しています。

さて、このTypedArray、色々とメソッドが定義されていて、よく使う処理は大体網羅されているのですが、memset（メモリ全体を特定のデータで塗りつぶす）を行うようなメソッドがありません。結構使う処理だと思うのですが、無いのでなんとかJSで塗りつぶさないといけない、という事になります。

今回はTypedArrayのmemset処理について色々と試してみた結果を書きます。

条件

• Let’s note SX-1 SSD Edition CF-SX1GETDR
• Intel Core i5-2540M
• Windows 7 64bit
• Firefox 18 x86

方法１：普通にループで回す

var memory = new Uint8Array(1024*1024);
log("normal: "+cycloa.probe.measure(function(){
    var m = memory;
    for(var i=0;i<5000;++i){
        for(var j=0;j<1024*1024;++j){
            m[j] = i;
        }
    }
}));

一番遅そうですが、一番オーソドックスな方法です。5000回、１MBのデータを０で埋めてみると、５回試行してそれぞれ
5008ms, 4950ms, 4955ms, 4949ms, 4957ms
になりました。

ということで、5000ms前後がベースラインということになります。これから遅くなったらむしろ逆効果ということでです。

方法２：小さい配列をループで初期化してsetで回す

setというメソッドがあって、これを使うと複数の要素を一気に上書きすることができます。

var mem = new Uint8Array(1024*1024);
var another_mem = new Uint8Array(1024);
var offset  = 100;
mem.set(another_mem, offset);  -> 100バイト目から1,024バイトがanother_memの内容に上書きされる

さらにこのanother_memの作り方として、上のようにnewで作る方法とsubarrayを使って元の配列を部分的に共有したものを使う方法があります。

ver another_mem = mem.subarray(100,100＋1024); -> memの100から100+1024バイト目までを共有したメモリ配列を作

全部ネイティブで0にするより、一旦小さな配列を0で埋めてからsetでセットしたほうが速い気がしませんか。私はそう思いました。

全部JSのループで回すのは遅いというのがわかりましたし、かといってあんまり小さな配列を使って何度もsetを呼び出してもネイティブ呼び出しのオーバーヘッドが重いだろうと思われるので、このバランスをどうするかが問題になります。今回は、1KBから1MB（意味なし）まで変化させて測定しました。

new Uint8Arrayで配列を作ってコピーする方法

for(var z=10;z<=20;++z){
    log(""+cycloa.probe.measure(function(){
        var m = memory;
        var bsize = 1<<z;
        var copy_times = 1024*1024/bsize;
        var buff = new Uint8Array(bsize);
        for(var i=0;i<5000;++i){
            for(var j=0;j<bsize;++j){
                buff[j] = i;
            }
            for(var j=0;j<copy_times;++j){
                m.set(buff, j*bsize);
            }
        }
    })+",");
}

subarrayを使って小さな配列を作る方法

for(var z=10;z<=20;++z){
    log(""+cycloa.probe.measure(function(){
        var m = memory;
        var bsize = 1<<z;
        var copy_times = 1024*1024/bsize;
        var buff = m.subarray(0, bsize);
        for(var i=0;i<5000;++i){
            for(var j=0;j<bsize;++j){
                buff[j] = i;
            }
            for(var j=1;j<copy_times;++j){
                m.set(buff, j*bsize);
            }
        }
    })+",");
}

 グラフ

new Uint8Arrayで配列を作ってコピーする方法

subarrayを使って小さな配列を作る方法

やっぱり小さな配列を作ったほうが速い

と、いうわけで、8192くらいの配列を作ってsetで回したほうが大体17倍くらい速いです。subarrayの方が配列生成コストが変わってくるのかなぁ、と思ったのですが、あんまり変わらないようですね。

ただこの8192という数字は2013年のFirefox18のWindows7でCore i5(Ivy Bridge)というひっっっっっっじょうに限られた環境での値なので、あんまり鵜呑みにしないほうがいいと思います。もし、JSの実行速度がネイティブ関数呼び出しのコストに対して相対的に速い環境があればこの値は大きくなるかもしれませんし、ネイティブ関数呼び出しのコストがJS実行速度よりも相対的に安い環境があれば、この値は小さくなってくると予想されます。

結論

• HTML5のTypedArrayでは、メモリの内容を特定の値で塗りつぶすとき、subarrayでも新しくつくるのでも、他のTypedArrayを用意してそれを特定の値で塗りつぶしてからsetを繰り返す方がとても速い
• 8192bytesの配列を用意すると一番速かったけど、他の環境では分からない。
• ターゲットの環境で調べれば良いのでは（クロスプラットフォームを無視した言い方）

JSは大変ですね…。

C++のテストフレームワークのGoogleTest、活用してますか！！私は大好きです！！（何

テストフレームワークを使ってると、マクロを使って似たようなテストをまとめたくなる時があると思います。前後のセットアップだけ同じで型名とテストする値だけが違うとか。できればテンプレートを使ったほうがいいと思いますが、そうもできない場合もあるでしょう。

#define _MY_TEST(TYPE, VALUE, EXPECTED) \
{ /* plus */\
TYPE result;\
ASSERT_NO_THROW( result=do_sth<TYPE>(VALUE) );\
ASSERT_EQ( EXPECTED, result );\
}\
{ /* minus */\
TYPE result;\
ASSERT_NO_THROW( result=do_sth<TYPE>(-VALUE) ); /* マイナス */\
ASSERT_EQ( EXPECTED, result );\
}

TEST(MyTest, TEST_A)
{
_MY_TEST(int, 0x7fffffff, 0x80000000); // do_sthは何するんだろう…
_MY_TEST(unsigned short, 0x7fff, 0x8000);
...
}

でも、コレは動かないのです。こんなエラーメッセージが出ちゃいます。

****.cpp: In member function ‘virtual void MyTest_TEST_A_Test::TestBody()’:
****.cpp:719:1140: error: duplicate label ‘gtest_label_testnothrow_719’
****.cpp:720:1171: error: duplicate label ‘gtest_label_testnothrow_720’

さて…GOTOのラベルがかぶっているようです。なんでなのかは、ASSERT_NO_THROWの先を見ればわかります。

#define GTEST_TEST_NO_THROW_(statement, fail) \
 GTEST_AMBIGUOUS_ELSE_BLOCKER_ \
 if (::testing::internal::AlwaysTrue()) { \
 try { \
 GTEST_SUPPRESS_UNREACHABLE_CODE_WARNING_BELOW_(statement); \
 } \
 catch (...) { \
 goto GTEST_CONCAT_TOKEN_(gtest_label_testnothrow_, __LINE__); \
 } \
 } else \
 GTEST_CONCAT_TOKEN_(gtest_label_testnothrow_, __LINE__): \
 fail("Expected: " #statement " doesn't throw an exception.\n" \
 "  Actual: it throws.")

というわけで、GOTOのラベルに__LINE__マクロで取得した行数を使っているのですが、関数風マクロで展開するソースは一行で展開されるので、先ほどの_MY_TESTの複数のASSERT_NO_THROWで同じ__LINE__が使われてしまい、GOTOのラベルがかぶるのでさっきのようなエラーでコンパイルエラーになってしまったのでした。

むー。困りましたね。

マクロ内でマクロのディレクティブは使えない

たとえばこんな事はできません。

#define _MY_TEST(TYPE, VALUE, EXPECTED, x) \
 { /* plus */\
 TYPE result;\
\
#line (x*1000) /*lineディレクティブで書き換えてしまえばよいのでは！？ */\
 ASSERT_NO_THROW( result=do_sth<TYPE>(VALUE) );\
 ASSERT_EQ( EXPECTED, result );\
 }\
 { /* minus */\
 TYPE result;\
#line (x*1000)+1 /*上とは違う番号を使っている */\
 ASSERT_NO_THROW( result=do_sth<TYPE>(-VALUE) ); /* マイナス */\
 ASSERT_EQ( EXPECTED, result );\
 }

#lineというディレクティブを使うと__LINE__での行番号がこの行以降差し替わるので、これで変えてあげればかぶらなくなるのでは？と思ったのですが、やはり一行に展開されてしまうので、このように展開されてしまい…

{.... #line (x*1000)+1 ASSERT_NO_THROW(.... /*←改行なし*/

これでは文法エラーにしかなりません。

 仕方ないのでファイルを分ける

何かいい方法無いのかなーと考えていたのですが、プリプロセッサには関数風マクロ以外にもソースの繰り返しを行う方法がありました。includeです。

さっきのマクロの内容そのものの別ヘッダファイルを作り…

/* inc.h */
#define _MY_TEST(TYPE, VALUE, EXPECTED, x) 
 { /* plus */
 TYPE result;

 ASSERT_NO_THROW( result=do<TYPE>(VALUE) );
 ASSERT_EQ( EXPECTED, result );
 }
 { /* minus */
 TYPE result;
 ASSERT_NO_THROW( result=do<TYPE>(-VALUE) ); /* マイナス */
 ASSERT_EQ( EXPECTED, result );
 }

それをincludeして繰り返しすれば…

TEST(MyTest, TEST_A)
{
#define TYPE int
#define VALUE 0x7fffffff
#define EXPECTED 0x80000000
#include "inc.h"
#undef TYPE
#undef VALUE
#undef EXPECTED
}

別ファイル内でのgoto扱いになるので、さっきのエラーは出なくなります。若干不恰好ですが、手動で繰り返すよりは…。

できればテンプレートを使う方が良いと思う

マクロではなくテンプレートを使ってテストをパラメータ化すれば、このような問題は起きません。テンプレートではマクロの##（シンボル連結）とか#（シンボルの文字列化）みたいな機能は使えませんが、もっと安全だし楽なので、出来ればテンプレートで出来ないか先に考えるほうが良いと思います。。。

また時間操作か！

githubにリポジトリ公開したいお…でも

　 　 　　　＿＿＿_ 
　 　　　／　　 　 　＼ 
　　　／　 _ノ 　ヽ､_　 ＼ 
　 ／ oﾟ(（●）) (（●）)ﾟo ＼ 　ほんとはgithubで公開したいんだお…
　 |　　　　 （__人__）　　　　| 
　 ＼　　 　 ｀ ⌒´ 　 　 ／ 

　 　 　　　＿＿＿_ 
　 　　　／　　 　 　＼ 
　　　／　 _ノ 　ヽ､_　 ＼ 
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　でもMySQLのパスワードとか
　 |　　　　 （__人__）　　　　|　　 公開できない情報が入ってるんだお…
　 ＼　　 　 ｀ ⌒´ 　 　 ／ 

　 　 　　　＿＿＿_ 
　 　　　／⌒　　⌒＼ 
　　　／（ ●） 　（●）＼ 
　 ／::::::⌒（__人__）⌒::::: ＼ 　　だから過去を書き換えるお！
　 |　　　　　|r┬-|　　　　　| 
　 ＼ 　　 　 `ー'´ 　 　 ／

 と、いうわけで、書き換えです。

githubにソースコードを置きたい…でも公開できない情報が…。ありそうなのはこんなケース？

• MySQLのパスワードが書いてある…
• 完全に非公開で遊ぶために書いてたから著作権上アレゲなコンテンツが…
• 残念な感じのコミットログが…

今更その部分を隠してコミットしたって、昔のコミットログを辿られたら意味ないじゃない！んじゃあ、修正済みのやつだけコミットログ無しで公開？もっと意味ないじゃん！

そこで過去の書き換えです。gitはもうぶっちゃけ何でもできるので、過去のコミットを再度やりなおして全部書き換える事ができます。以上のケースについて、修正してみましょう。

 MySQLのパスワードが書いてある…

こんなサンプルリポジトリを考えてみましょう（github）。

ファイルの一部分に公開したくない情報があるケースです。たとえばパスワード。ためしにこんなファイルを考えてみましょう。

// 以下のコードはあくまでサンプルであり、何の意味もありません。

var db = /* なんか初期化処理 */ null;

db.init({password: test}); /* パスワードを追加しちゃった！ */
// データベースに何か値を突っ込む
db.save({id: 1, name: "ちさ"});
db.load(); // 何かロード処理的なもの
db.close();

db.initの行でパスワードをハードコーディングしてしまいました。公開するのには問題があるかもしれません。繰り返しますが、この状態からパスワードを隠してコミットしても過去のファイルはそのままなので、意味がありません。

さて、git logはこんな感じです。

commit e236c0d55d0d7fc4744dd5f7edc34b9c22d8cada
Author: psi <ledyba@users.sourceforge.jp>
Date:   Fri Feb 22 11:05:50 2013 +0900

    ロード処理的なものを追加した（という想定）

commit e27ea6a1cf49021b9686c7e757fbf9adf60afb3f
Author: psi <ledyba@users.sourceforge.jp>
Date:   Fri Feb 22 11:05:10 2013 +0900

    パスワードを追加しちゃったコミット。取り消したい。

commit 7c132ae20f6c1db1bff876e8d0626d41e07a8294
Author: psi <ledyba@users.sourceforge.jp>
Date:   Fri Feb 22 11:04:30 2013 +0900

    最初のコミットです。

この「パスワードを追加しちゃった」コミットで、ソースコードに直接パスワードを書いてしまっています。

git diff-tree e27e -p
e27ea6a1cf49021b9686c7e757fbf9adf60afb3f
diff --git a/sample.js b/sample.js
index 0a2fa57..9c892d8 100644
--- a/sample.js
+++ b/sample.js
@@ -2,7 +2,7 @@

 var db = /* なんか初期化処理 */ null;

-db.init();
+db.init({password: test}); /* パスワードを追加しちゃった！ */
 // データベースに何か値を突っ込む
 db.save({id: 1, name: "ちさ"});
 db.close();

password: testの部分をpassword: xxxxに変えて、隠しましょう。

そのために、まず新しいブランチを用意します。

git checkout -b rewritten

として新たなブランチをつくった上で、

git rebase -i <修正したいコミットの一個前のコミット>

を実行して書き換え開始です。rebase -iでインタラクティブモードを使うと、コミットを直接書き換えることができるようです。するとインタラクティブなので、こういう感じでエディタが現れます。　→notepad++でgit logを編集したいとき

これで、テキストの上のほうに

pick e27ea6a パスワードを追加しちゃったコミット。取り消したい。
pick e236c0d ロード処理的なものを追加した（という想定）

とあるので、改変した「pick e27ea6a」を「edit e27ea6a」に書き換えてエディタを終了します。すると…

git rebase -i 7c132
Stopped at e27ea6a... パスワードを追加しちゃったコミット。取り消したい。
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

と指示が出てくるので、書き換えましょう。書き換えたソースがこれ。

// 以下のコードはあくまでサンプルであり、何の意味もありません。

var db = /* なんか初期化処理 */ null;

db.init({password: xxxx}); /* パスワードは隠しておいた */
// データベースに何か値を突っ込む
db.save({id: 1, name: "ちさ"});
db.close();

ちゃんと隠しました。

指示されたとおり–amendでコミットします。その前にgit addを忘れないように

git add sample.js
git commit --amend
[detached HEAD 6a7b87a] パスワードを追加したコミットだったけど、取り消しておいた
 1 file changed, 1 insertion(+), 1 deletion(-)

これで書き換えられましたとさ。で、残りのコミットをgit rebase –continueで再度適用しなおします。

$ git rebase --continue
Successfully rebased and updated refs/heads/rewritten.

gitk –allってやって全コミットを可視化すると…

ちゃんと枝分かれしてます。masterを消してrewritteをmasterにrenameすれば、完全に書き換えたことになります。

ここで注意しないと行けないのが、「ロード処理的なもの～」というコミットが2つ存在することです。rebase -iして書き換えると、その時点以降のコミットはすべて別のコミット扱いになるので、注意が必要です。

最初のコミットはどうするの？

上では修正したいコミットの一個前のコミットを指定しましたが、じゃあその一個前のコミットがない、最初のコミットはどうすればいいの？その場合のサンプルも用意してみました→github:ledyba/__sample__RewriteGitHist2

この時は若干面倒くさいです。

まず、テンポラリなブランチを作って…

git checkout -b tmp

reset –hardで一番最初まで戻ります。

git reset --hard <一番最初のコミット>

この状態で、消したい部分を修正して、コミットを修正しちゃってください！

vi <修正したいファイル>
git add <修正したいファイル>
git commit --amend

こうすると、tmpブランチはmasterブランチとは一切つながりのない孤立したブランチとなります。よく見てみてください。線が繋がってません。

ではここからどうするかというと、この新しい孤島のtmpに、書き換え以前のmasterのコミットを適用しなおします。

そのためにmasterの最初のコミットに、oldrootというタグをつけて、rebase –ontoを使います。

git rebase --onto tmp oldroot master

すると（うまくマージが動けば）修正済みのmasterブランチが出来上がってくるはずです。

昔の書き換えたいコミットである、oldrootが今度は孤島になりました。

過去コミットのAuthor/Comitterを書き換えたい

以前適当に使っていたので、設定する名前とメールアドレスも適当でした。マシンごとに違った設定だったり、セットアップしなおすたびに適当に違うメールアドレス入れたり。

$git config --global user.name fuga
$git config --global user.email hoge@gmail.com

でもそうすると、誰がコミットしたのか訳がわからなくなってしまって、困ってしまいます。ので、公開するときにはこれを統一したい。そう思いました。

その方法ですが、stack overflowに書いてあるのでそのまま受け売りすると、filter-branchを使うと書き換えられるようです。

 git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

とやって、コミット時にいろいろ書き換えられます。このcommit filterのなかに書いてあるのはシェルスクリプトで、sedを使ってファイルを書き換えることもできますし、上記のように環境変数を指定することで、メタデータも書き換えられます。書き換えられるメタデータは以下：

• GIT_AUTHOR_NAME
• GIT_AUTHOR_EMAIL
• GIT_AUTHOR_DATE
• GIT_COMMITTER_NAME
• GIT_COMMITTER_EMAIL
• GIT_COMMITTER_DATE

特定のファイルを全部除去したい

今度は例えば、画像処理プログラムのサンプルで、著作権的によろしくない画像を使ってた…みたいなケースです。ありそう（過去を思い出しながら）

上記のfilter-branchではコマンドラインを使うと任意のシェル・コマンドが使えますので、

git filter-branch --commit-filter 'rm -f <消したいファイルとか>' HEAD

ってやれば、ファイルとか全部消せます。examplesにいろいろかいてあるので試してみてね

おわり

rebaseの話はあんまり見ないので、そちらを重点に、以前やったことがある書き換えについて書いてみました。gitのブランチを詰将棋みたいに書き換えるゲームもあったりするようで、gitのこの辺の機能は強力であると同時に少し難しいですね…。

悲しい話

情弱でもSnapでファイルアップロードしたい！

HaskellのWebフレームワークSnap、使ってますか！最近ちょっと触ってて、ファイルアップロードがしたいなぁと思ってこんなハンドラを書きました。Snapでは、URLに紐ついたハンドラ（結局モナド）を登録して、特定のURLにアクセスされると、そのハンドラが実行されます。

こんな感じ：

handleUpload :: Handler App App ()
handleUpload = method GET (redirect "/") <|> method POST handlePost
    where
        process part = continue (\a -> (yield (partFileName part) a))
        handlePost = do
            ret <- handleMultipart defaultUploadPolicy (\p -> process p)
            writeText $ T.pack $ show ret

ふーむ。この状態でこんなフォームを書いて送信してみます。

<form method='post' action='/upload'>
  <table id='info'>
    <tr>
      <td>file: </td><td><input type='file' name='image' size='20' /></td>
    </tr>
    <tr>
      <td></td>
      <td><input type='submit' value='send' /></td>
    </tr>
  </table>
</form>

よくみるとformでのenctype指定がないのですが、最初私は気づきませんでした。さてブラウザからアクセス。

アップロード。

うーん、acceptできるハンドラがない、ねぇ…。最初、ルーティングがうまくいってないのかな、と思ったのですが、GETで/uploadにアクセスするとちゃんとリダイレクトがかかるので、そこは間違ってないだろう、となると、このPOSTのハンドラが変みたいだ、と目星をつけました。

finally catch try ->どれも動かない

handleMultiPartを消してreturnにするとちゃんとレスポンスが表示されるので、どうやらここで例外？が発生してる模様。じゃあ`catch`だ！とやってみても…

handleUpload = method GET (redirect "/") <|> method POST handlePost
 where
 process part = continue (\a -> (yield (partFileName part) a))
 handlePost = do
 ret <- (handleMultipart defaultUploadPolicy (\p -> process p)) `catch` (\(e :: SomeException) -> [show e])
 writeText $ T.pack $ show ret

こうしても、さっきとまったく同じ、「No handler accepted.」。すべての例外をキャッチできるはずのSomeExceptionを使ってもだめ。例外がキャッチできてないからか、finallyを使っても何も起こりません。tryを使ってもEitherが帰ってこず、処理がスキップされちゃいます。

これ、C++で-fno-exceptionした時となんか似てます。例外処理が動いてないのでは？…もっとも、C++の場合はもっと不思議なことが起こったりですが…。

Multi-Partのチェックとその失敗処理は例外と直行している

中身を見るしかないので読みましょう。まぬあるにて、どうぞ。　HaskellのドキュメントシステムHackageでは、rdocみたいにソースが読めます。すばらしい。

長いのですが、今回エラー処理が起こされているのはここでした。

    -- not well-formed multipart? bomb out.
    when (ct /= "multipart/form-data") $ do
        debug $ "handleMultipart called with content-type=" ++ S.unpack ct
                  ++ ", passing"
        pass

passというので実際に処理を抜けているようですね。このpassのドキュメントはこれ。Exception関係のものがシグネチャにあらわれていないのを見ればわかるように、例外とは一切関係なく処理をスキップ致します。finallyを使っても何も起こせないのは、こういう事だったのですね。

debugを有効にしたほうがいいかもしれない

環境変数にDEBUG=1を指定するとデバッグモードが有効になります。

すると、こんな感じのエラーログがひたすら出力されます。

 [       8] handleMultipart called with content-type=application/x-www-form-urlencoded, passing
 [       8] Server.httpSession: finished running user handler
 [       8] Server.httpSession: handled, skipping request body
 [       8] httpSession/skipToEof: BEGIN
 [       8] httpSession/skipToEof: continue

これならコンテント・タイプがおかしいんだな～ってすぐ気づけますね…。開発中はずっとこれをつけといたほうがいいかもしれませんね！

ちなみにうまくいくと

Justでファイル名が帰ってくるだけの簡単なサンプルプログラムでした。ファイルは扱ってないです…。

ネタもと

ぼんやりと「Haskellのエラー処理とMonadCatchIOの落とし穴 – 純粋関数型雑記」を見てたら思い至った話です。

「例外、失敗」を処理する方法がたくさんあるのは柔軟で良いと思うのですが、ルールをちゃんとあわせておくか、あるいは別種の「失敗」があることをちゃんと把握しておかないと意図しない挙動になっちゃうのは、悲しいですね…。

こんにちは！

ここ一ヶ月で「時を司るスクリプト言語　ど～なっつ」やそれを使った出前授業について書いて来ましたが、実はそれらは全て国の機関IPAの未踏事業の支援を受けて行なってきたものだったのです！

で、ついにその支援期間も終わりまして、その成果を報告する成果報告会が明日、秋葉のUDXで行われます。もちろん支援を受けた私もその中で喋ります。

秋葉のUDX、しかも１７時半ですので、仕事や学校の帰りにすこし時間のある方はぜひいらして下さい！

みどころ？

ど～なっつで開発された教材を使って今月中旬に行われた、出前授業についてレポートします。特設サイト～。

時を司るスクリプト言語　ど～なっつについて、実際のデモを交えながら、「時を司る」さまをデモります！

毎回毎回どうやるんだっけ…とか検索してて不毛なので自分用にまとめました

私はboostをWindowsのMinGWでC++11のスレッド・アトミックサポートがうまく動かないのでその代替として使っています。環境の組み合わせは：

• Windows 7 x86_64
• mingw32 x86
• gcc 4.7.2 x86

ダウンロード

boostの公式サイトからソースのtarballをダウンロードしてどっかに保存してtar xvf。

boost::atomicの追加

採択されたらしいのになぜか入ってないboost::atomicを手動で入れる

公式サイトからダウンロードして中身を全部boostのフォルダにマージすればOKな模様。とりあえず使えたのでこれいいのかなと…。

bjamのブートストラップ

解凍したディレクトリに入って

cmd
bootstrap.bat gcc

するとb2.exeが出来て、これがboostのビルドシステム。bjam.exeっていうのもできてるけどこれはどうやら古い（？）ビルドシステムの模様。折角なのでb2を使いました。

b2の設定＆ビルド＆コンパイル

b2 --help

で設定が見れる。

b2 --show-libraries

でライブラリの一覧が見える。後で–without-****するときにこの名前が必要。

今回使った設定

これらを使って今回紡いだオプションがこちら

b2 --prefix=<install先> --build-type=complete \
--toolset=gcc --variant=debug,release \
--without-python --without-graph \
--without-graph_parallel --without-mpi \
link=static threading=multi runtime-link=static \
release debug stage -j4

これでちゃんと動くようなら上記の最後に install を追加したb2を走らせてインストール。

終わり

お疲れ様でした。