[過去ﾛｸﾞ] Boostを語れゴラァ part3 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
777: 2007/03/04(日)12:28 AAS
まあ、spiritが標準ライブラリに入るなんて考えにくい。
778: 2007/03/04(日)12:32 AAS
Rubyは例に出しただけだ。
何故か突然Pythonに対応して、かつPythonにしか対応していないところに
統一性や一貫性がないと言っている。
779: 2007/03/04(日)12:38 AAS
いつからBoostは、そんな何もかも面倒見るライブラリになったんだか。
そういう目的なら、もっとふさわしいものがあると思うけど。
取捨選択して使えばいいじゃない。
780: 2007/03/04(日)12:46 AAS
利用者が取捨選択するためにも、
コアな機能とその他の雑多な機能を明確にわかりやすく分類してほしいものだね。
いまのBoostは統一感のないごった煮だ。
781(1): 2007/03/04(日)12:50 AAS
Boost.PythonのゴールはBoost.LangBindingだよ。
782: 2007/03/04(日)12:53 AAS
コアな機能も何も、どれも単品での使用を意図しているものばかりに見えるけど・・
貴方の言葉を借りれば、「単なるライブラリの寄せ集め」ですし。
783: 2007/03/04(日)12:54 AAS
>>781
＞Boost.PythonのゴールはBoost.LangBindingだよ。
それは後付けな印象が強いんですがどうなんですかね？
Boost.LangBinding の prototype 的な役割を
Boost.Python が担っている，というほうが適切な気が
784: 2007/03/04(日)13:12 AAS
そもそもboost自体が巨大なsandboxみたいなもんだろ
785: 2007/03/04(日)19:05 AAS
元々が「こんなの標準に欲しいよね」だし
786: 2007/03/04(日)19:16 AAS
グラフィックスもオーディオもウィンドウシステムも端末制御も
ネットワークも暗号化も数値計算もDBアクセスもXML/HTML等のパーシングも
扱っていない（今後グラフィックスやネットワーク機能は追加されるようだが）
現実の応用において欲しくなるような機能が恐ろしく乏しいというのに、
既にヘッダの数が1000のオーダーというのはいっそ笑えるな
787: 2007/03/04(日)19:19 AAS
だが、そこがいい
788(1): 2007/03/04(日)19:26 AAS
boost は一般のライブラリより枯れていそうな点(関係者が高度なC++使い)と
ライセンスを煩く考えずに済む点が良いと思うけどなぁ。
789(1): 2007/03/04(日)19:27 AAS
>>788
boost::regexのバグは直ったのかな？
790(1): 2007/03/04(日)19:37 AAS
>>789
的外れなツッコミ乙
791: 2007/03/04(日)21:04 AAS
boostは言語の補完/拡張的意味合いが強いからなぁ。言語として実装すべきだろと突っ込みたくなるものも幾つもあるけど。
792: 2007/03/04(日)21:12 AAS
ラムダの事かー
793(1): 2007/03/04(日)22:47 AAS
boostはウインドウシステムやミドルウェアから独立しているからこそ価値があるわけ。
WindowsならATLを使い、UNIXならgtkを使うという使い分けができるわけで、
依存関係とかcygwinによるエミュレーションとかの厄介事を避けることができるわけ。
794(1): 2007/03/04(日)22:59 AAS
>>793
その理屈は意味不明だな。
別にBoostはお仕着せフレームワークじゃないんだから、
GUIの機能を持ってても、欲しくないのなら使わなければいいだけだろ。
現状でもBoost::threadやBoost::filesystemなんて、あんたが言うような
そのものズバリのエミュレーション層だし
Boost::pythonなんて意味不明だし
795: 2007/03/04(日)23:16 AAS
boost に統一性や一貫性が無いのは知れたことだけど、具体的に何か困ることあるか？
なんでケチつけてるのか意味が分からない。
796: 2007/03/05(月)00:19 AAS
boostが単なるライブラリ群であり続けるなら、単にヘンテコなライブラリの寄せ集めでもいいが、
C++の標準になるのであれば、論理的に必要十分なライブラリ集に仕上げてもらいたいものだ。
797: 2007/03/05(月)00:28 AAS
標準に移行する際にブラッシュアップされるだろ
そのまんま標準になるわけなかろう
798(1): 2007/03/05(月)01:16 AAS
>>794
MFCみたいにGUIと密着してると、
サービスを作る時に、どのクラスがメッセージポンプに関連するかとか
いちいち気にしないといけないだろ。
799: 2007/03/05(月)01:19 AAS
ブラッシュアップの過程で現在のboostとの互換性はなくなるわけだ。
800: 2007/03/05(月)01:31 AAS
>>798
それはMFCのツクリがタコであるというだけ。
大体、どのクラスがWindow System絡みかなんて、namespaceや
ディレクトリ階層みりゃすぐ分かるだろ。
801(1): 2007/03/05(月)01:49 AAS
>>790
何が的外れなの？
正規表現のバックリファレレンスなんてありふれたものに
バグを作りこむなんて随分枯れてるライブラリだなと感心したものだけれど。
802: 2007/03/05(月)02:04 AAS
長年の豊富で幅広い利用が無ければプログラムなんて枯れないよ
Boostはまだまだ「枯れる」段階じゃないっしょ
803: 2007/03/05(月)02:19 AAS
パターン中のバックリファレンスはハッキリ言って蛇足。
多機能で延々とサポートが続くライブラリよりも
シンプルですぐ枯れて安定するのが欲しい。
804: 2007/03/05(月)05:22 AAS
>>801
それならVCでもGCCでもSTLでもバグが皆無なのかと聞きたいもんだが。
バグが存在しないソフトウェアなど存在しない。\
君のレスは重箱の隅をつつくようなもんだ。
805: 2007/03/05(月)10:17 AAS
Boost.Python って Formal Review の枠組みが整う前に入ってなかったっけ？
今だと特定の用途向け杉とかであっさり reject されそう
806: 2007/03/05(月)13:03 AAS
最近Boostで一番良く使うのがboost.pythonだったりする俺ｗ
上下前次1-新書関写板覧索設栞歴
あと 195 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.009s