[過去ﾛｸﾞ] BOOSTを語れゴラァ (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
899: 2006/01/22(日)13:55 AAS
>>898
「馬鹿なコンパイラだと」
900(1): 2006/01/22(日)14:19 AAS
VCだといいけど、Borlandだと警告出るよね。
Borlandは出来ないということでしょうがないけど、VCの場合は
どういう展開をしているのかが気になるところ。
901: 2006/01/22(日)15:13 AAS
>>900
CaseByCase。つーか、スレ違い。
902: ・∀・）っ-●○◎- ◆Pu/ODYSSEY 2006/01/22(日)16:48 AAS
ループがなくても数十ステップにわたる関数なら/i 付けてもインライン展開しないケースも多々あるよ。
__forceinlineなら緩くなるけど確実じゃない。
903: 2006/01/22(日)18:22 AAS
当たり前のことをわざわざコテでレスかよ。
904: 2006/01/23(月)00:08 AAS
別に展開しようがしまいがかまわないが、標準ライブラリで警告抑止オプションをつけないと
警告だらけというのはやめてくれってかんじ
905: ・∀・）っ-●○◎- ◆Pu/ODYSSEY 2006/01/23(月)00:34 AAS
#pragmaで抑制できないの？某はあんま使ったこと無いけど。
906: 2006/01/23(月)12:52 AAS
別にレスしようがしまいがかまわないが、専用ブラウザであぼーん設定をつけないと
うざいコテだらけというのはやめてくれってかんじ
907(1): 2006/01/23(月)17:12 AAS
regexは名前付きキャプチャ使えないのか...
908: 2006/01/24(火)12:14 AAS
>>907
細かいところで不便を感じたりしたから、
結局イテレータベースで名前付きキャプチャとマルチバイト対応、
ヘッダファイルのみで完結する basic_regex 作ったこともあった。
検索結果はすべてまとめて関数オブジェクトに渡すつくりだったから
再帰検索や、構文解析するのにけっこう便利だったよ。
909: ◆Pu/ODYSSEY [＞∀＜）っ-●○◎-] 2006/01/24(火)12:29 AAS
鬼車をラップしたほうが速くね？
boost::onigurumaとか出たら鼻血でそう。
910(2): ◆Pu/ODYSSEY [＞∀＜）っ-●○◎-] 2006/01/24(火)12:33 AAS
でもregex++は双方向イテレータ定義されてるものにはなんにでも使えるのか。
これはこれで便利なの？
リスト構造になってる文字列とかお目にかかったことがないんだが。
911: 2006/01/24(火)12:51 AAS
vc-8_0-stlportってないみたいだけど
VS2005は付属のSTL使えってことでいいんですか？
912: 2006/01/24(火)13:19 AAS
>>910
charTはコンセプトが合っていれば「文字」じゃなくていい。
913(1): 2006/01/24(火)13:28 AAS
トークン列のマッチに使えるのは便利だな
914: 2006/01/24(火)13:33 AAS
>>913 文字に相当するものがトークンってこと？
915(1): 2006/01/24(火)14:06 AAS
>>910
双方向イタレータ＝リスト構造ってアホですか?
ゴミレスは不要。
916: 2006/01/24(火)14:18 AAS
UTF-8 は、双方向イテレータ
Shift_JIS は 前方向イテレータ
917: 2006/01/24(火)16:05 AAS
I need Boost NOW!!
I need Boost NOW!!
I need Boost NOW!!
*ghost Fuckin BackFacker!!!
918: 2006/01/24(火)16:14 AAS
BrainFacker!!!
919: ＞∀＜）っ-●○◎- ◆Pu/ODYSSEY 2006/01/24(火)21:31 AAS
>>915
regex++にはリスト構造「にも」使える。onigurumaやその他正規表現ライブラリは1次元配列前提。
もしリスト構造かなんかで使えないと何か不便なケースでもあるかなと思って言ったんですが、
それすら通じませんでしたかｗｗｗ
そりゃ失敬ｗｗｗｗｗｗうはｗｗｗｗテラワロスｗｗｗｗｗ
920: 2006/01/24(火)21:43 AAS
必死ですね
921: ＞∀＜）っ-●○◎- ◆Pu/ODYSSEY 2006/01/24(火)22:47 AAS
ついでだけどさ、
Regex++ってsyntax差し替え（SQLやGROBのワイルドカード文字列からオートマトン生成）
って簡単にできたっけ？
鬼車にはサンプルがあったんで解りやすかったが。
まぁ別にワイド文字かASCIIかなら悪くない選択肢だと思うけど、
コード変換って正規表現マッチングそのものなみに遅いじゃん。しかも一部の漢字は死ぬし。
できあいのライブラリでダイレクトに判定したいってことになると、Regex++は日本語環境には
不親切といわざるを得ないかと。
1.33でようやく大文字小文字区別あり／なしの動的切り替えサポートしたと思ったらますます重くなりやがるし。
ASCIIでも単純な構文なら鬼車のほうが数倍高速だったり。
（固定文字列部分を抽出して先にBM法で絞り込むから速いそうな）
922: 2006/01/25(水)11:23 AAS
鬼車も実はマッチは正確でなかったり('A`)
機能拡張だの豊富なオプションだのはいいんだが
そんなことより照合をばっちりとやってほしいところ。
最低限の機能と正確なマッチングをキボンヌ。
923(2): 2006/01/25(水)18:48 AAS
Xpressive が正式に Boost に採用されたから、
中途半端な Boost.Regex は最早不要になるだろうと予想。
924: 2006/01/25(水)18:53 AAS
xpressiveのストリームIOを使ったパターン記法に慣れるのにちょいと時間がかかりそうだ
925(1): 2006/01/25(水)19:23 AAS
>>923
今のところデフォルトインストールではXpressiveはインストールされないんだよね？
926: 2006/01/25(水)19:37 AAS
デフォルトでインストールされないというよりか
リリースブランチにまだ入っていなかったかと．
入るのは 1.34.0 以降でしょうね．
待ちきれないのなら CVS の HEAD 落とせば入ってます．
927: 2006/01/25(水)20:27 AAS
>>923 不要になるってのは、 Boost から外される？
ってことはないよね、基本的に一旦受理されたものは
ずっとメンテナンスされるってスタンスだし。
それにしても正規表現関係では、日本語、というか
非西洋の文字群の扱いに常に不安がつきまとうね。
外部ﾘﾝｸ:article.gmane.org
928(1): 2006/01/25(水)20:38 AAS
boost.filesystemとか日本語ファイル名をきちんと読んでくれないしなあ。
上下前次1-新書関写板覧索設栞歴
あと 73 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.014s