boost::adjacency_listをごちゃごちゃいじるよりも，問題にピッタリ適合するデータ構造を作っておいて，次にこれみたいにconceptの要求通りにtaritsのspecializationと関数のoverloadをしていった方が楽な気がしてきました．boost::adjacency_listって柔軟な拡張性があるように見えますが，実際に使ってみると色々不満が出てきたもので・・・．
最初にBGL見たときは，インターフェイスがすべて名前空間の関数として定義されていることについて「なんだかなー」というのが第一印象だったのですが，こうしてみると名前空間の関数なら単にoverloadするだけで特定のデータ構造をconceptに合わせられるので，これはこれで（゜д゜）ウマーなんだなと思えてきました．
後，GraphのコンセプトでGraph conceptとIncidenceGraph conceptの間にDirectionalGraph conceptってな感じのコンセプト（IncidenceGraph conceptからsource(e, g)のvalid expressionだけが抜けているようなコンセプト）がないことが疑問でした．IncidenceGraph conceptの場合，edge descriptorからsourceが分かるということはedge descriptorにsource vertexの情報があるわけで，余計なoverheadがあるから嫌だにゃ〜ってことでedge descriptorにsourceの情報がないコンセプトとしてDirectionalGraph conceptってのがあっても良いじゃないか，と思っていたのです．ところが実装を実際に見ていたら，edgeをあらわす内部データ（各vertexが持っている隣接リストのvalue_type）にはtarget vertexの情報しかなかったのですね．で，これでどうやってedge descriptorからsource vertexの情報を得ているのか非常に不思議だったのですが，実はout_edge_iteratorが特殊なiteratorで，確かにvertexの隣接リストを渡るiteratorではあるんですが，dereferenceするときにsource vertexの情報を付加したオブジェクトに変換して返しているんですね．要するにout_edges(v, g)が内部の隣接リストのiteratorに対するiterator adaptorを返している感じです．これは見ていてなかなか（゜д゜）ウマーだな〜と思いますた．ただ，source vertexの情報が一切必要でない場合，最適化されなければ（そして多分，多くのコンパイラではされないと予想していますが）付加したsource vertexの情報が無駄になるという欠点はやはり存在しますが・・・．
BGLについては他にも，いろいろいじっていて雑感として書きたいことが多く出てきているので，それについてはまた今度（例えばproperty mapの面白さとか）．
それだけ．
