2011年11月6日日曜日

boost 勉強会 in 札幌に参加してきた

 講師陣の皆様、ありがとうございました。まずは、お礼を申し上げます。
まず最初は、cpp_akira さんの boost::geometry の話。コンセプト・ベースの部分は、設計の思想を知らないと使えないので、非常に為になる話でした。余談ですが、仕事上、geometry 系は使ってはいます。ただ、データ構造の関係でインナーポリゴンを一筆書きで扱っている事もあって、どちらかというと、boost::polygon の方でないと現状と合わないので、導入には至っていません。他には、図形の演算はデリケートな面があり、特にユーザさんが入力するデータや既存のデータには、恐ろしい構成点の組み合わせ(例:ポリゴンが閉じてるけど1点オーバランしている、穴空きポリゴンを一筆書きで表現しているが回しがねじれていて時計回りでも反時計周りでもない)への対応をしている。などがあります。挙動が変わると、まずいので、なかなか、切り替えるのも大変だったりします。後で、函数型のparaisoが刺激的で面白かったよという話をしたのですが、一応リンクをはっときます。

 で、uskz さんによる圏論のお話...圧倒的に会場を置き去りにして(と思う)、熱くHaskellいいよとまとまりました。個人的には、c++にはstd::cout やglobal 変数を更新するという恐ろしい函数の副作用がありますという次に、World が出てきたところがウケてました。先の並列化という面で考えれば、concept ベースのデータ構造に依存しない設計アプローチは、SIMDのような並列化とは相性が悪いのかな?と漠然と考えてました。

 fadis_さんのContainerFacade、微妙に違いのあるコンテナに対して、なるべく少ない手数でアルゴリズムを実装できるようにしようという話でした。ベースにあるのは、stlではイテレータを介してコンテナにアクセスしているから、コンテナの要素を挿入/削除するような事ができない、そこで、なるべく多くのコンテナに対してコードの補完ができるようにしようというものです。聞いてて思ったのは、リンクドリストのような構造のものに2分探査のアルゴリズムを実装しても全くの無駄なので、このアプローチは便利なように見えて、実は良くないだろう...でした。この辺に対して考慮をし、合わないアルゴリズムは、コンセプトを満たしていないからエラーにするといった改良を加えれば、面白いのかなぁという感想です。すかさず、cpp_akiraさんが、ダメ出ししていたので、さすがだと感じました。

 DigitalGhost さんの Template MetaPrograming as 式 DigitalGhostさんワールドが展開されていたような...質問も無いですよね?で終了されてたのが、ウケてました。

 主催者のhotwatermorningさんのPStade.OvenとEggの実装を読む ソースの追い方がデジャヴな感じで、面白かったです。あっち読んで、こっち読んで、考えて、またあっち読んで...確かに、Eggを読むのはしんどそうです。

egtraさんの char32_tとBoost.Xpressiveと、char16_t, char32_t ができたので、それを使いましょうという話で、文字コード変換が iconv か ICU 以外に特にライブラリが無くてどうしよう?という切実な訴え...道化師さんの babel もあるけど...不便には違いないです。windows に限定すれば文字コード変換のようなアプローチもあります。wconv.hpp は最初に書いた時点からは、若干設計が変わっていて、特殊化によってUNICODEとコードベース間の変換コードがカスタマイズできるよう考慮が加わってます。xpressive の対応の話も興味深かったです。これも、余談ですが、Linux で FreeType2 を利用した時は、char16_t でないと使えなくて、-fshort-wchar オプションを使用しました。

 Kikairoya さんの 組み込みでこそC++を使う100の理由 C++偏執狂には、面白すぎて、爆笑しまくり。楽しかったです。組み込みの世界のわからないチップの話を質問されて、例外とRTTIをオフにすれば、ooバイトぐらいに収まるので大丈夫ですと即答されていたのには、スゲーと感心してました。懇親会では、別の方KさんからチップセットのコンパイラがC++に対応していない実情もあるのでやむを得ない場合もあるけど、c++のコンパイラに通すと、型チェックを行ってくれるので有効な手法に間違いないという情報も得ました。

 redbolzさんの Boost.MSMの使い方 白状すると、ユースケースの中で、ステートチャート図だけは、何を書いていいのかさっぱりわかんねぇ状態の私には、耳が痛い話でもあり、有用な話でもありました。UMLからBoost.MSM のひな形コードを生成するツールに興味のある方は、ちょっと飲み会で話をしましょうとの事でした。

 ライトニングでは、道化師さんの #include の話、#include だけで、あそこまで話を引っ張れるのが凄いです。何でも、後から5分だよと聞かされて、ボリュームを減らしたのだとか...(^^;
懇親会でも、いろんな方と話ができて楽しかったです。

 皆さん、ありがとうございました。

追記:ひとつ、思い出しました。boost base64 への変換の実装は、iterator を利用しています。そのため、最終のバイト境界が3バイト以外では、終端を正しく終える事が出来ていません。Fadis_さんの ContainerFacade のアプローチならば、これをうまく扱えるのではないか?と感じました。

0 件のコメント: