boost::graphの第一感

変態.
いや,真面目にやりますw.C++(の特に標準ライブラリ)で使われているgeneric programming用のテクニックの嵐ですね.ユーザ側から見ると特にtag dispatchが徹底して使われているな,と感じます.vertexやedgeを抽象的に扱うdescriptorの概念はまぁなるほど,って感じですね.これによってedgeやvertexのデータ構造の詳細に立ち入らずに済む,っつーのはまぁOK.graphもSTLiteratorのようにcategory分けされていてこれも(゜д゜)ウマー.さらにconcept checkを積極的に採用していて,各graph categoryにconcept checkerをつけているあたり気が利いているというか,利き過ぎているというか,paranoicというか・・・w.
で,一番目を引いたのがproperty mapの考え方.vertexやedgeに特有のデータをgraphのデータ構造内にhard cordingしたくないというのは,前々から私も思っていましたが,その解決策をどかーんと提示してくれた概念です.要するに各vertexからそのvertexに対応した値へのmap,あるいは各edgeからそのedgeに対応した値へのmapという概念を一般化しているだけですが,これによってgraph構造とgraph内の各vertexとedgeが持つべき値(property)を切り離して表現できます.それなら,普通の発想はstd::map使えば良いじゃない,なんですが,それだけでは変態たちが納得するはずがないw.propertyを持つデータ構造をvectorだろうがlist(#後で気づきましたが,listはrandom access iteratorを提供しないのでproperty mapに出来ないかも)だろうがmapだろうが何でも許してしまって,それにgenericにaccessできるようにしてしまう.これがproperty mapの発想(だと私は理解したのですが,どうでしょうか?).で,vertexが例えば2つのpropertyを持つなら,そのpropertyに名前をつけて区別しようと.この区別のやり方はtag dispatchのように見えるのですが,実際どうなんでしょうか?
後,もう一つ目を引く概念がvisitorの概念ですね.関数オブジェクトというかcall backの集合体ですかね?あらかじめgraphをtraverseする方法と,call backのタイミングが規定されているオブジェクトといったところなのかな?若干デザパタでいうところのvisitorとは異なる感じですかね.でも,public継承で挙動を再定義できるみたいですけれど,どうやるんだろう?CRTPで?まだ詳しく見ていないのでなんともいえないですね.
後,各vertexから出てるedgeの集合はiterator経由でaccessできて,しかも普通にinput iteratorのrefinement(要するにinput iteratorの要件を満たしている)なので,普通にstlのalgorithm群に突っ込めますね.っていうか突っ込みましたw.最初に突っ込んでみたのがstd::set_intersectionなのはご愛嬌w.もちろんedgeにpropertyを振って,そのpropertyでsortされていることを保証しておいた上で,functorも書いてから突っ込んだのでご安心くださいw.ただ,このときにfunctorにproperty mapを渡さないといけないのが不満といえば不満ですか.(多分property mapの正体はtagなので軽いのは確かだとはおもうのですが.っていうか後でsizeofしてみようっと)
#追記:property mapのsizeは予想通り1でした.ただのtagのようです.