Boost.勉強会#3で適当なことをしゃべってきました
- 私の発表資料: http://www.slideshare.net/digitalghost/preprocesstime-lambda-expression
- ソース: http://patch-tag.com/r/digitalghost/pplambda/home , http://sites.google.com/site/ilikemanaka/code/pplambda.tar.bz2
あぁどうしよう。今回は大阪開催なので旅程がなくて書くことがないのであった。終わり。
などというだけではあんまりなので、まぁ千里中央の地形はやばいですね。前にも第一回GC勉強会のときに行きましたが、会場の建物に入るまでやっぱり迷いました。地上なのにぐぐる地図が役に立たないというすばらしい地形ですね。あと誰も御堂筋線が地下鉄だと信じてくれないのですが、一つ誤解があって、御堂筋線は新大阪以北だと江坂までで、そこから先は北大阪急行線であって地下鉄じゃないんです。よってみなさんはほとんど地下鉄には乗っていないわけです。西中島南方から先まで乗るべきです。
全発表はここから見れます。実況のまとめはいつもの【Twitter】ブー速zakブログで。私は気になった話の感想を書きます。私の発表の話の補足とかは後ほど別の記事として用意します。
エラーハンドリング
の話は、聞いててふと関数呼び出しの際に例外から戻り値に変換できたらなーとか思いましたが、これはもっとこの考えを推し進めて、エラーかもしれない戻り値(ぬるぽ・optional系)/例外/errno + get_last_error/errno + out引数その他様々なエラー処理は、送出する側/捕捉する側で別々の方法で扱えるべきなんですよ!errnoで通知したものをcatchで捕捉できたりしてもいいじゃないですか!
前に「エラーは捕捉する側が都合のいい手段で捕捉できるべきだ」とか書きましたが、常にエラーを捕捉する側が、送出する側のとったエラー通知の方法に合わせないといけないわけです。先に書きましたが、送出する側が例外なら捕捉はcatchでしかできないですし、ぬるぽなら if (!f()) ですし、errnoならget_last_errorなど。「なんでお前はthrowしてないんや」「おいぃoptional使えやボケが!」とかそういう戦争が日々繰り広げられていて、大量のエラーハンドリングラッパが世の中に量産されている。大変不毛です(不毛といってもすっぽすっぽ先生のことではないです)。
だからまぁ、送出側と捕捉側を分離できる仕組みがあればいいですねという話です。
Goodbye Doost!
Dなんとか言語のA先生はRange中二病?大丈夫なんでしょうか。あと懇親会会場の道すがらの話で、コミッタの中では日本人勢が一番マジキチなんじゃないかと思いました。大丈夫なんでしょうか。まぁ、俺のD言語がこんなにまともなわけがない。
Boost.Build
よーしパパビルドしちゃうぞーという気持ちですね。そんなに難しくなさそうでよかったです。
あとRypplと組み合わせて何かできないかな。まぁ私Ryppl全然調べてないですけど。
Boost.PropertyMap
前回のshared_ptrに引き続き、動機から話を積み上げていく大変に分かりやすいお話で非常に明解で分かりやすい(←これで使い方あってるかな)お話でした。まぁ私全然使う機会ないですけど。
二次会
懇親会は大変賑っていました。道化師さんやredboltzさんとkikairoyaさんは昔話に花を咲かせていました。ちょっと年齢層の違う話なので私はよく分からなかったです。
二次会ではalohakunさんが「みんなもっと残念な感じのキモオタだと思ってた。がっかりした。」「(アキラさんに)ほんとイケメンですよねー」「(めるぽんさんに)ほんと勝ち組ですよねー」「うちの会社は高齢化が激しいのに、社長に同年代だと思われている」などとずっと悲しくなるトークをしていました。そういえば一次会の席でもなつたんさんに説教していたという話を聞いてますね…。まぁそんななかでも私は期待通りの感じだったそうです。やったねたえちゃん!
そういえばHiNaさんって見あたらなk(ry