koie blog : boost

12:55〜13:00 : 会場の案内 (ももい)

会場貸します。ただしIIJ関係者がいることが条件。平日夜はけっこう空いてるらしい。のってきそうなネタなら会社帰りに参加できるのでだいじょうぶ。

oss-contact@iij.ad.jp

13:00〜13:20 : Boostライブラリ一周の旅 1.41.0〜1.44.0までの差分 (faith_and_brave)

property tree

xml,json.ini
RapidXmlをつかっている。
.attrはつかえない点に注意。

uuid

randomとstringから生成できる。

range

range algo: iterの組からrangeがつかえるようになった。(ちょっとべんりになっただけ)
range adapter: pipeっぽくつないでなんかできる。 m | map_keys でキーだけぬきだしたり。
遅延評価がされるのでベンチマークがとりにくいらしい。
Range2.0はおすすめ。Oven Rengeってしゃれたネーミングらしい。

filesystem

v3で日本語対応。string,wstringのかわりにpathをつかう。これからのながれか。

polygon

三角形の中の判定ができたり。

meta state machine (MSM)

state chartのかわり。
boost::mpl::vectorで一箇所に記述できる(あちこちにちらばらなくてよい)

13:30〜14:00 : Boost.Graph (egtra)

頂点vertexと辺edge
linked-list, tree
directed, undirected
adjacency_list<>

JR最長片道切符をBoost.Graphで総当たりした。
- 北海道の路線を打ち込んだとこでギブアップ...
- 四国が路線はすくないけど最長切符の区間にはいらないことが知られている...

なんでgraphをつかうか?
- イテレータがつかえるからとかrangeっぽいのがあるから。
- malloc/forのかわりにstlがつかえるから。

VC2010でテンプレート引数でミスると赤線がひかれて便利!らしい。

14:20〜14:50 : Boost.GIL (Leo)

Leoは本名。
ギル、ジル、ギーアイエル? 開発者はジーアイエルといっているらしい。
色空間重要。3種類だけサポート。
ラスタ画像のみサポート。(ベクタはなし)
画像の操作にはImave Viewをつかう。Imageはいじらない。
ピクセルへのアクセスは
- image_view::operator() 絶対座標
- iterator 順番にアクセス
- locator 相対位置
テンプレート引数が長くなりがちでめんどい。

動体検出 = フレーム間の差分(引き算)
演算するときは for(y) for(x)の順にやるのがふつう。

stlcv: STL like OpenCV wpraeerというのもある。

差分を表示するviewってのを作るとよさそうだが内部を知ってないと難しい。
viewで変換したのもはimageにcopyすれはいつでも保持できる。
ぼかしなどもできるけどファンクタを書く必要がある。
自分で画像サポートを書こうとすると自分で圧縮を解く必要がある。
画像フォーマット(jpeg?depth?)を調べるのはユーザがやる。てきとうに変換してくれはする。depthとか。
ジェネリックなコードなので色空間を切り替えるのはかんたん。
新しい色空間をサポートをするのはそれほどたいへんではない。HSV拡張は自分で書いてみた。参考にして。
rgb8_image_tはboostっぽくないけど、rgb8_image_tは展開すると画面いっぱいになるほどテンプレートパラメータがいっぱいある。なのでdepthをとりだしすことはできる。
複数のviewをかさねてもコスト0。回転なんかはポインタの操作だけなのでコスト0らしい。色空間の変換だけがコストがかかるらしい。
- 実はコスト0というのは手で書いたのと比較してという意味らしい。なので実行コストかかる。
const View にたいして view(x,y) = xxx とかできる。(constなのに!)
- constなのは設定に対して。
- rbg8c_image_tにするとconstなイメージになる。

15:00〜15:50 : SEXYHOOK (rti)

(略)

C++ともboostとも関係ないようなきがする...
http://ja.wikipedia/org/wiki/呼出規約

16:05〜16:40 : Boost.Flyweight (SubaruG)

const教
immutableはtemplateで実現できる。
shared_ptr
flyweightは等値のものを1つにまとめる。基本はshared_ptrと同じ。
const -> immutable -> shared_ptr -> flyweight ってながれ
非侵入的なので boost::flyweightとかできる。
パフォーマンス: 構築はややおそい。コピーや比較は高速。ハッシュ関数としてアドレスがつかえるのでunorderd_mapとかに。ただしハッシュfunctorは自分でつくる。文字列なんか便利かも。
デメリット:
- 非侵入的なので最適化に限界がある。
- flyweight側からその言語のGCがつかえない。
- シリアライズしたときにハッシュ値=アドレスがかわるのはいやかも。文字列にハッシュ値をうめこむのもあり。
trieをつかうと効率化できそう!
key-value flyweight
- flyweight>
- つくるときはflyweightでつかうときはflyweight → Valueの制作は遅延される
公式ページがよくできている。
Linux kernelだとmemory のdedupとかあるけど、小さなオブジェクトではflyweightは有効はなず。メモリ以外の資源も共有できるし。
複数の名前空間をサポートしていてタグをつかうとできる。
notrackだとresetできない。bome GCがあれば別だけど。

16:50〜17:35 : MessagePack for C++ (frsyuki)

mplex: C++のプログラムを生成するライブラリ。
json, protocol buffersよりもはやい。文字列のzero copyが効いている。
V-FIELD,Cagra, KAstor,kumofsなど何度もRPCを書いてきた..
streaming deserialization
future = client.call_async(...);
最適化
- コンテナ型: type length bodyをシリアライズ
- コンテナでない型: type valueのみ
messagepackの型システム(=json)があってハブになっていて、各言語と変換する。
json-RPCベース: 種類はrequest,response,notify(one-way)。msgidがいっている。
特徴
- async rpc
- paralllel pipelining
- thrifft IDL
- dynamic typing
- connection pooling
- delayedreturn
- event-drivend
event loopはmpioつかっている(C++),RubyではRev,JavaはXNIO。IO,timer,signalを1つのevent loopで対応できる。
message pack platform構想
- 分散DB, 分散ストレージ、分散キャッシュ、分散キューなどひとまとめにしたmessage pack platformを構想中
フォーマットはbig endianでUTF-8。
floatの配列はやっぱりほしい。25%サイズが増えてしまう。型がいっしょだったら型情報を省略とか。要望はあちこちからあるが、できるだけ単純なものにしたいため手をつけていない。
iteratorでアクセスできるようになるとboostっぽい。
RPCにrequired,optionalなフィールド指定ができない(現在実装中)
エラーはいまはerror,timeoutしかない。
optional<>対応はちょっと難しい。voidを返すようになっているため。
androidではC++は例外がつかえない! (コーディング規約の問題だけっぽい)
- http://www.textdrop.net/google-styleguide-ja/cppguide.xml