【C++】STL（Standard Template Library）相談室 8

1 名前：858 [2007/12/24(月) 03:41:59 ] C++標準ライブラリの一つ、STLについて。 前スレ 【C++】STL（Standard Template Library）相談室 7 pc11.2ch.net/test/read.cgi/tech/1185986999/ 過去ログ・リンク・書籍紹介は >>2 以降 402 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:47:46 ] 何も考えずに動いていたCStringがなつかすぃ。。 そういえばなんでがんばってfind禁止のダウングレードのstd::string使ってるん だったっけ？ だれかどこでも動くCString作ってぇぇ 403 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:49:03 ] >>393 >>394 >>396 ありがと。 やっぱＣ＋＋はスゲーや。 Ｃのシンプルな文法に慣れきったオレには奥が深いぜ。 404 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:49:05 ] ドザは Windows のことしか考えないから困る。 405 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:52:20 ] どこでも動く？ どこでもSJIS使うの？ 406 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:52:31 ] Linuxとかｶｽいらねーし 407 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:54:02 ] Mac では SJIS 使わん事も無い。 UTF-8 や EUC も使うが。 408 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:57:06 ] ASCII自体が腐ってるからな。誰だよ、あんなコードにしたのは。 409 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:58:30 ] >>405 いや、できればマクロとかでプラットフォームごととか文字コードとか 切り替えられてさ、当たり前だけどfindとかも問題なく動いちゃうやつ。 CStringみたいに楽に使えて、でもUTF-8とか16とかも平気な感じ。 std::ustringみたいに統一しちゃってさ。boostとかかな。 410 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 18:59:32 ] findだけの問題ならすぐ解決するけどな。 ただ、SJISのままだと単純サーチにするしかないので効率は悪い。 411 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:01:36 ] >>410 そりゃWinの場合は内部的には_mbsstr呼ぶとかして高速化しる 412 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:01:45 ] wstringに自動変換する const char *n_str();と wstring(char*)を付ければ解決するような気になるけど？ 413 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:01:47 ] >>406 普通sunだよな 414 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:05:17 ] Windows なら mbs 系でおkだが、 他の環境だとその手の関数あるんだろうか。 415 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:22:06 ] ついでに質問なのですが、TCHARみたいにstringとwstringを切り分けるにはどう すればよいのでしょうか？以下のようにしておく必要があるのでしょうか？ 他にもっといい方法があるのでしょうか？ #ifdef UNICODE 　#define tstring string else 　#define tstring wstring まだ98でもXPでも動かしたいので・・ 416 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:23:31 ] 組み込み型にしてもいい位のデータ構造なのに クロスに作るのが難しいこんな世の中じゃ 417 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:25:51 ] >>415 とりあえず #define よりは typedef のほうがいいだろうな。 418 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:30:39 ] >>415 なにかわからないがよくないことが起こりそうな悪寒 419 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:41:43 ] charとwchar_tも切り替えないと。リテラル使ってるところがあったらそれもマクロで囲まないとね。 …めんどくさいでしょ。 420 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:45:37 ] つまり、C++0xのユーザ定義リテラルの登場を待てと 421 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 19:51:06 ] >>419 それは TCHAR と _T として既に用意されているだろう。 422 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 23:53:01 ] >>415 typedef std::basic_string<TCHAR> tstring; >>362 361のようなことを現実にやれるソフトウェアでは、 多言語対応のため、文字列リテラルの大半はソースコードに含まれないとか、 APIはラッパー層があるから変換も余裕とかそういう次元にいると思う。 423 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 00:52:04 ] 実際文字列リテラルをまったく含まないのはたいへんだぞ〜。 メッセージ的なものはともかくfind(":")的なパース類もすべてfind(COLON)とか にして事前にUTF-8で用意しておかなくちゃいけなくなるし、全WinAPIをラップする のはいよいよ無理だろうに。カレントディレクトリ一つ取るのも GetCurDir(string& s){ 　TCHAR t[PATH_MAX]; 　::GetCurrentDirectory(PATH_MAX, t); 　#ifdef UNICODE 　Utf-16からUTF-8に変換 　#else 　SJISからUTF-8に変換 } 的にすべてのラップ関数を用意してあげなきゃいけなくなるし。。 424 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 00:57:46 ] > find(":") 他に理由がなければ、ASCII分はそのままソースに書いていいと思った。 425 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 00:59:56 ] そんなわけがないだろ。 426 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 01:02:52 ] A 系使えば大丈夫。 427 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 01:34:22 ] せっかくWinがUTF-16なのに内部エンコーディングをUTF-8にして、API呼ぶたびに UTF-8からUTF-16に変換はちょっとやだなあ。 全てのAPIをラップする開発コストに加えて、実行時の変換コストまでかかるし。。 やっぱWinはUTF-16でいきたいね。 428 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 01:37:11 ] いい加減スレチガイだということに(ry 429 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 09:45:10 ] std::string/wstringは最重要のコンテナだしスレ違いとは思わんが・・ 結局文字コード周りはいまいちなのがわかるだけなんだよなあ。。 430 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 14:04:09 ] 話の流れぶった切って申し訳ないが言わせてくれ。 なんか良スレの悪寒。 431 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 15:13:29 ] 日本語と中国語の区別ができない腐れた文字コードそれがUnicode 中国が大体元凶だけどな 432 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 15:26:40 ] > 内部エンコーディングをUTF-8にして、 > API呼ぶたびにUTF-8からUTF-16に変換 Dのことかー！ 433 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 16:15:55 ] >>431 4.0からは区別できますよ 434 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 16:34:19 ] >>431 言語の区別ができない文字コードはUnicodeに限らないんだよ 435 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 17:12:12 ] ユニコードは本格的多国語環境や16ビット固定長を宣伝文句にしていたからねえ。 次々と撤回して期待外れだったよな。 436 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 17:37:19 ] だから、多国語ではなく多文字だったと。 437 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 17:44:51 ] 見苦しい 438 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 18:07:33 ] ユニコードって、UNIXの文字コードだったから ユニコードって言うんだよね。 439 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 18:27:51 ] おまいらいい加減スレ違いだぞコノヤロー。 440 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:13:14 ] >>438-439 しらんかった 441 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:15:54 ] ユニコード表みるとハングルが異様なほど文字数が多い 中国だけじゃないぞ 442 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:24:34 ] >>441 ハングルは現在全く使用されない組み合わせも全部作るように 韓国が強く要求したんだと それでbatangが異常に膨れている。 韓国死ねよ。 443 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:30:25 ] >>442 にほんだって「あ゛」とかいれてるじゃん。 444 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:35:52 ] unicode.org/charts/normalization/chart_Hiragana.html ここをみるかぎり、「あ゛」は単一のコードとして存在しないようだが 445 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:57:49 ] ごめん、勘違いだったかも。でも日本人だって「あ゛」いれたいしぃ。 可変長で6バイトでもよくなったんだから、なんでもいれていいと思う。 446 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 19:59:46 ] >>443 やあチョーセンジン 447 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 20:06:35 ] >>442 欧米人にしたらCJK死ねよなわけだが。 なんでなかよくできんもんかね。 448 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 20:10:36 ] 仲の良い隣国つーのは歴史上稀なわけだが。 稀つーかあるのか。 449 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 20:13:08 ] 日本だって古代は中国と仲良かったじゃん。 あと、中国と韓国。 どちらも、主従関係だけどｗ 450 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 20:42:13 ] 「仲良かった古代」、って遣唐使廃止まででそ。1000年も前の話だし。 451 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 21:41:37 ] 当時は海ってのは命がけで渡るもの凄い大きな壁だったわけで、 隣国っつーよりは、日本とアメリカ・・・は言い過ぎかもしれんが、 そんな感じだったと思うぜ。 452 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 21:47:52 ] 　　　♪　♪　　　＼＼　♪　　僕ら〜はみんな〜　生〜きている〜　　♪.／／　♪　　♪ 　　♪　　　　　　　　＼＼　♪　　生き〜ているけど　チョンは氏ね〜　♪／／　♪ 　 　　　　　♪　　　 ∧ ∧　 　 　∧ ∧　　　∧ ∧　　 　 ∧ ∧　 　　∧ ∧　　 　 ∧∧　　♪ 　 　♪　　　　∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)　♪ 　 　　　　　　(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧ 　 　　　　♪ ∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)∧ ∧(ﾟ0 ﾟ*)♪ 　 ─♪──(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U(ﾟ0 ﾟ*)｜　U 　 　　　 　 　 | 　U.｜　 | | 　U　| 　｜| 　Ｕ. | 　｜| 　Ｕ. | 　｜| 　Ｕ. | 　 |｜　Ｕ. | 　 |〜♪ 　 　　♪　 　 |　　|　U U. | 　｜ U U　| 　 |　U U　| 　 |　U U　|　　|　Ｕ Ｕ |　　|　U U　♪ 　 　　　　　　 U Ｕ　 　 　 U U 　 　 　 U U　 　 　 U U 　 　 　 U U　　　　 U U 453 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 22:06:43 ] www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html こんなのがあったのね。知らんかった 確かにゲームや組み込みではSTLそのまま使うのはキツイわな 454 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 22:11:55 ] >>447 電脳創世記っていう本にあったんだが、そもそも「CJKその他ヨーロッパの小国死ねよ」 ってやってる連中はアルファベットしかないコードしか使ってなくて、それを日本人が 「文字コード問題は俺たちが解決して業績上げますからメリケン共は口出ししなくても良いよ＾＾」 って挑発して今の流れになったんだと思う。 455 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 02:36:05 ] >>453 ゲームがメモリをキツキツに使うからって、数バイト〜数十〜数百バイト単位の 標準ライブラリのメモリ確保までキツキツにしても、あんまり関係ないと思うんだ。 どうせ画像やサウンドデータが１個増えればだけでそこらへんの努力は 吹っ飛ぶもんじゃないの？処理負荷にしてもさ。 456 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 02:42:20 ] >>442 漢字使用国がそれだけは言っちゃいかんだろ 「じゃお前ら文字数が多すぎるから統合ね」と言われても何も言い返せない むしろ韓国みたいにもっと初期の段階で分離しろと言い張れば分離できたかも しれないのに日本人おとなしすぎ 457 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 02:55:03 ] 文字、文字コード関係はこっちいけよ 458 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 02:55:33 ] pc11.2ch.net/test/read.cgi/tech/1180250376/ 459 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 02:58:15 ] 英語・日本語・中国語間のソフトやマニュアルの翻訳をやってるけど ほぼ同じ意味の文章なら中国語が一番少ないデータサイズで書ける 460 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 03:06:02 ] そんなの中国語知らん俺でも分かるっちゅーの 461 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 03:47:21 ] utf-8で？ アニメの中国語のfansubとか見るとかなが入った日本語と 漢字ばっかりの中国語で文字数そんなに変わらんように見えたけど。 だから画数で言えば中国語は不利。 462 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 04:43:57 ] 一文字に線をたくさん詰め込むんだから、字数が少なくならないとおかしい。 ような気もする。 463 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 06:14:49 ] >>455 ゲーム機はメインメモリ領域が結構キツイんでないの 464 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 06:33:10 ] >>440 嘘過ぎる 465 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 06:40:30 ] さすがに>>440は釣りじゃないのか 466 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 06:41:36 ] >>462 ちょうどいいのがなかったけど、これとか jp.youtube.com/watch?v=BdXniHjh2WM 467 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 07:28:09 ] 詩とか台詞の翻訳はちょっと特殊じゃないか？ ってどこへ行こうとしてるんだこのスレは 468 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 15:13:48 ] 標準STLではunicodeをちゃんと扱えるんでしょうか？ 処理系依存では（例えばVC++とか）扱えそうですけど。 469 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 16:35:57 ] ちゃんと扱う、の定義次第。 wstring, wchar_t を問題なく扱えればOKなのか？それなら問題ないよ。 ロカール処理やエンコーディング変換のための十分なサポートがあるか？それなりしかない。 470 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 21:06:41 ] >>455 コンテナ(というかアロケータ)のメモリ効率は重要だと思うが。 アラインメントやページ境界にかなり気をつかっているらしい。 演算効率についてはちょっと読みきれていないが... inline展開とか命令キャッシュ効率とか、分岐予測の弱いプロセッサのこととか、 いろいろ書いてある。 でかいボトルネックは取り除いた上でさらにどうがんばるかって話では。 >>463 "Game platform memory metrics"ってところに主要なゲーム機のspecが書いてある。 471 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 21:17:44 ] EAがやたらマルチプラットフォームでゲームを作れるのは この辺がしっかりしてるからかな まぁ無理だろうけど、一部位公開してほしいな 472 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 23:48:57 ] VC9でライブラリを作ろうとするとえらーがでます。 使えないですか？ 473 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 23:53:57 ] 主語を書け。 474 名前：デフォルトの名無しさん mailto:sage [2008/01/30(水) 00:12:34 ] むちゃぶりだな 475 名前：デフォルトの名無しさん mailto:sage [2008/01/30(水) 00:50:00 ] バージョンは5.1.5です。 476 名前：デフォルトの名無しさん mailto:sage [2008/01/30(水) 01:43:11 ] わたし にほんご わかりません 477 名前：デフォルトの名無しさん mailto:sage [2008/01/30(水) 01:59:02 ] ベンチャーキャピタルが図書館の設立に失敗？ 478 名前：デフォルトの名無しさん mailto:sage [2008/01/30(水) 15:09:31 ] STLportじゃないの 479 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 12:03:42 ] マルチスレッドにてqueueを使いたいのですが、 STL等にセマフォを任せることは出来ないでしょうか？ 480 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 12:06:11 ] 基本的にSTLはスレッドセーフではない。 481 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 12:31:30 ] >>479 いまどきの実装であれば、たいていドキュメントにマルチスレッドについて書かれている。 そういう記述が無いとか、書かれた保証では不十分だとか、広い移植性が必要だとか、 ドキュメントを読むのがメンドイとか言うんなら自分でなんとかするしかない。 482 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 18:06:11 ] std::stringの配列の連続性は保障されてないそうですが、 実際配列が連続じゃない実装をしてる環境ってあるんですか？ 483 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 18:10:37 ] 配列じゃないよ 484 名前：479 mailto:sage [2008/01/31(木) 18:50:24 ] >>480-481 ありがとうございました。　無い事が分かって安心しました。 必死で作って、既に有ったらかなり凹むのでｗ（勉強にはなるけど） WinAPIのCreateSemaphore()かmutexで検討したいと思います。 485 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 19:52:11 ] まあ実際はc_str()の動作を速くするために連続の場合が多いけどな。 しかもヌルターミネータ文字まで入ってたり。 486 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 19:54:51 ] >>482 ない。というか、次期の規格（C++0x）で連続性が保証されるようになる。 N2461) 21.3.1 basic_string general requirements [string.require] 3　 The char-like objects in a basic_string object shall be stored contiguously. 　　 That is, for any basic_string object s, the identity &*(s.begin() + n) == &*s.begin() + n 　　 shall hold for all values of n such that 0 <= n < s.size(). 487 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 19:58:43 ] std::ropeは標準じゃないけど、初めから切れ切れの文字列を つなぎ合わせる事を想定してるな。 488 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 20:01:32 ] だからstd::ropeにはメンバ関数c_str()がない。 489 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 20:02:47 ] でもSTLportのstd::ropeにはc_str()があったりする。変なの。 490 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 20:04:03 ] 標準じゃないのに std を使うのは違和感あるよな。 491 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 20:06:10 ] STLportはSGI-STLに妙なこだわりを持ってるよな。 何か言われてんのかな。 492 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 21:13:41 ] > 基本的にSTLはスレッドセーフではない 例えばどんな場合？ 493 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 21:15:33 ] >>492 どんな場合って・・・何するにしてもスレッドセーフを要求する 仕様なんてないはずだけども。 494 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 21:17:02 ] STLportはスレッドセーフだったような 495 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 21:21:14 ] うーん、書いてないとスレッドセーフでないってのも・・ beginthread一回でも呼ぶプロセスではstlは一行も使えないってことに なりそうな。 たぶん皆、同一インスタンスに複数スレッドでアクセスしなければ平気 くらいな解釈で使ってるんだよね 496 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 22:41:35 ] 標準にスレッドセーフという概念がないから語っても意味ないだろ 497 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:19:44 ] スレッドの概念自体が無い 498 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:26:59 ] ちっ、また自己責任かよ。つかえねーな 499 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:30:23 ] 効率のためにintの幅すら決めない言語に向かって何を言ってるのかね 500 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:39:35 ] int幅が実装依存なのはちゃんと作ってれば別に問題ないだろ。 501 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:41:25 ] 原子力発電所も冷凍餃子もちゃんと作ってれば別に問題無いぞ。 502 名前：デフォルトの名無しさん mailto:sage [2008/01/31(木) 23:41:37 ] AMD64は自然な長さが64ビットなのにintが32ビットだな

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef