[過去ﾛｸﾞ] Boostを語れゴラァ part3 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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落としてビルドしてるんだけど、
オプションの与え方変わったの？
813(1): 2007/03/06(火)14:56 AAS
regex はとっとと xpressive に吸収されろと思うし、
bind は、lamdba.bind に吸収されろと思う。
lambda と phoenix はどっちベースでもいいから統合されて欲しい。
できれば、lamdba が母体となって、spirit は lamdba で実装。
asio と sandbox にある network は一本化してほしい。
814: 2007/03/06(火)15:30 AAS
boostは早めに整理・統合しろよ。
糞ライブラリがゴチャゴチャしててウザい。
815: 2007/03/06(火)15:33 AAS
>>813
tuple も fusion に(ry
816: 2007/03/07(水)08:23 AAS
外部ﾘﾝｸ:www.franz.com
swigとboost.python経由でlispとかとインターフェイス作るのは
どっちがいいんだろうか
817: 2007/03/08(木)08:57 AAS
1.34 ｸﾙｰ?
818(1): 2007/03/09(金)22:38 AAS
boost.graph使ってるやついる？
819(1): 2007/03/09(金)22:53 AAS
>>818
ﾉｼ
820: 2007/03/09(金)23:08 AAS
使い方わからんからパス
上下前次1-新書関写板覧索設栞歴
あと 181 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s