[過去ﾛｸﾞ] Boostを語れゴラァ part3 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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だったりする俺ｗ
807(1): 2007/03/05(月)13:26 AAS
標準に入ったらファイル名やネームスペースはどうなるのかね。
全部標準のincludeに入って.hppはずしてstd::になったらさぞや壮観だろうw
808(1): 2007/03/05(月)16:17 AAS
>>773
>>771
ublas.matrix
multi_array
を組合せてテンソル処理ができないかと思ったら
全然互換性がなくて死んだ
809: 2007/03/05(月)16:20 AAS
ある程度抽象化された処理が必要ならc++を拡張するんじゃなくて
lispあたりからcを呼ぶようにしたほうがよかったと思う
今日このごろ
810: 2007/03/05(月)16:39 AAS
>>807
shard_ptrやfunctionなどはtr1に入っているが正にそんな感じ
811: 2007/03/05(月)18:33 AAS
>>808
標準ライブラリでさえstd::valarrayはひでえもんだぞ
それに比べればマシ
812: 2007/03/06(火)04:48 AAS
bjam -sTOOLS=vc-8_0 ...
ってやってるのに、
warning: Configuring default toolset "gcc".
って出るのは何故？
cvsで最新のboost落としてビルドしてるんだけど、
オプションの与え方変わったの？
上下前次1-新書関写板覧索設栞歴
あと 189 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s