boostのような組み方は非効率
http://d.hatena.ne.jp/kmt-t/20060628#1151492391
より。
私もkmt-t氏の意見に同感。
例えばboostのcrc.hを例に取ると
私はboost/crc.hppをdkcCRC.cとしてC言語に移植したことがあるのだが、はっきり言ってとてもめんどくさかった。
さらにC言語に移植するとたくさんの分岐命令が出てきて普通にテーブルを使ったCRCのプログラムより遅くなってしまった。*1
templateが使えるC++ならではのテクニックがてんこもりでとてもC++を少し覚えたくらいでは太刀打ちできるような構造ではなかった。
このような組み方をする利点としては一つのインターフェイスで様々な場面に適応できると言う事だと思う。すなわちライブラリ的価値が上がるという事だ。
しかしながら、趣味でソフトウェアを作る場合このように突き詰めた実装をしなくてもCRC32あたりのアルゴリズム説明書かなにか見てさっさと組んでしまえばよいのではないかと感じる。
一つのインターフェイスで各bit長のCRC(1 - 64)の計算、および様々なCRCの実装が出来るように、さらにはその実装がお手本で実際にそのように組まなければならないだなんて考え方は私もかなり非生産的だと感じる。
こういうのはやはりライブラリを製作する余裕のある人や好きな人や専門家に任せるのが一番なのだと感じる。
技巧に走っても本当に便利なものがつくれるわけでもないし。
特に私はこれに共感した。
boost::spiritなんてのが典型。BNFで頭の中に状態遷移を作るのに慣れてない人にはただただ苦痛の構文。普通にパーサー用意してくれ＾＾；
でも、分かっている人にはやっぱり便利なんだろうなと思う。
いちいちBNFからコードジェネレーターを介してソースコードにするよりはC++の規則利用してちょこっと作るほうが効率的かもって思うのも分からなくも無い･･･
が、実際にライブラリの形のポリシーをもってあれほどしっかりしたライブラリを作るとなるとやっぱり私が思うにライブラリアン*2なのかなと感じてしまう所がある。
でも、やっぱりソフトウェアを作る事を目的としている人にはboostを使う人になってboostを作る人にはならない方が良いと主張したい!!!
その為にもやはりライブラリはバグ持ちではない信頼できるライブラリを使うべきなのだが、私の知る限りバグ持ちではないライブラリはgoogle:STLPortだけである。
