08/01/28 19:59:46
>>443
やあチョーセンジン
447:デフォルトの名無しさん
08/01/28 20:06:35
>>442 欧米人にしたらCJK死ねよなわけだが。
なんでなかよくできんもんかね。
448:デフォルトの名無しさん
08/01/28 20:10:36
仲の良い隣国つーのは歴史上稀なわけだが。
稀つーかあるのか。
449:デフォルトの名無しさん
08/01/28 20:13:08
日本だって古代は中国と仲良かったじゃん。
あと、中国と韓国。
どちらも、主従関係だけどｗ
450:デフォルトの名無しさん
08/01/28 20:42:13
「仲良かった古代」、って遣唐使廃止まででそ。1000年も前の話だし。
451:デフォルトの名無しさん
08/01/28 21:41:37
当時は海ってのは命がけで渡るもの凄い大きな壁だったわけで、
隣国っつーよりは、日本とアメリカ・・・は言い過ぎかもしれんが、
そんな感じだったと思うぜ。
452:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/28 22:06:43
URLﾘﾝｸ(www.open-std.org)
こんなのがあったのね。知らんかった
確かにゲームや組み込みではSTLそのまま使うのはキツイわな
454:デフォルトの名無しさん
08/01/28 22:11:55
>>447
電脳創世記っていう本にあったんだが、そもそも「CJKその他ヨーロッパの小国死ねよ」
ってやってる連中はアルファベットしかないコードしか使ってなくて、それを日本人が
「文字コード問題は俺たちが解決して業績上げますからメリケン共は口出ししなくても良いよ＾＾」
って挑発して今の流れになったんだと思う。
455:デフォルトの名無しさん
08/01/29 02:36:05
>>453
ゲームがメモリをキツキツに使うからって、数バイト～数十～数百バイト単位の
標準ライブラリのメモリ確保までキツキツにしても、あんまり関係ないと思うんだ。
どうせ画像やサウンドデータが１個増えればだけでそこらへんの努力は
吹っ飛ぶもんじゃないの？処理負荷にしてもさ。
456:デフォルトの名無しさん
08/01/29 02:42:20
>>442
漢字使用国がそれだけは言っちゃいかんだろ
「じゃお前ら文字数が多すぎるから統合ね」と言われても何も言い返せない
むしろ韓国みたいにもっと初期の段階で分離しろと言い張れば分離できたかも
しれないのに日本人おとなしすぎ
457:デフォルトの名無しさん
08/01/29 02:55:03
文字、文字コード関係はこっちいけよ
458:デフォルトの名無しさん
08/01/29 02:55:33
ｽﾚﾘﾝｸ(tech板)
459:デフォルトの名無しさん
08/01/29 02:58:15
英語・日本語・中国語間のソフトやマニュアルの翻訳をやってるけど
ほぼ同じ意味の文章なら中国語が一番少ないデータサイズで書ける
460:デフォルトの名無しさん
08/01/29 03:06:02
そんなの中国語知らん俺でも分かるっちゅーの
461:デフォルトの名無しさん
08/01/29 03:47:21
utf-8で？
アニメの中国語のfansubとか見るとかなが入った日本語と
漢字ばっかりの中国語で文字数そんなに変わらんように見えたけど。
だから画数で言えば中国語は不利。
462:デフォルトの名無しさん
08/01/29 04:43:57
一文字に線をたくさん詰め込むんだから、字数が少なくならないとおかしい。
ような気もする。
463:デフォルトの名無しさん
08/01/29 06:14:49
>>455
ゲーム機はメインメモリ領域が結構キツイんでないの
464:デフォルトの名無しさん
08/01/29 06:33:10
>>440
嘘過ぎる
465:デフォルトの名無しさん
08/01/29 06:40:30
さすがに>>440は釣りじゃないのか
466:デフォルトの名無しさん
08/01/29 06:41:36
>>462
ちょうどいいのがなかったけど、これとか
URLﾘﾝｸ(jp.youtube.com)
467:デフォルトの名無しさん
08/01/29 07:28:09
詩とか台詞の翻訳はちょっと特殊じゃないか？
ってどこへ行こうとしてるんだこのスレは
468:デフォルトの名無しさん
08/01/29 15:13:48
標準STLではunicodeをちゃんと扱えるんでしょうか？
処理系依存では（例えばVC++とか）扱えそうですけど。
469:デフォルトの名無しさん
08/01/29 16:35:57
ちゃんと扱う、の定義次第。
wstring, wchar_t を問題なく扱えればOKなのか？それなら問題ないよ。
ロカール処理やエンコーディング変換のための十分なサポートがあるか？それなりしかない。
470:デフォルトの名無しさん
08/01/29 21:06:41
>>455
コンテナ(というかアロケータ)のメモリ効率は重要だと思うが。
アラインメントやページ境界にかなり気をつかっているらしい。
演算効率についてはちょっと読みきれていないが...
inline展開とか命令キャッシュ効率とか、分岐予測の弱いプロセッサのこととか、
いろいろ書いてある。
でかいボトルネックは取り除いた上でさらにどうがんばるかって話では。
>>463
"Game platform memory metrics"ってところに主要なゲーム機のspecが書いてある。
471:デフォルトの名無しさん
08/01/29 21:17:44
EAがやたらマルチプラットフォームでゲームを作れるのは
この辺がしっかりしてるからかな
まぁ無理だろうけど、一部位公開してほしいな
472:デフォルトの名無しさん
08/01/29 23:48:57
VC9でライブラリを作ろうとするとえらーがでます。
使えないですか？
473:デフォルトの名無しさん
08/01/29 23:53:57
主語を書け。
474:デフォルトの名無しさん
08/01/30 00:12:34
むちゃぶりだな
475:デフォルトの名無しさん
08/01/30 00:50:00
バージョンは5.1.5です。
476:デフォルトの名無しさん
08/01/30 01:43:11
わたし にほんご わかりません
477:デフォルトの名無しさん
08/01/30 01:59:02
ベンチャーキャピタルが図書館の設立に失敗？
478:デフォルトの名無しさん
08/01/30 15:09:31
STLportじゃないの
479:デフォルトの名無しさん
08/01/31 12:03:42
マルチスレッドにてqueueを使いたいのですが、
STL等にセマフォを任せることは出来ないでしょうか？
480:デフォルトの名無しさん
08/01/31 12:06:11
基本的にSTLはスレッドセーフではない。
481:デフォルトの名無しさん
08/01/31 12:31:30
>>479
いまどきの実装であれば、たいていドキュメントにマルチスレッドについて書かれている。
そういう記述が無いとか、書かれた保証では不十分だとか、広い移植性が必要だとか、
ドキュメントを読むのがメンドイとか言うんなら自分でなんとかするしかない。
482:デフォルトの名無しさん
08/01/31 18:06:11
std::stringの配列の連続性は保障されてないそうですが、
実際配列が連続じゃない実装をしてる環境ってあるんですか？
483:デフォルトの名無しさん
08/01/31 18:10:37
配列じゃないよ
484:479
08/01/31 18:50:24
>>480-481
ありがとうございました。 無い事が分かって安心しました。
必死で作って、既に有ったらかなり凹むのでｗ（勉強にはなるけど）
WinAPIのCreateSemaphore()かmutexで検討したいと思います。
485:デフォルトの名無しさん
08/01/31 19:52:11
まあ実際はc_str()の動作を速くするために連続の場合が多いけどな。
しかもヌルターミネータ文字まで入ってたり。
486:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/01/31 19:58:43
std::ropeは標準じゃないけど、初めから切れ切れの文字列を
つなぎ合わせる事を想定してるな。
488:デフォルトの名無しさん
08/01/31 20:01:32
だからstd::ropeにはメンバ関数c_str()がない。
489:デフォルトの名無しさん
08/01/31 20:02:47
でもSTLportのstd::ropeにはc_str()があったりする。変なの。
490:デフォルトの名無しさん
08/01/31 20:04:03
標準じゃないのに std を使うのは違和感あるよな。
491:デフォルトの名無しさん
08/01/31 20:06:10
STLportはSGI-STLに妙なこだわりを持ってるよな。
何か言われてんのかな。
492:デフォルトの名無しさん
08/01/31 21:13:41
> 基本的にSTLはスレッドセーフではない
例えばどんな場合？
493:デフォルトの名無しさん
08/01/31 21:15:33
>>492
どんな場合って・・・何するにしてもスレッドセーフを要求する
仕様なんてないはずだけども。
494:デフォルトの名無しさん
08/01/31 21:17:02
STLportはスレッドセーフだったような
495:デフォルトの名無しさん
08/01/31 21:21:14
うーん、書いてないとスレッドセーフでないってのも・・
beginthread一回でも呼ぶプロセスではstlは一行も使えないってことに
なりそうな。
たぶん皆、同一インスタンスに複数スレッドでアクセスしなければ平気
くらいな解釈で使ってるんだよね
496:デフォルトの名無しさん
08/01/31 22:41:35
標準にスレッドセーフという概念がないから語っても意味ないだろ
497:デフォルトの名無しさん
08/01/31 23:19:44
スレッドの概念自体が無い
498:デフォルトの名無しさん
08/01/31 23:26:59
ちっ、また自己責任かよ。つかえねーな
499:デフォルトの名無しさん
08/01/31 23:30:23
効率のためにintの幅すら決めない言語に向かって何を言ってるのかね
500:デフォルトの名無しさん
08/01/31 23:39:35
int幅が実装依存なのはちゃんと作ってれば別に問題ないだろ。
501:デフォルトの名無しさん
08/01/31 23:41:25
原子力発電所も冷凍餃子もちゃんと作ってれば別に問題無いぞ。
502:デフォルトの名無しさん
08/01/31 23:41:37
AMD64は自然な長さが64ビットなのにintが32ビットだな
503:デフォルトの名無しさん
08/01/31 23:48:23
intが64bitな処理系は現存するのか？
その場合、32bitを示す型は何だろう？
504:デフォルトの名無しさん
08/01/31 23:52:06
C言語が設計された時期が古いので64ビットとか考えてなかったんだろ
505:デフォルトの名無しさん
08/01/31 23:52:21
>>503
ILP64 でググれ。
506:デフォルトの名無しさん
08/02/01 00:09:02
32bitといったらlongなんじゃないのか
507:デフォルトの名無しさん
08/02/01 00:16:41
>506
まさか、int 64bitでlong 32bitと言ってる？
508:デフォルトの名無しさん
08/02/01 00:17:56
ねたにまじ（ry
509:デフォルトの名無しさん
08/02/01 00:24:17
LP64のほうが素直だねやっぱり。
I16/LP32はDOSで経験があるし(w
510:デフォルトの名無しさん
08/02/01 00:25:16
もうビット数気にする処理には stdint.h 使えばいいということで。
511:デフォルトの名無しさん
08/02/01 00:29:14
_int64とかタイプしたくないよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
4G超えのファイルなんかザラだろうが。
512:デフォルトの名無しさん
08/02/01 00:31:19
typedef すれば？
513:デフォルトの名無しさん
08/02/01 00:34:47
typedef _int64 long long ってできねーだろ
514:デフォルトの名無しさん
08/02/01 00:37:09
え？
515:デフォルトの名無しさん
08/02/01 00:37:34
long long とか名前長くしてどうするよ。
516:デフォルトの名無しさん
08/02/01 00:42:24
long long は既にあるべよ。long_long_long とかにしようべ。
517:デフォルトの名無しさん
08/02/01 00:44:20
>>515
C99にあるんですよlong long。
>>516
そうします。
518:デフォルトの名無しさん
08/02/01 00:47:19
long long ago むかーしむかし、あるところに長い長いアゴの男がおりましたとさ
519:デフォルトの名無しさん
08/02/01 00:50:58
_int64とはVC++くさいが、
VC++ .NET 2003からはlong longも使えるぞ。
520:デフォルトの名無しさん
08/02/01 00:51:20
中学の英語の授業中誰もが経験するであろうネタだな
521:デフォルトの名無しさん
08/02/01 00:53:43
>>516
別に知っとるが、_int64 の方が短くて分かりやすくていいじゃン
522:デフォルトの名無しさん
08/02/01 00:55:01
i8 u8 i16 u16 i32 u32 i64 u64
これでtypedefしとけば字数的にはint未満だ。何かとぶつかりそうだけどな。
523:デフォルトの名無しさん
08/02/01 00:55:52
そこで名前空間ですよ。
524:デフォルトの名無しさん
08/02/01 00:55:54
以下（8bitのみ未満）の間違い。
525:デフォルトの名無しさん
08/02/01 00:56:53
my_primitive_type::u64
なげーよ。
526:デフォルトの名無しさん
08/02/01 00:59:03
だから、自分のプログラム全体を特定の名前空間内に入れて、
そこで i8 とか定義しとけば何も付けなくて大丈夫。
527:デフォルトの名無しさん
08/02/01 02:14:27
stdintはC++の標準に入ったんだっけか
intN_tな連中。
528:デフォルトの名無しさん
08/02/01 02:18:41
_tてなんかの略？
529:デフォルトの名無しさん
08/02/01 02:30:24
type
530:デフォルトの名無しさん
08/02/01 02:47:05
>>527
最新のドラフトに cstdint と stdint.h が載ってた。次の改訂 (C++0x) で入るみたいだね。
531:デフォルトの名無しさん
08/02/01 06:38:05
C++0xはC99の(ほぼ)上位互換になるんですか
それともC99で使えてもC++0xではサポートされない機能もあり?
532:デフォルトの名無しさん
08/02/01 07:22:07
コンパウンドリテラルとか
配列個数に変数使うとか
そういうのは C++0x で無視
533:デフォルトの名無しさん
08/02/01 07:24:48
restricted ポインタとか色々無視されてる。
534:デフォルトの名無しさん
08/02/01 07:54:32
「配列の要素数に変数」はSTLと相性悪すぎだからな。
535:デフォルトの名無しさん
08/02/01 08:29:10
>>534
kwsk
536:デフォルトの名無しさん
08/02/01 09:01:10
コンパイル時に型が決まらない、だっけ？
537:デフォルトの名無しさん
08/02/01 13:51:10
type* v = new type[n]; ... delete[] v;
の糖衣構文にしてくれるだけでいいのに。
538:デフォルトの名無しさん
08/02/01 16:33:28
stlportsは2008には使えないの？
539:デフォルトの名無しさん
08/02/01 16:49:23
>>538
STLPort はインストーラ(make)が VS2008 にまだ対応していない。
手動でインストールするなら可能らしい。STLport VS2008 でググレ。俺はまだ試していないので、試したら結果を教えてくれ。
540:デフォルトの名無しさん
08/02/01 17:54:00
>>538
iostream使うとC2487がいっぱい出るよ
541:デフォルトの名無しさん
08/02/01 18:14:05
っ _STLP_STATIC_CONST_INIT_BUG
542:デフォルトの名無しさん
08/02/02 01:05:39
>>537
std::vector で何が不満なのさ？
543:デフォルトの名無しさん
08/02/02 01:06:58
見た目が汚い
544:デフォルトの名無しさん
08/02/02 01:09:31
はぁ？
545:デフォルトの名無しさん
08/02/02 01:21:27
std::vector<double> v(i);
と
double v[i];
なら下の方が綺麗だろう。
２次元配列とかなるともうキモいったらありゃしない。
546:デフォルトの名無しさん
08/02/02 03:43:09
エェー
547:デフォルトの名無しさん
08/02/02 04:00:52
valarray使えや
548:デフォルトの名無しさん
08/02/02 07:03:42
[i] はキモいだろ。どんだけ使い込んでるんだよ。
(i) これは正常。むしろ性情。
549:デフォルトの名無しさん
08/02/02 07:29:17
少し、頭冷やそうか
550:デフォルトの名無しさん
08/02/02 08:16:48
(O) ＜ くぱぁ
╋
/＼
551:デフォルトの名無しさん
08/02/02 11:50:57
>>548
FORTRAN か BASIC ばっかつかってるからそうなるんだ。
552:デフォルトの名無しさん
08/02/02 12:08:05
>>546 は
double v[i][j];
より
std::vector< std::vector<double> > v(i, std::vector<double>(j));
や
std::vector< std::vector<double> > v(i);
std::for_each(v.begin(), v.end(), std::bind2nd(std::mem_fun_ref(&std::vector<double>::resize), j));
の方が美しいと感じるようだ。
553:デフォルトの名無しさん
08/02/02 12:21:14
どうしても知識をひけらかしたい奴がいるようだ。
554:デフォルトの名無しさん
08/02/02 12:29:59
馬鹿か？
typedefしろよ
555:デフォルトの名無しさん
08/02/02 12:30:33
あんまりしょうもないtypedefたくさん作らないで欲しいお…
556:デフォルトの名無しさん
08/02/02 12:35:53
グローバルスコープでないならまだ許せる
557:デフォルトの名無しさん
08/02/02 12:50:03
typedef vector<int> vector_int;
typedef vector<double> vector_double;
…
こんなのがtypedefs.hに延々ならんでるソースを見せられたときは会社やめようかと思った。
結局1年しか勤めなかったけど･･
558:デフォルトの名無しさん
08/02/02 13:15:32
>>557
なにがあかんねん
559:デフォルトの名無しさん
08/02/02 13:17:39
>>558
いみないやん
560:デフォルトの名無しさん
08/02/02 13:18:26
まぁ普通意味を考えて命名するよな
#define VALUE_100 100
て定義する様なもの
561:デフォルトの名無しさん
08/02/02 14:29:30
>>557
そのレベルだと好みが分かれそうだなあ
vector<string> string_list
とかはありがちだけど。intとはな。。
562:デフォルトの名無しさん
08/02/02 14:32:11
vectorなのにlist?
563:デフォルトの名無しさん
08/02/02 14:36:40
>>561
そういう問題じゃない。
・typedef名に意味付けがない
↓のようなコメントと通じるものがある
a += 100; // aに100を足す
・字数がほとんど変わらず、打鍵数減少につながらない
…ところで、あなたは list<string>をどのようにtypedefするの？
564:デフォルトの名無しさん
08/02/02 14:39:41
んなマジレスされても。。名前考えんのめんどうだからしないねくらいだが
565:デフォルトの名無しさん
08/02/02 14:48:34
557に意味がないわけじゃないけどな。
typedefされた型しか使わないというのは、
互換性を重視するときは有利になる。
566:デフォルトの名無しさん
08/02/02 14:51:03
>>565
具体的にどんな移植性の問題が typedef によって解決されるんでしょうか？
567:デフォルトの名無しさん
08/02/02 14:54:21
>>565
typedefはそういう用途に使えることは否定しないけど、
vectorもintも標準の一部だから、互換性の点でもtypedef vector<int> vector_int;とする意味は無いんじゃないの。
568:デフォルトの名無しさん
08/02/02 14:55:54
>>566
typedefが移植性のためにあるようなものなのにな。
なぜなにの子供か？
569:デフォルトの名無しさん
08/02/02 14:56:04
もしかしてあれか？ int のサイズが違う環境では
typedef vector<long> vector_int;
に置き換えて「すっきり解決」とか、そういう話か？
570:デフォルトの名無しさん
08/02/02 15:01:04
intのサイズ違いをそのレベルで解決すべきじゃない。
571:デフォルトの名無しさん
08/02/02 15:03:50
つsize_t/off_t
572:デフォルトの名無しさん
08/02/02 15:05:24
だからやっぱり vector_int は意味無いだろ >565
573:デフォルトの名無しさん
08/02/02 15:31:24
std:: を省略できれば打鍵数が結構減る。
574:デフォルトの名無しさん
08/02/02 17:22:02
打鍵数とかでなく、会社からSTLは一律typedefせよ の命題が
課せられれば、vector_int みたいなものは生まれるし、それでもよいと思うぞ。
だから >>557 がどうこう言う程の問題ではないと思われるが。
こういうのは出たての若いのによくいる 自分は社内でも皆よりよく分かってる と
思いこんでる井の中の蛙ってこった。
575:デフォルトの名無しさん
08/02/02 17:31:06
std::foreachとかどうやってtypedefするの？
576:デフォルトの名無しさん
08/02/02 17:34:44
>>574
そんな命題を甘んじて受けるほど奴隷ではありません。
577:デフォルトの名無しさん
08/02/02 17:35:12
>>574
その通り、会社の方針なら勤めてる以上は従わざるを得ないのは言うまでもない。
そこで、無能だったり考え方の一致しなかったりする上司の下で働く羽目になった場合に取り得る行動は、
我慢して働きつづけるか、さっさと辞めるかの二者択一で、>>557は後者を選んだだけだろ。
別に非難されるようなことではない。
578:デフォルトの名無しさん
08/02/02 17:36:14
>>574
それは無能なプログラマが無能な会社に変わっただけで、>>557の判断には影響ないだろｗ
579:デフォルトの名無しさん
08/02/02 17:39:09
>>576
それで問題が発生したとき責任取って解決できるのなら
それでも良いんじゃね？ いざとなったら逃げるのはただの口だけ君。
580:デフォルトの名無しさん
08/02/02 17:43:00
vector<vector<vector<int> > >みたいなものを書かざるをえない状況なら
vector<T>をtypedefすることもあるんじゃないかな？
581:デフォルトの名無しさん
08/02/02 17:43:44
>>579
会社の命令に背いて問題を起こすなんて選択肢はもとからないよ
常識があれば、「従う」と「去る」の二択しか取れない
582:デフォルトの名無しさん
08/02/02 17:43:51
そんな当たり前の事言われましても。
583:デフォルトの名無しさん
08/02/02 17:48:52
>>566
このケースでvector<int>は必要なかったとしても、
list<string>はtypedefしたほうがいい。
とすれば、必要あるなしの境界はどこで切る？
こういう皆が使って判断の微妙な境界線は、
「一律typedef」が安全。
584:デフォルトの名無しさん
08/02/02 17:53:28
STLって型によらずアルゴリズムを記述できるような抽象化を
目指して作られてるはずなのに、ソースはtypedefだらけ。
それを異常と感じないほうがおかしい。
585:デフォルトの名無しさん
08/02/02 17:55:26
抽象的な書き方をしない箇所もある。適切にtypedefすることには何の問題もない。
586:デフォルトの名無しさん
08/02/02 18:03:04
そもそもどういう理由でtypedefしてるの？
587:デフォルトの名無しさん
08/02/02 18:04:36
>>584
抽象化するためにtypedefが必要だったりするし、STLなんかtypedefだらけだけど？
588:デフォルトの名無しさん
08/02/02 18:12:31
>>581
まぁね。 ドラマのまねっこで「僕はそんなことはできません」なんて
楯突いてその後その人間同士が上手く行くことなんてまぁないからね。
ドラマはご都合主義だから上手くいくけどさｗ
589:デフォルトの名無しさん
08/02/02 18:17:26
>>588
自分も会社の一員だけどね。そういうこだわりのない人間が集まってるから駄目な会社になったとも言える。
590:デフォルトの名無しさん
08/02/02 18:17:50
>>574
仕事ってオブジェクト(?)をもっと理解した方がいいよ。
逆に考えて、君がお客で 奴隷とかいうのが車屋の店員だったとする。
君は赤色の車を注文した。 しかし店員は「いやいまのトレンドは白です。
そこは譲れません」 と言ってるのと大して変わらん。
591:590
08/02/02 18:21:36
アンカー違い >>576 へ訂正
592:デフォルトの名無しさん
08/02/02 18:24:24
本日の課題
授業単元：コンピュータ理論
課題：本字の流れをvectorとlistを使って表しなさい。但しtypedefは使わないものとする。
593:デフォルトの名無しさん
08/02/02 18:27:27
販売拒否も車屋の勝手だろ
それで商売になるならそれでいいし、ならないなら別のことをするだけだ
意に反して赤い車を売らされることはない。もちろん妥協して赤い車を売ってもいい
594:デフォルトの名無しさん
08/02/02 18:33:44
>>590
それは違うだろ
595:デフォルトの名無しさん
08/02/02 18:43:17
>>593
おまえ尾崎豊の歌大好きだろ？ｗ
596:デフォルトの名無しさん
08/02/02 18:59:03
>>595
ほとんど聴いたことすらないｗｗ
597:デフォルトの名無しさん
08/02/02 19:31:33
typedef厨いる？
598:デフォルトの名無しさん
08/02/02 19:42:18
まあたいして責められてるわけでもないのに
いきなり奴隷なんて言葉を使い出す輩とは
あまり議論もしたくないな、おれは。
どこぞのウィルス流してつかまったヤツを想起してしまうよ。
599:デフォルトの名無しさん
08/02/02 19:49:14
>>587
それは抽象化とはいわん。単なる簡略化。
型の違いを意識の外に放り出してしまえるのが本来の抽象化。
現実はその逆。
600:デフォルトの名無しさん
08/02/02 19:49:59
個人でやってる分にはいいが、人が動かせない大きな岩(ﾌﾟﾛｼﾞｪｸﾄ)を
動かすには、全員が力合わせて同じ方向に綱引かないと成功なんか
ないよね。 俺は反対に引きたい とか関係ねーよ。
社会の歯車とかTVで憶えた訳分からん言葉に流されるべからず。
601:デフォルトの名無しさん
08/02/02 19:54:16
>>599
std::binary_functionの中とかでやってるtypedefはどう考えても抽象化のためだろ？
602:デフォルトの名無しさん
08/02/02 19:56:43
>>600
本心は別だろ？ｗ
マが鬱になる原因はそういうところが始まりなんだよ？
603:デフォルトの名無しさん
08/02/02 19:58:08
>593
本当は「会社として金を儲けるにはどうすりゃいい」というのに従うべきなんだけどな。
車売って利益上げるのが商売なんだから。
>586
色々。主に抽象化と手抜き。一例として
template<template<class>class trail_t>
struct Policy {
typedef trail_t<Policy<trail_t> > Trail;
// (snip)
};
template<class policy_t> // Policyの派生型を取り込むことを想定
class S {
typedef policy_t Policy;
typedef policy_t::Trail Trail;
// Trailをバンバン活用
};
といった感じで手が抜ける。
604:デフォルトの名無しさん
08/02/02 19:58:17
>>601
使ったこと無いから知らん
それにここまでの話の流れじゃはそういうとこじゃないだろ
605:デフォルトの名無しさん
08/02/02 19:59:30
俺は、木しか見ていない>>557より、森も見ている会社の
typedefs.hの方が賢いと思う。
606:デフォルトの名無しさん
08/02/02 19:59:50
ミス
それにここまでの話の流れじゃそういうとこじゃないだろ
↑typedef乱用のところな
607:デフォルトの名無しさん
08/02/02 20:00:42
>>604
使ったことないのね。了解。
608:603
08/02/02 20:01:43
ごめん。policy_tはPolicyの派生型じゃ無いわな。
609:デフォルトの名無しさん
08/02/02 20:19:10
>>602
本心は当然別よ。 本来人の考えが一致するなんて奇蹟ぐらいの考えで丁度いいよ。
映画あらしのよるに で上手く分かりやすく描かれてるよ。羊と狼が友情築くｱﾆﾒ風のやつ。
610:デフォルトの名無しさん
08/02/02 20:37:17
typedefs.h には元々プロジェクトの成功を見ていた２人の心を分かつ効果もありそうだ。
611:デフォルトの名無しさん
08/02/02 21:14:32
つうかコンテナをvectorからdequeに変えたくなった時や
intじゃなくて複素数入れたくなった時に
vector_int
じゃカコワルイだろ
612:デフォルトの名無しさん
08/02/02 21:18:35
おまいらソフトウェアプロジェクトマネジメントの本を読んでみ。「ピープルウェア」とか。
>600を実現するためにどれだけの苦労が必要かがわかる。
あくまでマネージャー視点だけど、プログラマ側からするとマネージャーの資質を
測るのに良いヒントになるよ。
ついでに「デスマーチ」もドゾー。現実は厳しいということを教えてくれる古典的名著。
613:デフォルトの名無しさん
08/02/02 21:19:56
そんな話はマ板でやれよ
614:デフォルトの名無しさん
08/02/02 21:20:00
>611 変えない……というのは冗談として。
そんときはリファクタリングじゃね？名前総取っ替えだろうね。
615:デフォルトの名無しさん
08/02/02 21:21:41
>613 だったら>603にコメント入れろよ。放置されてバカみたいだろ。
他のtypedefの使いかたでも良いよ。
616:デフォルトの名無しさん
08/02/02 21:27:10
だから vector_int には意味がなくて
typedef int Code;
typedef std::vector<Code> CodeList;
とか
typedef std::vector<Code> CodeSequence;
とかにしたほうが良いんじゃないのって言うのが良識のあるプログラマの意見じゃないかな
617:デフォルトの名無しさん
08/02/02 21:29:19
このスレでまともにSTLの話をしているのを見たことがない俺
618:デフォルトの名無しさん
08/02/02 21:35:25
文字コードの次はtypedefかお
619:デフォルトの名無しさん
08/02/02 21:40:05
で、赤い車は買えたの？
620:デフォルトの名無しさん
08/02/02 21:48:46
というか、おまいらTemplate使ってる？
Policyは非常に強力なコンセプトだと思うんだがね。
本当はもっと制約の少ないMix-in機能が欲しいけどね。
Policy同士で相互依存があると破綻しがちだから、けっこう設計が面倒。
621:デフォルトの名無しさん
08/02/02 21:49:24
>619
あぁ、早速それ乗って近くの本屋にEffectiveSTL買いに行く予定だよ
622:デフォルトの名無しさん
08/02/02 22:12:32
>>620
アレキサンドレスクの受け売りですか？
623:デフォルトの名無しさん
08/02/02 22:20:19
メイヤーズもヴァンデヴォーデも質問したら
ちゃんと返事くれるんだな。できる人は違うわ。
624:デフォルトの名無しさん
08/02/02 22:20:59
>>620
相互依存のあるPolicyなんて思い浮かばないんだけど
具体的にどんなの？
625:デフォルトの名無しさん
08/02/02 22:23:26
あれってヴァンデヴォーデって読むのか……
626:デフォルトの名無しさん
08/02/02 22:23:56
>622 基本的にはそんな感じなんだけど、Policyの組替えを想定してるんじゃなくて
単にデカいクラスのモジュール化をするときに使ったりしてる。
本当は包含とかでも何とかなるんだけどねぇ。
委譲関数書かなくて良いのが素敵なんで何となくポリシー使ってる。
627:デフォルトの名無しさん
08/02/02 22:26:16
>>625
いや適当
628:デフォルトの名無しさん
08/02/02 22:27:48
>624
もちろんきっちり設計してから組めば相互依存はほとんど無くすことができるんだけど、
トライ＆エラーで設計するときはそんなこと言ってられないからね。
ルーズに始めるときは、たいてい相互依存バリバリだったりする…………
リファクタリングするときも相互依存した状態を経由するから、そういうときも不便。
629:デフォルトの名無しさん
08/02/02 22:32:02
orthogonalってやつか
630:デフォルトの名無しさん
08/02/02 22:43:00
>629
直交に分離するのは理想だけど、神様でもなければ一発でそんなに上手く行くわきゃ無いよな。
631:デフォルトの名無しさん
08/02/05 08:39:38
std::map<T1, T2>をT2順に整列したものを使いたいんだけど、std::vector<std::pair<T1, T2> >に
コピーしてsortする方法だと、std::pair<T1, T2>が大きい時にコストがかかるのでイヤーン。
mapの要素へのポインタをvectorに格納してsortしたいんだけどうまくいかない。
std::vector<const std::pair<T1, T2>*>みたいの。
エロい人サンプルコード書いてくだちい。
632:デフォルトの名無しさん
08/02/05 09:21:28
const pair<const int, int>* addressof(const pair<const int, int> &obj)
{
return &obj;
}
map<int, int> m;
m[0] = 3;
vector<const pair<const int, int>*> vec;
transform(m.begin(), m.end(), back_inserter(vec), addressof);
こんな感じ？
633:デフォルトの名無しさん
08/02/05 20:54:58
ありが㌧。
でもソートも書いて欲しいよﾏﾏﾝ
634:デフォルトの名無しさん
08/02/05 22:28:39
>633
そんな難しくもなさそうな気もするけど、まずはうまくいかなかったコードを書いてみれば？
635:デフォルトの名無しさん
08/02/05 22:39:37
というか std::sortにbool op( const int *l, const int *r) { return *l<*r;}
を渡せば終わる話だからなー
636:デフォルトの名無しさん
08/02/05 22:44:01
pair だからそれだと足りない。けどまぁその程度ではあるんでどういうところでつまるのかな、という方に興味があったり。
637:デフォルトの名無しさん
08/02/05 23:10:39
こんなのは？意味違うかもしれんが。
typedef map<int, string> Mymap;
struct Mycomp {
bool operator()(const pair<const int, string>* p1,
const pair<const int, string>* p2) {
return p1->second < p2->second;
}
};
int main()
{
Mymap m;
//いろいろ挿入
vector<pair<const int, string>* > vec;
for(Mymap::iterator i = m.begin(); i != m.end(); ++i) {
vec.push_back(&(*i));
}
sort(vec.begin(), vec.end(), Mycomp());
}
638:デフォルトの名無しさん
08/02/05 23:15:32
sort_inserterみたいの作れば挿入とソートが一発で。コスト的にはあんまり美味しくないか。
639:デフォルトの名無しさん
08/02/06 00:02:14
>>638
それなんてstd::set?
640:デフォルトの名無しさん
08/02/06 00:15:23
>>639
pairのsecondだけでソートってできるんだっけ？
641:デフォルトの名無しさん
08/02/06 00:18:18
あー失礼、compare指定すりゃいいだけだ。
642:デフォルトの名無しさん
08/02/09 11:47:37
vectorで使用したメモリ領域を開放する方法を教えてください。
vector<int> v;
v.reserve (100000);
ぐらいの領域を使った後
v.clear ();
cout << "capacity = " << v.catacity() << "\n";
capacityが100000を返してくるのですが、どうやって領域を開放したらいいのでしょうか？
v自体はまだ使うので消したくありません。
643:デフォルトの名無しさん
08/02/09 11:54:07
vector<int>().swap(v);
644:642
08/02/09 12:01:01
>>643
できた。ありがとう！ お前まじ天才
さしつかえなければ、何をどうやって勉強すればお前みたいになれるのか教えてください。
645:デフォルトの名無しさん
08/02/09 12:03:27
とりあえず
つ"Effective STL"
646:642
08/02/09 12:08:50
買った。
これを読んで俺も天才になる
647:デフォルトの名無しさん
08/02/09 12:31:42
天才って言葉の使い方間違ってる
648:デフォルトの名無しさん
08/02/09 13:05:16
むしろ転載に近いよな。
649:デフォルトの名無しさん
08/02/09 13:29:09
メイヤーズSTLはジョスティスの内容をパクってるものが多い。
650:デフォルトの名無しさん
08/02/09 16:10:30
で っていう
651:デフォルトの名無しさん
08/02/09 17:58:50
その本にじょてぃすすげー参考にしたって書いてあったから
じょてぃす買った俺が通りますよ。
じょてぃすは絶版になるべきではなかった。
652:デフォルトの名無しさん
08/02/09 18:19:14
>>651
原書を読み漁ったおれもいますよ。平易な英語だから無問題。
653:デフォルトの名無しさん
08/02/09 19:24:52
Vandevoorde も忘れないでね。
654:デフォルトの名無しさん
08/02/09 19:50:38
>>653
TemplateならあるがSTLの本なんて書いてたっけ？
655:デフォルトの名無しさん
08/02/09 20:56:21
お前ら日本語でしゃべれ
656:デフォルトの名無しさん
08/02/10 02:11:51
よし今回だけだぞ
657:デフォルトの名無しさん
08/02/11 07:54:08
>643 の方法だとstd::stringには効果無いのですが、
stringの場合は明示的にメモリ解放する手段て無いのでしょうか？
658:657
08/02/11 08:06:11
すみません、VC2005のstd::stringだと、作成した
直後の状態である程度のバッファが確保されてるだけでした。
659:デフォルトの名無しさん
08/02/14 09:50:34
STLにTStringListみたいなのありましたっけ？
やっぱ、
＞std::vector <std::string>
ですか？
660:デフォルトの名無しさん
08/02/14 09:53:14
>>659
うん。 TStringList という名前だけ見ると、どちらかといえば std::list<std::string> かと。
661:デフォルトの名無しさん
08/02/14 10:03:11
有難う。
実は、vectorしか使ったことないのです。listとvectorの違いを知りたいです。
662:デフォルトの名無しさん
08/02/14 10:06:33
事故解決しました。
記述は大差ないみたいですね。
実行効率とメモリの違いみたいな。
URLﾘﾝｸ(ml.tietew.jp)
663:デフォルトの名無しさん
08/02/14 13:05:03
大差ある。
664:デフォルトの名無しさん
08/02/14 17:07:51
vector
ランダムアクセス可能。
メモリが連続している。
list
ランダムアクセスできない。
当該要素のerase以外で参照・イテレータが無効化されない。（個人的にはこれが一番重要）
任意位置への挿入・削除が定数時間。
独特な操作（spliceなど）がある。
選択する上で気をつけるのはこんなとこか？
665:デフォルトの名無しさん
08/02/14 17:20:05
なるほど、どうも有難うございます。
選択って意味では、
vector と list を間違えるより、
vector と map（←これもまだ使ったこと無いｗ） を間違えたら大変な気がしました。
666:デフォルトの名無しさん
08/02/14 18:24:34
いや、vector使うつもりでlistつかうよりmap使った方が多分マシだぞ
667:デフォルトの名無しさん
08/02/14 19:46:00
そもそもコンテナに何を求めているかによる。
連続性が重要ならlistもmapも同じくらい散々な目に遭うし、一応コンパイルが通ればいいだけなら
vectorでもmapでも問題ない。
668:デフォルトの名無しさん
08/02/14 21:59:15
ポインタつなげて線形リンクリスト作らされたことってないの？
669:デフォルトの名無しさん
08/02/14 22:17:35
>>668
標準ではないがstd::slistってのがある。
670:デフォルトの名無しさん
08/02/14 22:56:57
>>669
std::listだって線形リンクリストでしょ。双方向であるというだけで。
671:デフォルトの名無しさん
08/02/15 01:50:44
std::list って単方向じゃなかったけか？
672:デフォルトの名無しさん
08/02/15 01:53:08
いいえ。
673:デフォルトの名無しさん
08/02/15 01:53:10
あ、ごめ。双方向だった・・・
よく考えたら reverse_iterator 使えるもんね。
674:デフォルトの名無しさん
08/02/15 02:14:36
連続性が要らないなら、vectorよりdequeつかっとけって誰かえらいひとが
言ってた気がする
675:デフォルトの名無しさん
08/02/15 02:36:37
要素数が万単位にならなければlistよりvectorつかっとけって誰かえらいひとが
言ってた気がする
676:デフォルトの名無しさん
08/02/15 02:41:25
つ URLﾘﾝｸ(www.codeproject.com)
677:デフォルトの名無しさん
08/02/15 03:13:20
>>676
dequeメチャメチャ速いやん
678:デフォルトの名無しさん
08/02/15 03:35:20
むしろvectorがいらない子だろう
679:デフォルトの名無しさん
08/02/15 07:49:19
オブジェクトのサイズ/要素数が大きくない場合
listはvectorに比べてアロケーションの多さと断片化が弱点になりそうだよね
680:666
08/02/15 08:45:44
なるほど、今までvectorのみ使ってましたがmapにトライしてみます。
というより、実はネットで拾ったライブラリがmap使ってて、初期化宣言見ただけで”えっ”と思ってもう理解するの必須。
vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
何度も文献とかで確認しましたが、結局怖くて１つ１つイテレーター参照してますが。
ところで、map使うとプライマリキーみたいなのが必須ですよね？
キーがいる場合にはピッタリですが、開発途中でやっぱキーいらね、とかなったら、
とりあえず連番で埋めとけば良いわけですかね。
その時点でvectorかlistに差し替えかな。
>>668
線形リスト勉強しました。その頃C++どころかC初心者だったため、氏にました。
で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。
681:デフォルトの名無しさん
08/02/15 08:46:35
↑
＞666
は間違いで、665です。
682:デフォルトの名無しさん
08/02/15 09:04:18
mapについてそんなふうに思ってる人は始めて見たｗ
データベースみたいな複雑なものじゃなくてただの写像ですよ。
電話帳みたいな何かと何かの対応表だと思えばいい。
パフォーマンスに関してはそれを理解してからでいいと思う。
>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分大丈夫だけどやる必要ないならやらないに越したものはない。
>その時点でvectorかlistに差し替えかな。
パフォーマンス以前に用途が違うのでそのとおり。
>で、STLって何て便利なんだろう（これで使い方さえもう少し簡単であれば）って思ってまつ。
便利さを追求した結果こうなったんだろう。
ただしその上で、できるだけ簡単にはなってると思う。
683:デフォルトの名無しさん
08/02/15 09:56:51
mapなんて連想配列ですよ。awk使いの私が言うんだから間違いありません。
＞>vectorの連続性って、普通の変数配列みたいにメモリがばっとコピーしても大丈夫なんですよね？
多分じゃなくて大丈夫だけど、memcpy()などを自分で使うのはお勧めしない。潜在的なバグの原因になりかねない。
APIに渡すなどのように、必要に迫られたときに限定した方がいい。
684:デフォルトの名無しさん
08/02/15 10:18:40
boostとかにTStringListに近いものがあったりしないでしょうかね？
685:デフォルトの名無しさん
08/02/15 10:38:33
そんな無駄なものはない
686:デフォルトの名無しさん
08/02/15 10:39:27
ま、StringListクラス宣言して、中の人にmultimapすれば、自分でメソッド作るだけですか。
車輪の再開発とか言われたら嫌だから、既にあるものをなるべく使いたいです。
687:デフォルトの名無しさん
08/02/15 10:40:46
コンテナに使われている例えば連想コンテナのデータ構造（平衡二分木）とか
に詳しい人いる？
688:デフォルトの名無しさん
08/02/15 10:42:54
>686
どんなことがやりたいの？
689:686
08/02/15 10:55:33
どちらかというと、やりたいことがあるのでなくて、移植作業のためにTStringListメソッド実装。
CommaTextの入出力、iniファイルの１行処理のためのValues/Namesプロパティ、IndexOf、ファイル入出力メソッド、要素文字連結 etc..
690:デフォルトの名無しさん
08/02/15 11:11:00
>>687
ここにそれなりに詳しく書かれてるよ
URLﾘﾝｸ(ja.wikipedia.org)
691:デフォルトの名無しさん
08/02/15 11:29:40
>>689
組み合わせて使えばできそうな気がする。
boost.lambda
boost.string_algo
boost.tokenizer
ファイル入出力はfstreamとalgorithm使えばよし。
692:デフォルトの名無しさん
08/02/15 12:48:59
typedef vector<int> vector_int;
を
typedef deque<int> vector_int;
に書き換えただけで、うちのソフトの体感速度が上がったｗ
処理速度アップ！ってバージョンアップ唄えるお( ^ω^)
693:デフォルトの名無しさん
08/02/15 13:02:15
＞typedef vector<int> vector_int;
＞typedef deque<int> vector_int;
kwsk
何が違うのか教えれ！
694:デフォルトの名無しさん
08/02/15 13:09:15
vectorに数万とかpush_backして再アロケートが発生しまくったんじゃないかと予想
695:デフォルトの名無しさん
08/02/15 13:11:54
その２つはメソッドは同じなの？
696:デフォルトの名無しさん
08/02/15 13:13:34
バッファの連続性が必要なくて、
確保すべきメモリ量が事前によく分からないなら、
vector より deque の方が圧倒的に効率的。
697:デフォルトの名無しさん
08/02/15 14:07:45
いままでboost::shared_ptrのコンテナにstd::listを使ってたけど
std::dequeにしたら速くなるのかな
でもスマポのコピーは時間かかりそうだな...
698:デフォルトの名無しさん
08/02/15 14:11:04
push_back のコストは list より deque の方が平均的には少ないはずだが
699:デフォルトの名無しさん
08/02/15 14:16:41
mapってシーケンシャルアクセス、かつ、入れた順番に取り出す、もできますか？
700:デフォルトの名無しさん
08/02/15 14:18:42
もっと詳しく
701:デフォルトの名無しさん
08/02/15 14:20:57
mapをbeginからendまで参照した場合、
順番は、mapに登録した順番になっててくれますか？
702:デフォルトの名無しさん
08/02/15 14:23:46
>>699
入れた順番は失われる
703:デフォルトの名無しさん
08/02/15 14:24:29
>>701
Sort Criterionによる
704:699
08/02/15 14:27:50
＞Sort Criterionによる
kwsk
ググっても出ません。
705:デフォルトの名無しさん
08/02/15 14:30:43
map<string, int> m;
m["foo"] = 0;
m["bar"] = 1;
と、
map<string, int> m;
m["bar"] = 1;
m["foo"] = 0;
で異なる挙動になるようにしたいって事だろ？
標準のmapではどうやっても不可能だと思う
706:699
08/02/15 14:35:07
え”～ショック。
つまり、並び順が保障されるのは、vectorとdequeだけですかぁ。
707:デフォルトの名無しさん
08/02/15 14:37:31
だってmapはシーケンスコンテナじゃないし
708:デフォルトの名無しさん
08/02/15 14:42:34
>>704
テンプレートパラメータかオブジェクトととして渡す
ソート基準による。
709:699
08/02/15 14:47:40
じゃ、mapはやめて、vectorします。
vectorのヘルプ見てると、pos番目の要素をとるには[pos]ではなくて、at(pos)を使えと書いてありますね。
atを使わずに[]を使ってると、dequeに置き換えが出来なくなるわけでしょうか？
710:デフォルトの名無しさん
08/02/15 14:48:47
operator[]は範囲チェックをしないけどatはする
違いはそれだけ
dequeにもoperator[]はあるから、その心配は要らない
711:デフォルトの名無しさん
08/02/15 16:19:32
ごめん。未だに
「Associative Containerじゃ駄目なんですか。じゃあSequenceにします」
が簡単に出来る場面というのが想像できない
712:デフォルトの名無しさん
08/02/15 16:29:56
線形探索しても痛くないときとか
713:デフォルトの名無しさん
08/02/15 17:07:05
>>695 >>709
>>676のリンク先にも書いてあるけど、vectorとdequeのメンバ関数の違いは
・vectorにだけある……capacity() reserve()
・dequeにだけある……push_front() pop_front()
だけ。
いずれもメモリの連続性に関わるもので、前者が「あらかじめ確保しておく」系（dequeには要らない）、
後者が「先頭要素を出し入れする」系（vectorには高コスト過ぎ）。
714:695
08/02/15 17:11:30
ｻﾝｸｽ。
STLってｷﾓｶﾜｲｲね。
715:デフォルトの名無しさん
08/02/15 17:31:49
個人的にはlistがいらない子のようなきがしてます
716:デフォルトの名無しさん
08/02/15 17:40:48
dequeにはspliceが無いだろ？
717:デフォルトの名無しさん
08/02/15 17:46:29
listはアロケータさえちゃんと作れば、本当はやれば出来る子
718:デフォルトの名無しさん
08/02/15 17:54:59
vectorはお金がかかる子。
vector（笑）
719:デフォルトの名無しさん
08/02/15 18:11:05
vectorとdequeの最大の違いは、stackコンテナでdequeがデフォルト
コンテナとして使われてることを見ればわかるね。メモリ構造の違い
によってvectorは要素を削除した場合に絶対にメモリを解放しないが
dequeはチャンクの集まりだから不要なチャンクは解放されることが多い。
（これはstandardでは求められていないらしいが）
また、reallocateの際、vectorは全ての要素を移動する必要があるが
dequeは必ずしもそうはならない。同じ要素へのアクセスではvectorの
ほうが理論的には高速。dequeはメモリ構造上indirect accessとなるから。
このくらいしか気にしてないけど、結局は要素数と実測で決めることにしてる。
720:デフォルトの名無しさん
08/02/15 23:04:47
>>706
次期C++ではinsert(iterator, value)の意味が変わって、
同順の要素の間で好きな場所に値を挿入できるようになる。
それまではstd::map<Key, std::deque<T> >でも使うしかないね。
721:デフォルトの名無しさん
08/02/15 23:27:40
>>720
へぇ。知らなかった。
これか。
URLﾘﾝｸ(www.open-std.org)
722:デフォルトの名無しさん
08/02/16 00:04:14
メタプログラミングをゴリゴリやってる奴いないの？
STLを専ら使うだけ？
723:デフォルトの名無しさん
08/02/16 00:18:21
>>722
それはboostスレで。
724:デフォルトの名無しさん
08/02/16 12:16:37
C++/TemplateMetaProgramming専用スレってないの？
725:デフォルトの名無しさん
08/02/16 12:27:05
ないね。
欲しければ立てれば？
726:デフォルトの名無しさん
08/02/16 12:42:44
過疎りそうだけどな
TMPと言ったって大概はSTL、Boostの範疇だし
727:デフォルトの名無しさん
08/02/16 12:45:39
ｒ､ﾉVV＾ｰ八
､^':::::::::::::::::::::::＾vｨ ､ヽ l / ,
l..:.::::::::::::::::::::::::::::ｲ = =
|.:::::::::::::::::::::::::::::: | ﾆ= 724そ -=
|:r￢‐--─勹:::::| ﾆ= な れ =ﾆ
|:} _＿ ､.＿ ｀}f'〉ｎ＿ =- ら で -=
、､ l | /, , ,ﾍ}´`'｀｀ `´` |ﾉ:::|.| ヽ ﾆ .：. も ﾆ
.ヽ ´´, ,ゝ|、 ､, l|ヽ:ヽヽ } ´r ヽ｀
.ヽ げ き 724 ﾆ. ／|｛/ :ヽ -=- ./| |.|:::::| | | ´/小ヽ｀
= て っ な =ﾆ ／:.:.::ヽ､ ＼二／ :| |.|:::::| | /
ﾆ く. と ら -= ヽ､:.:::::::ヽ､.＿､ ＿,ﾉ/.:::::| | /|
= れ.盛 -= ヽ､:::::::::＼､＿＿／::.z:::::.:| |' :|
ﾆ る り =ﾆ | |:::::::::::::::::::::::::::::::::::.|'.:Y′ﾄ､
/, ： 上 ヽ､ | |::::::::::::::::::::::::::::::::::::_:::::_::| 'ﾞ, .＼
/ ヽ、 | |:::::::::::::::::::::::::::::::::::.|:::::::|.ﾄ､ ＼
/ / 小 ＼ r￢|ﾉ::::::::::::::::::::::::::::::::::::::::::::::::| ＼
728:デフォルトの名無しさん
08/02/16 12:46:16
724だけど、立てたぞ。
ｽﾚﾘﾝｸ(tech板)
729:デフォルトの名無しさん
08/02/16 14:03:50
>>726
甘いな
730:デフォルトの名無しさん
08/02/16 18:04:09
TMPとSTLって全然ちがくね？
731:デフォルトの名無しさん
08/02/16 18:10:33
どっちかっつーと、非 STL 部分の方が TMP っぽいな。
char_traits とか。
732:デフォルトの名無しさん
08/02/16 20:53:06
iterator_traits
733:デフォルトの名無しさん
08/02/16 22:54:48
numeric_limits
734:デフォルトの名無しさん
08/02/16 22:55:47
std::advanceもTMPっていっていいの？
735:デフォルトの名無しさん
08/02/16 23:00:21
いいんじゃね？
736:デフォルトの名無しさん
08/02/17 13:45:21
vectorやdequeってさ、変更せず読み込みだけなら複数スレッドからアクセスしても
大丈夫ですか？
737:デフォルトの名無しさん
08/02/17 13:49:27
volatileつけとけ
738:デフォルトの名無しさん
08/02/17 14:49:07
誰も書かないならvolatileいらない
739:デフォルトの名無しさん
08/02/17 15:05:58
例えばVisual C++ならここに書いてある。ほかは知らないけど。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
740:デフォルトの名無しさん
08/02/18 14:53:30
MFCやVCLにある、StringOfChar って無いですか？
ある文字を指定個数分返してくれるメソッド。
741:デフォルトの名無しさん
08/02/18 15:08:12
string s(10, 'A');
742:デフォルトの名無しさん
08/02/18 15:09:32
thx! >>741
あやうくfor文で回すところですた。
743:デフォルトの名無しさん
08/02/18 18:28:13
>>731
STLの中でメタプログラミングの要素があるのは
iterator_traitsとiterator_tagを使ったディスパッチくらいかな。
744:デフォルトの名無しさん
08/02/18 18:33:37
>>743
関数テンプレートのオーバーロードを利用した
ランダムアクセスとその他の振り分けか。
でもほとんど使ったことないなあ。
745:デフォルトの名無しさん
08/02/18 19:36:19
Vectorで、５番目の要素の次にデータを挿入したいときは、どう書きますか？
746:デフォルトの名無しさん
08/02/18 19:43:45
直接は使わなくても、advance とかで間接的には使ってる事ない？
747:745
08/02/18 19:44:02
既存の要素が４の場合と５の場合と、場合分けして、記述する必要があるのでしょうか？
748:デフォルトの名無しさん
08/02/18 19:46:41
既存の要素が１とかの時どうすんの？
749:デフォルトの名無しさん
08/02/18 20:07:40
>>745
std::vector なら v.insert(v.begin() + 5, value);
とかかな。要素数が最低5個は存在してないとマズイから。
v.size()で要素数調べる必要はあるか。
>>746
そういう意味では使うこともあるなあ。
本では読んだけど自分で書いたことはないな。
750:745
08/02/19 08:35:45
＞v.begin() + 5
あ、イテレーターって足し算できるんですね。
勉強になりました。
751:デフォルトの名無しさん
08/02/19 11:13:44
vectorのイテレータはランダムアクセス可能だからな。
752:745
08/02/19 11:15:48
では、vectorのイテレータだけが、＋－演算子定義されてるってことですか？
（dequeは無理と）
753:デフォルトの名無しさん
08/02/19 11:35:47
dequeもランダムアクセスイテレータなので+ - は定義されているよ
754:745
08/02/19 11:42:15
え”～、自分vectorのみ使ってるのに、それじゃvectorはやっぱり要らない子じゃん。
755:デフォルトの名無しさん
08/02/19 11:46:41
+や-ができないのは、たとえばlistとかsetの双方向イテレータ。
こいつらでは、インクリメントやデクリメントを繰り返す必要がある。
そんなときはstd::advanceなんていう関数が既に用意されている、もちろんO(N)。
vectorは、要素のメモリアドレスの連続が保障されているので、
組込の配列やmallocなんかで確保したメモリと同じように使えるという点が決定的にほかと違う。
例えばC用のAPIに渡すバッファなんかにも使える。
756:745
08/02/19 11:53:08
＞vectorは、要素のメモリアドレスの連続が保障されているので、
その通りなんですが、上レス読むと、やっぱふつーはイテレーター使えって逝われてるじゃん。
757:デフォルトの名無しさん
08/02/19 12:00:24
>>745-750
std::vector<int> v;
if (v.begin() + 5 > v.end()) v.resize(5);
を実行したら、VS2008 では Debug Assertion Failed! で落ちた。
v.end() を越えるような vector::itrator::opearator+() の結果に対して、
_SCL_SECURE_VALIDATE_RANGEマクロが範囲外を検出して例外を起こしている。
言いたいことはわかるが、融通利かせてほしい。
758:デフォルトの名無しさん
08/02/19 12:03:22
じゃ malloc的な使い方する時は、あえて
vector<int>って直書きしないとちょっと恐いな。
759:デフォルトの名無しさん
08/02/19 12:05:37
>>756
そうだから、vectorで要素へのポインタを使うのはchar*な引数に渡すなんて使い方くらいだね。
760:デフォルトの名無しさん
08/02/19 12:06:05
すまん、char*に限らず任意のT*でいいんだ。
761:デフォルトの名無しさん
08/02/19 12:13:51
>>757
組み込み配列だって要素数超える足し算は未定義動作なんだぜ。 assert() が
入ってる分ありがたいぐらいだ。
762:デフォルトの名無しさん
08/02/19 12:32:11
イテレータについて質問です。
イテレータをインクリメントするコストはコンテナによって違うと思うのですが、
STL解説サイトなどで、そのことについて触れているのをみかけません。
速度を知りたければ、実装毎にテストして計るしかないのでしょうか？
763:デフォルトの名無しさん
08/02/19 13:08:30
>>762
実際の速度(具体的な処理時間)を知りたいのならそれでいいんじゃね？
ソースやアセンブル結果を見て見当をつけても良いけど。
764:デフォルトの名無しさん
08/02/19 13:08:44
VC++2005で、
std::map<std::string,int> mp;
mp["key000"]=0;
とすると、「stringに>演算子がない」ってエラーが出るんだが、これって標準C++準拠の正しいエラーなのかな？
それともVC++2005のstringの方がおかしいのかな？
ネットで検索した時に普通にstd::stringをキーにしてるソースあったんで、問題ない書き方だとは思うんだが。
765:デフォルトの名無しさん
08/02/19 13:13:37
>>762
折角ソースがあるんだから読めばいいんじゃね?
766:デフォルトの名無しさん
08/02/19 13:18:50
>>764
標準準拠である確信は無いけど、g++-4.2.3では普通に使えた
767:デフォルトの名無しさん
08/02/19 13:31:04
>>764
VS2005でその二行を今書いているコードにペーストしてビルドしたけど、普通に通ったよ。
768:デフォルトの名無しさん
08/02/19 13:32:00
>>764
エラーメッセージを変に略さずに、そのまま晒したり Google に放り込むと、
なにか余計なことをしているのが見つかるかもしれない。
769:デフォルトの名無しさん
08/02/19 13:38:22
ヘッダincludeしてない時に出るメッセージに似てる…
770:デフォルトの名無しさん
08/02/19 13:38:42
>>764 ヘッダのincludeが足りてないのでは？
#include "stdafx.h"
#include <map>
#include <string> ←これをコメントアウトすると、「stringに>演算子がない」ってエラーが出る
int _tmain(int argc, _TCHAR* argv[])
{
std::map<std::string,int> mp;
mp["key000"]=0;
return 0;
}
771:764
08/02/19 13:45:41
早いレス㌧。
#include <string>が抜けてただけでした。
お騒がせして申し訳ないです。
772:762
08/02/19 14:07:09
>>763,765
どうもです。
ソース見て見当つけるの難しいですね(if文のコストとポインタ代入のコストの比率がどのぐらいになるのかとかさっぱりです)。
c++の制御文や演算のコストについて、本などでほとんど目にしないのですが、皆さんはどうやって勉強されました？
773:デフォルトの名無しさん
08/02/19 14:20:26
>>772
環境によって違うんだから、ある程度一般化せざるをえない本なんかで「勉強」するのは
無理だろ。
速度が要るプログラム組むときに、いろんなコードに対応するアセンブリを見て経験的に
身に付けるのがいいんじゃね？
環境が変われば結果が変わるということにも気をつけないといけない。
774:762
08/02/19 14:47:14
>>773
なるほど。
経験的に身につけていくしかないですか。
速度見積もるのに技術がいる上、環境で変わることを考えると、
速度はあまり気にせず、プロファイリングしてからボトルネックとなっている部分だけ考えるのがいいんでしょうね。
775:デフォルトの名無しさん
08/02/19 14:55:08
ばかすぎる
776:デフォルトの名無しさん
08/02/19 15:00:48
自己卑下ですか？
777:デフォルトの名無しさん
08/02/19 16:31:26
スパコンやx86-64のSSE2最適化の場合はvectorを使って、ベクトル化させたい場所はポインタに変換してる。
iteratorなんか使うと最適化してくれないし。
778:デフォルトの名無しさん
08/02/19 16:34:19
>>772
まあ、こういう細かい部分を気にするのは悪いことじゃないよね。
でもそれはC++の勉強ではなくて、ターゲット環境のしくみを先に勉強した方が良いよ。
CPUがC++で作ったコードをどう処理するのか、とかさ。
昔みたいにクロック数を数えれば分かるような簡単な時代じゃないけど、
その疑問に答えるためには、結局そのあたりの知識が必要だから。
779:デフォルトの名無しさん
08/02/19 17:38:29
スパコンでどんなソフト作ってんの？
780:デフォルトの名無しさん
08/02/19 17:59:00
>>777
やっぱり、本物の数値演算には valarray は使い物になりませんか？
781:デフォルトの名無しさん
08/02/19 18:00:28
下手にC++で書くよりMatlabで書いた方が早い
782:デフォルトの名無しさん
08/02/19 19:57:54
>>774
理論的な計算量のオーダーだけは気にしておいた方がいい。
O(N^2)の処理をやっている場所やO(N)の処理を繰り返す場所があったら
適切なコンテナやアルゴリズムを選定することを考えるべき。
結果的にはmapやsetを使うよりvectorを毎回検索、ソートした方が
速いというケースはあるけど、チューニングする以前のエイヤッと決める段階では、
理論的に速いアルゴリズムを選んでおいた方が無難。
783:デフォルトの名無しさん
08/02/19 21:41:57
>>780
つーか、C++自体が使い物にならなったりする。
ヌパコン屋はFortranしか本気でコンパイラを使ってない。
784:デフォルトの名無しさん
08/02/19 21:42:40
>>783
×使ってない
○作ってない
785:デフォルトの名無しさん
08/02/19 21:45:54
スパコンは並列化がキモだから、
並列化コンパイラの作りやすい Fortran を作りたがるのかもね。
言語仕様も単純で作りやすいし。
786:デフォルトの名無しさん
08/02/19 22:00:50
質問です。
vectorのイテレータが有効なイテレータかどうか調べる方法を教えてください。
787:デフォルトの名無しさん
08/02/19 22:04:23
質問です。
ポインタが有効なポインタかどうか調べる方法を教えてください。
と同じく、ありません。
788:785
08/02/19 22:30:42
>>787
わかりました。
ありがとうございます。
789:デフォルトの名無しさん
08/02/19 22:34:26
有効なポインタの全てと等しくならなければ有効・・・かも。
大小比較演算子使えるなら簡単になる。
当然、親となる配列が固定されていないと無理だが。
でも、こういうことしていいのかは微妙。
有効に見えるけど、指してる所が違うとかありうるし。
790:786
08/02/19 22:40:03
vec.begin() < itr && itr < vec.end()
こんな感じでやっていたのですがこれでいいのか不安でした。
791:デフォルトの名無しさん
08/02/19 22:42:01
やるなら vec.begin() <= itr かと。
それで一応どこか有効な要素は指してるかもしれないが、
「元々指していた箇所から決して動いていない」
ということまでは保証してくれない。
792:デフォルトの名無しさん
08/02/19 23:00:47
非常に厳密に言えば>>790のコードは全く意味がない
そのコードを実行してよい事前条件が、まさに itr が有効なイテレータであることなので
793:デフォルトの名無しさん
08/02/19 23:43:39
>>790
reallocateされた場合どうすんのよ？
794:デフォルトの名無しさん
08/02/19 23:55:31
なんだかんだいっても、あれだよあれ。
795:デフォルトの名無しさん
08/02/20 00:12:26
メジャーリーグに興味持ち始めた頃、STL vs ATLってのがあって何かと思ったら
セントルイス・カージナルス対アトランタ・ブレーブスだった。
796:デフォルトの名無しさん
08/02/20 09:16:18
＞vectorのイテレータが有効なイテレータかどうか調べる方法を教えてください。
＞vec.begin() < itr && itr < vec.end()
自分もこれに関する情報欲しい。
良い記述があれば教えてｷﾎﾞﾝ!
797:デフォルトの名無しさん
08/02/20 09:26:21
しかしイテレータをそんな長く持ってるのって
プログラムを考え直した方がよいような
798:デフォルトの名無しさん
08/02/20 09:35:17
いや、長く持つんじゃなくて、取得した直後に調べたいんだけど。
799:デフォルトの名無しさん
08/02/20 09:36:58
*itr
で対象をproxyにしてis_valid()でも持たせたら？
800:デフォルトの名無しさん
08/02/20 09:44:22
そのis_validの実装をどうするかの話をしてるんだろ…
801:デフォルトの名無しさん
08/02/20 10:16:45
盛り上がってきますたｗ
802:デフォルトの名無しさん
08/02/20 10:25:13
>>798
本当に「取得した直後」なら、i != vec.end()でいいのでは。
803:デフォルトの名無しさん
08/02/20 10:35:54
ｻﾝｸｽ>>802
絶対あってる？保障してくれる？
804:デフォルトの名無しさん
08/02/20 11:09:57
>>803
どんな手段で取得した直後を想定しているの?
805:デフォルトの名無しさん
08/02/20 11:10:48
どれだけ力強く保証したって、しょせん名無しのレスだぜ。
806:デフォルトの名無しさん
08/02/20 11:12:20
こんなに調べる気ゼロな奴だと知ってたら、大嘘教えたのにな。
807:803
08/02/20 11:14:32
>>804
>>745- のような使い方です。
808:デフォルトの名無しさん
08/02/20 11:16:06
>>806
本人からすると、ここで質問することだって調べる気でしょ。
そういう破壊的なことするのは良くないお( ＾ω＾)
809:デフォルトの名無しさん
08/02/20 11:20:42
答になってないぞ。
>>745に書いてあるのは「取得したあとにやりたいこと」。
質問は「どんな手段で取得した直後を想定しているのか」だ。
810:803
08/02/20 11:30:31
>>809
ですから、
vector::insertするためにはイテレーターが要りますよね？
で、item[6] としてイテレーターを取得したときに、そのイテレーターは有効なのか無効なのか、という判定。
811:デフォルトの名無しさん
08/02/20 11:51:08
>>810
イテレータを取得する前に検査すべき。
例えば、std::vector<int> foo(5); std::vector<int>::iterator it = foo + 6;の結果は鼻から悪魔。
812:デフォルトの名無しさん
08/02/20 11:54:57
>>810
item[6] ではイテレータを取得できないと思うよ
item.begin() + 6 のことか？
itemの6番目の要素が存在するなら、当然有効だし、
存在しないなら、何が返ってこようかくるまいが item.begin() + 6 を実行した時点でアウト
813:デフォルトの名無しさん
08/02/20 11:58:27
>>810
よくわからんが、こういうことか？
void foo(vector<int>& v, int index) {
vector::iterator iｔer = v.begin() + index; // この iter は有効か判断したい.
v.insert(iter, 5);
}
ならば、こう書けば良い
void foo1(vector<int>& v, int index) {
if (v.size() < index) v.resize(index); // iterが必ず有効になるように、事前にvectorを拡大する.
vector::iterator iｔer = v.begin() + index;
v.insert(iter, 5);
}
void foo2(vector<int>& v, int index) {
if (v.size() < index) throw std::invalid_argument("index が大き杉"); // 範囲外なら例外を投げる.
vector::iterator iｔer = v.begin() + index;
v.insert(iter, 5);
}
814:デフォルトの名無しさん
08/02/20 12:15:16
作った直後で無効なイテレータってあるのか？
作ること自体が違法だったり、作った後に無効になったりするのなら分かるんだが・
815:810
08/02/20 12:20:17
>>813
やりたいことは、
ある行の後に１行追加したい、
だから、foo1でできるのはできます。
でも、ある行の後に１行追加するメソッドくらい、std::vectorとかが標準で持ってて欲しいと思うお。
816:デフォルトの名無しさん
08/02/20 12:33:35
>>815
却下だな。
- 勝手に resize() するなら、途中の要素を何で埋めるか指定しないといけない。
- 挿入位置は iterator で指定するのが標準コンテナの流儀なのに、この場合だけ
インデックスで指定するのはおかしい。
- vector のメンバにしてもユーザーが実装しても効率などは変わらない。
標準で持っていたほうがいい理由が何も思いつかない。
817:デフォルトの名無しさん
08/02/20 12:35:35
>>814
作った直後のイテレータは、コンテナの中身を指しているか、end()と等値か、だよな。
だからこっちは「本当に作った直後なら、!= vector.end()との比較でいい」って言ってるのに、
この質問者、「自分の訊きたいこと」と「自分の訊いていること」を一致させられないんだよ。
818:デフォルトの名無しさん
08/02/20 12:57:08
おまえら頑張ってるが、実行効率も考えろ。
結果的に再取得したほうが良かったりして。
819:786
08/02/20 13:51:57
いろいろ勘違いしていました。
実際はイテレータじゃなくてただのインデックスでした。
0<=index<vec.size()
で十分でした。
イテレータの場合は持ってる間vectorを変更しないようにしています。
820:デフォルトの名無しさん
08/02/20 13:53:28
ｴｴｪｪｪ
821:デフォルトの名無しさん
08/02/20 14:18:16
>>819
う゛ーう゛ー
822:デフォルトの名無しさん
08/02/20 14:20:36
これは酷い釣りだ…
823:デフォルトの名無しさん
08/02/20 16:22:14
結論としてイテレーターは役立たずでOk?
824:デフォルトの名無しさん
08/02/20 16:30:10
list をイテレータなしでというのはちょっと
vector にはいらないけどさ
825:デフォルトの名無しさん
08/02/20 16:37:03
listの返したイテレータが無効になるタイミングって、
list本体が破棄された場合と、イテレータ先がeraseされた
時だけでしょうか？
826:デフォルトの名無しさん
08/02/20 16:46:18
元からC++にあった下位概念（ポインタ）が要求するメモリ構造を持っているvectorは、
後から加わった上位概念（イテレータ）を使わずとも、下位概念のやり方で各要素を見ていける、
だから「必須ではない」・・・という意味では、無くてもいいかもね。
実際には、stringやlistがbegin() end()してる中、vectorだけ&vec[0]とか使ってポインタでいじるのは
えらく不自然だから、vectorもイテレータで扱ってしまうけれども。
827:デフォルトの名無しさん
08/02/20 18:04:53
>>825
合ってる(要素を消す関数はerase()以外にもあるけど)。あと標準には
list1.splice(list2);
するとlist2へのイテレータが全部無効になる、と書いてあるけど、
実際にはほぼ間違いなくlist1への有効なイテレータになる。
これは標準の方が訂正される可能性が高い。
828:デフォルトの名無しさん
08/02/20 19:40:59
>>827
返答ありがとうございます。
listに要素追加したときイテレータを保存しておいて、
それを別なコンテナでインデックス化するってな使い方を
しても大丈夫そうですね。
spliceの
＞実際にはほぼ間違いなく
ってところはちと怖いので、使用は避けときます。
829:デフォルトの名無しさん
08/02/20 21:01:56
>>827
最新のドラフトだと 「移動した要素を指し続ける」 と書いてあるね。
830:デフォルトの名無しさん
08/02/20 21:36:58
250. splicing invalidates iterators
Section: 23.2.3.4 [list.ops] Status: WP Submitter: Brian Parker Date: 2000-07-14
void splice(iterator position, list<T, Allocator>& x);
invalidates all iterators and references to list x.
This is unnecessary and defeats an important feature of splice. In fact, the SGI STL guarantees that iterators to x remain valid after splice.
WPってWorking Paperってなってるけど一度却下されてるんだよね。
で、最新のドラフトだとC++0xで修正されることは決定？
WP The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.
831:デフォルトの名無しさん
08/02/20 21:44:24
N2461 だと次のように書いてある。
23.2.3.4 list operations
void splice(const_iterator position, list<T, Allocator>&& x);
4 Effects: Inserts the contents of x before position and x becomes empty.
Pointers and references to the moved elements of x now refer to those same elements
but as members of *this.
Iterators referring to the moved elements will continue to refer to their elements, ← ここ
but they now behave as iterators into *this, not into x.
832:デフォルトの名無しさん
08/02/20 21:49:02
moveの導入による影響おそるべし
833:デフォルトの名無しさん
08/02/20 21:53:24
>>831
Working Draftか。
そうなりそうだね。
834:デフォルトの名無しさん
08/02/20 22:02:47
>>832
list の splice は，標準ライブラリへの move の本格導入以前から，
auto_ptr と並ぶ標準ライブラリにおける move の代名詞だったような？
現行の規格が不必要に制限が強すぎた
(iterator の stability を保証しなかった) だけで，
move 導入とは直接関係ないんじゃないですかね？
>>831の splice の第2引数が右辺値参照型に変更されたのも
単に一時変数を渡すことができるようにしただけでしょうし．
835:デフォルトの名無しさん
08/02/20 22:05:17
rvalue reference うぜえな。。 基本仕様としては
これが一番インパクトでかいかな。
836:デフォルトの名無しさん
08/02/20 22:07:39
concept 周りが間に合えばあれも相当インパクト大きいのでは
837:デフォルトの名無しさん
08/02/20 22:07:54
今まで
const Widget operator+(Widget, Widget)
とかしてたものが
Widget&& operator+(Widget, Widget)
になるのか。
838:デフォルトの名無しさん
08/02/20 22:08:37
テンポラリオブジェクトを渡せるようになるのはいいのだが、
そのせいで左辺値参照でいい状況でもムーブが発生するのが微妙だな。
839:デフォルトの名無しさん
08/02/20 22:26:14
以下は C++0x を前提にしたレスです．スレ違いですいません．
>>837
Widget の実装と operator+ の機能によりますけれど
値で返すのと参照で返すのでは基本的に意味が違ってしまうのでは？
で， move の恩恵を受けたければ Widget を move 可能にした上で
Widget operator+(Widget, Widget)
となるのが一般的かと思います．
>>838
＞そのせいで左辺値参照でいい状況でもムーブが発生するのが微妙だな。
その微妙になる具体例ってどんなのがありますかね？
840:デフォルトの名無しさん
08/02/20 22:37:12
l1.splice(it, l2);
右辺値参照の場合
1. l2 -> x のムーブ
2. x のノードを l1 に付け替える
左辺値参照の場合
1. l2 のノードを l1 に付け替える
841:デフォルトの名無しさん
08/02/20 22:42:46
>>839
戻り値をWidgetにしてしまうと代入できてしまうので
constをつけてるんだけど、
①const Widget operator+(const Widget&, const Widget&);
②Widget&& operator+(const Widget&, const Widget&);
現在は①のようにしてるけど、C++0xからは②でいいかなと思った。
どちらも
Widget w1, w2, w3;
if( (w1 = w2) = w3 )
のようなケアレスミスをコンパイルエラーにしてくれると思ったけど、
②だと (w1 = w2) = w3 はOKになってしまうか。右辺値参照に左辺値
は代入できるか。
842:デフォルトの名無しさん
08/02/20 22:44:44
const Widget operator+(const Widget&, const Widget&);
と書いた場合、const Widget はムーブできるのか？
843:デフォルトの名無しさん
08/02/20 22:44:56
>839
>838 じゃないけど。
値渡しにした段階でコピーが発生しちゃうから、
Widget&& operator+(Widget&&, Widget&&);
Widget&& operator+(Widget&&, const Widget&);
Widget&& operator+(const Widget&, Widget&&);
Widget operator+(const Widget&, const Widget&);
頑張るんならこうなるんじゃないの？
std::string の operator+() はこうなってるが。
あと、微妙ってのは左辺値参照なら単純にアドレス渡すだけで済んだものが、ムーブ処理が発生しちゃうのが嫌ってことなんじゃないかと。
で、↑はそのためにオーバーロードしてるけど。
844:デフォルトの名無しさん
08/02/20 22:46:52
>>840
引数のl2は右辺値という前提だよね。そうするとmoveの分だけ効率が
悪くなるということかな。
845:デフォルトの名無しさん
08/02/20 22:51:32
>>842
ん？メイヤーズの本で推奨されてたから従ってる。
>>843
ドラフト見たところでは、例えば
Widget&& operator+(Widget&& lhs, const Widget&& rhs);
の場合、両方の実引数にWidgetの一時オブジェクトを
渡すとlhsとrhsは右辺値になって、両方に左辺値を渡すとlhsとrhsは
左辺値になるという理解でいい？
846:デフォルトの名無しさん
08/02/20 22:55:53
>>840
現行の list の splice の意味からすると，
splice という名前に前者の操作を overload させると混乱するのでは？
前者は最新の working draft に従えば，例えば
l1.splice(it,decltype(l2)(move_iterator(l2.begin()),move_iterator(l2.end())));
と書けると思いますけれど，これではダメなのですか？
あと，「左辺値参照の場合……」「右辺値参照の場合……」という書き方を
されていますけれど， l2 の型が右辺値参照型か左辺値参照型か，ということですか？
もしそうだとすると，l2 はそのままでは常に左辺値として扱われるので，
void splice(iterator, list<T,A>&);
と
void splice(iterator, list<T,A>&&);
があった場合には， l2 が右辺値参照型か左辺値参照型かに関わらず
常に前者が呼ばれると思います．
847:デフォルトの名無しさん
08/02/20 23:00:25
しかし void splice iterator, list<T,A>&); は存在しない
848:デフォルトの名無しさん
08/02/20 23:03:20
>>841
一時オブジェクトに対するメンバ関数呼び出しの overload は
右辺値参照型の *this への拡張が対応するかと思います．
URLﾘﾝｸ(www.open-std.org)
例えば，右辺値に対して Widget::operator=(const Widget&) を禁止したければ
class Widget{
Widget& operator=(const Widget&) & { ... }
Widget& operator=(const Widget&) && = delete;
...
}
上記のようになるかと思います．従って Effective C++ にある>>845の記述は
C++0x では deprecated になるかと思います．
849:デフォルトの名無しさん
08/02/20 23:06:33
>>842
move はそのソース (move 元) に対して破壊的操作を行うことになるので
戻り値に対して const を指定しているとその戻り値に対して
move を行うことはできなくなると思います．
Widget& Widget::operator=(const Wideget&); // copy assignment
と
Widget& Widget::operator=(Wideget&&&); // move assignment
があった場合，>>842の operator+ の戻り値に対しては
オーバーロードの優先順位を解決した結果， copy assignment が呼ばれるかと．
850:デフォルトの名無しさん
08/02/20 23:06:55
dequeとvectorの速さ比べをしてみた(gcc 3.4.5 mingw)
for(i=0; i < num; i++){
foo += v[i];
}
みたいなの。
vectorの先頭をポインタに渡してポインタ経由でアクセス
>>>>>>vectorを[]でアクセス>>>vector をiteratorでアクセス=dequeをiteratorでアクセス
>>>>>>>(越えられない壁)>>>>>>dequeを[]でアクセス
dequeがあればvectorはいらない子みたいなカキコがあったけど、やっぱvectorはやればデキる子だよ。
851:デフォルトの名無しさん
08/02/20 23:15:29
>>843
ありがとうございます．微妙な具体例が理解できました．
これを気にするならば overload 頑張るしかないですね．
852:デフォルトの名無しさん
08/02/20 23:18:07
オーバーロードで解決は出来るけど、
沢山あると大変だね。
853:デフォルトの名無しさん
08/02/20 23:27:12
蛇足ですけれど，>>843は書かれているような「微妙な状況」の他に，
引数が一時オブジェクトで，その一時オブジェクトのバッファが
結合後の文字列を保持できる余裕がある場合に，
バッファの再確保を回避できる最適化を積極的に活用できる
というのもあるかと思います．
854:デフォルトの名無しさん
08/02/20 23:34:05
>>847
元々 splice は move (破壊的コピー) を行うという意味づけであり
右辺値と左辺値を区別する必要はなく，
void splice(iterator, list<T,A>&);
と
void splice(iterator, list<T,A>&&);
をオーバーロードする必要もないと自分は思います
(し，おっしゃるとおり working draft も今のところそうなっています)
855:デフォルトの名無しさん
08/02/20 23:35:07
>>850
vectorアクセスするのにiterator経由より[]の方が速いって謎すぎる。
何らかの理由で最適化に失敗してるか、assertが効いてるんじゃ？
856:デフォルトの名無しさん
08/02/20 23:48:29
>>855
最適化オプション何もなしだお
857:デフォルトの名無しさん
08/02/20 23:49:40
>>855
ちなみに、倍速くらい
ポインタにすると[]のさらに倍
ちなみにdequeの[]はvectorの[]の4倍遅い
858:デフォルトの名無しさん
08/02/20 23:50:03
-O2つけて測定コード毎最適化で消してしまえ。
859:デフォルトの名無しさん
08/02/20 23:50:18
あほすぎ。
860:デフォルトの名無しさん
08/02/20 23:54:00
ふつーSTLは最適化かけて実測するもんだと思ってたのだが、違うのか？
861:デフォルトの名無しさん
08/02/20 23:57:15
STL に限らず、実測は最適化かけてからやるのが普通。
最適化しない場合の影響を調べるのでもない限りは。
862:デフォルトの名無しさん
08/02/21 00:05:39
ふつー、最適化をかけるとvetor::operator[]はポインタアクセスと同じコードに
展開される。実際、gcc3.4.6 -O2ではそう。
863:デフォルトの名無しさん
08/02/21 00:24:53
dequeのメモリ構造は複数のメモリブロックから成っているので
ブロック間でindirect accessが発生するから、要素へのアクセス
とiteratorの操作はvectorより遅くなるというのが一般論。
864:デフォルトの名無しさん
08/02/21 00:35:31
>>854
ほほう。結局、
void splice(iterator pos, list<T,A>&& l2);
この場合、l2に右辺値（一時オブジェクト）を渡そうが
左辺値を渡そうが、l2は常に左辺値として扱われるという
ことだよね？この仕様変更のメリットとしては、右辺値も
渡せるということかね。
865:デフォルトの名無しさん
08/02/21 00:47:02
>>864
splice の定義内では，明示的にキャストをかけるか
std::move を使うかしないと l2 は左辺値として扱われると思います．
＞この仕様変更のメリットとしては、右辺値も渡せるということかね。
自分はそう理解していたので>>834のように書きました．
右辺値が渡せるので>>846に書いたような
l1.splice(it,decltype(l2)(move_iterator(l2.begin()),move_iterator(l2.end())));
みたいなコードも通るようになります．
866:デフォルトの名無しさん
08/02/21 00:50:32
>>865
後半は漏れの理解不足で分からんけど、アリガトン。
867:デフォルトの名無しさん
08/02/21 00:55:32
>>866
すいません．
l1.splice(it,list<int>(l2.begin(),l2.end()));
みたいなコードも通るようになるといいたかったんです．
といいますか>>846のとかこれの場合は insert で良いですね……orz
868:デフォルトの名無しさん
08/02/21 01:37:08
>>867
いえいえ。
move_iteratorとか見たことなかったので漏れの理解不足というより
知識不足だった。範囲指定のコンストラクタで一時オブジェクト
をそのまま渡すことができると。
それが、l1.insert(it, l2.begin(), l2.end());で可能だったという
こっですね。
869:デフォルトの名無しさん
08/02/21 10:09:34
>>813
＞vector::iterator iｔer = v.begin() + index;
やっぱ、イテレーターとるときってbegin()で取るのが正しいのか。
＞vector::iterator iｔer = &v[index];
ってのはダメ？
ってか、おｋ、だったとしてもvectorとdequeでしか通用しないＢＡＤな書き方？
870:デフォルトの名無しさん
08/02/21 10:21:31
それはポインタ。
全てのSTL実装でコンパイルが通る保証はない。
871:デフォルトの名無しさん
08/02/21 10:27:49
ｻﾝｸｽ。
つまり、書き方という問題じゃなくて、使ってるSTLの実装上たまたまコンパイルエラーが出ないだけなんだね。
すげー賢くなったお( ＾ω＾)
872:871
08/02/21 10:30:40
あっ、本当だ。vectorをdequeに変えたらコンパイルエラー。
実行時エラーじゃなくて、コンパイルエラーなのは好感( ＾ω＾)
873:デフォルトの名無しさん
08/02/21 12:52:05
散々既出だけど、vectorの場合は、int* p = &v[index];も可能。
ただ、end相当の&v[v.size()]は未定義だから、&v[0] + v.size()を使えって話があった気もする。
874:デフォルトの名無しさん
08/02/21 12:58:44
いいえ。
875:デフォルトの名無しさん
08/02/21 13:01:28
>int* p = &v[index];
これはvectorに限らずあらゆるコンテナで可能だろ
876:デフォルトの名無しさん
08/02/21 13:08:38
そうですね。
877:デフォルトの名無しさん
08/02/21 13:09:09
え”？
dequeでコンパイルエラー出たけど、気のせい？
もうテストコード消しちゃったお。
878:デフォルトの名無しさん
08/02/21 13:11:06
>>875
釣りですか？
879:デフォルトの名無しさん
08/02/21 13:17:54
いいえ。
880:デフォルトの名無しさん
08/02/21 13:37:04
不正確な物言いだったな
operator[]を持っていて、value_typeがintであるような、あらゆるコンテナのインスタンスについて可能、と言いたかった
881:デフォルトの名無しさん
08/02/21 13:55:22
それはうっかりだった、すまん。
vectorのポインタの場合は、配列の要素を指すポインタの如く、
ポインタ演算を使用してそのvectorインスタンスの保持する他の要素も参照できると言えばいいか。
882:デフォルトの名無しさん
08/02/21 13:58:46
std::stringは、イテレーﾀﾝを無視して、何文字目かを数字で指定しても、おｋだおね？
883:デフォルトの名無しさん
08/02/21 14:03:08
＞ただ、end相当の&v[v.size()]は未定義だから、&v[0] + v.size()を使えって話があった気もする。
で、これは?
884:デフォルトの名無しさん
08/02/21 15:09:32
&v[0]の時点でただのポインタなんだから、それにどんな値を足しても
指してる先にアクセスしなきゃ大丈夫でしょ。
885:デフォルトの名無しさん
08/02/21 15:30:22
配列の最後の要素の一つ後の要素のアドレスをポインタ演算に
使用することは規格で認められていた記憶がある。
これが正しければ &v[v.size()] は有効だと思う。
886:デフォルトの名無しさん
08/02/21 15:30:54
>>884
ダウト。
887:デフォルトの名無しさん
08/02/21 15:31:47
stringのuppercaseはどう書きますか？
888:デフォルトの名無しさん
08/02/21 15:56:50
>>885
その式は右から評価するからアウト
889:デフォルトの名無しさん
08/02/21 16:01:43
>>885
vectorのoperator []は多重定義された関数なのだから、それとは別に規定があるはず。
と思ってX 3014見てみたが、23.1.1 列の中で参照されている表68に
a[n]は*(a.begin() + n)と書かれているがそれ以上は何もない。
もちろん、atはn >= a.size()のときにout_of_rangeを送出と書いてあるけど。
890:デフォルトの名無しさん
08/02/21 16:23:53
>>885
v[v.size()]の時点で鼻から悪魔確定だろ
891:デフォルトの名無しさん
08/02/21 16:27:30
>>890
なんで？
892:デフォルトの名無しさん
08/02/21 16:29:38
>>886
なんで？
893:デフォルトの名無しさん
08/02/21 16:36:28
>>889
a.begin() + n は dereferenceable ではないので
これを dereference した時点で規格としては undefined behavior，
でよいのでは？
894:デフォルトの名無しさん
08/02/21 16:48:51
std::string に trim が無いなんて不自由でつね。
895:デフォルトの名無しさん
08/02/21 16:51:25
まぁ、色々足りないものはある。
896:デフォルトの名無しさん
08/02/21 17:25:46
>>888
No
アドレス演算子&はオペランドが[ ]演算子の結果の場合、単項&演算子と
[ ]演算子が暗黙に意味する単項*演算子は評価されず、&演算子を削除し
[ ]演算子を+演算子に変更した場合と同じ結果となる。
つまり、&v[v.size()] は v + v.size() に評価されるのであって、
&(*(v + v.size)) とは評価されない。
897:デフォルトの名無しさん
08/02/21 17:27:38
>>888
C言語もあまり詳しくないだろ？K&Rにも、>>885が正しいことは書いてある。
かつ、C++でも同じ。
898:デフォルトの名無しさん
08/02/21 17:44:24
>>896
それはポインタについてじゃないのか
>>889も言ってるが、vectorの[]や、vectorのイテレータの+と*は単なる関数かもしれない訳で、
ポインタについての規定がそのままあてはまるとする理由はないだろ
899:デフォルトの名無しさん
08/02/21 18:01:34
stringの数字チェックはできますか？
900:デフォルトの名無しさん
08/02/21 18:47:36
>>898
そのとおりだ。ポインタの話しと思ってた。
901:デフォルトの名無しさん
08/02/21 18:52:15
&v[0] + v.size()でOK
902:デフォルトの名無しさん
08/02/21 22:31:04
私はヘタレなのでそんなに悩んでる暇があったらイタレータ使っちゃいます
ごめんなさい
903:デフォルトの名無しさん
08/02/21 22:33:11
>>902
僕もです。
904:デフォルトの名無しさん
08/02/21 23:01:29
サイズが0のときの&v[0]は不定だ。VS2005だとアサート。
905:デフォルトの名無しさん
08/02/22 00:39:14
おかしなコード書きすぎ＞＜
906:デフォルトの名無しさん
08/02/22 08:41:26
結局STLって無いと困るけど、書き難いね。
複数ファイルイメージみたいなのをバッファに持っておきたいばあいは、
みなさんどうされてます？
void*？char*?
やっぱ、vector <char*>みたいな感じ？
907:906
08/02/22 08:54:20
*で宣言しちゃうと、メモリの開放を書かないと逝けないから、
vector <string>の方が良いかなぁ？
908:906
08/02/22 09:30:49
たまには質問にも応えて欲しいお。
909:デフォルトの名無しさん
08/02/22 10:05:33
>>906
テキストファイルである保証があるなら兎も角、普通はvector<string>はつかわんだろ。
つーか、ファイルの内容によって違うものを一般化されても困る。
910:906
08/02/22 10:06:37
テキストファイルじゃなくてバイナリファイルです。
TMemoryStremaみたいなのが欲しいんです。
911:デフォルトの名無しさん
08/02/22 10:08:23
ファイルをvector<char>に入れるとして、複数ファイルならvector<vector<char> >でいいんでね?
なにをやりたいか判ればもっと適当な方法もあるかもしれないけど。
912:デフォルトの名無しさん
08/02/22 10:08:31
>>906 vector<char> じゃないのか？
913:906
08/02/22 10:27:17
＞vector<vector<char> >
おｋ。
ファイルのロードとか要りますよね。
出来上がったクラスが標準だったり、ネットに転がってて欲しい。
914:デフォルトの名無しさん
08/02/22 10:40:03
クラス? 何を言ってるんだ? このスレがなんだか判っているか?
STLの使い方を提示されたんだから、後は自分で勝手に実装すればいいだろ。
915:デフォルトの名無しさん
08/02/22 10:46:03
だって普段STL使ってる人たちが、便利な標準クラス使ってるか自作クラスライブラリそろえてるに決まってるじゃん。
916:デフォルトの名無しさん
08/02/22 10:55:17
もうかまうなよ。
917:デフォルトの名無しさん
08/02/22 11:00:59
>>913
あのさ、先日からC++BuilderのVCLを移したいみたいだけどさ
STLはVCLと範疇が違うんだから、ファイルロードだのなんだのは
自分でやってくれるかな。
918:デフォルトの名無しさん
08/02/22 13:53:18
じゃ、せめて、
＞vector<vector<char> >
をカプセル化した便利なクラスだけでも教えてorz
919:デフォルトの名無しさん
08/02/22 13:54:32
そんなものないよ
920:デフォルトの名無しさん
08/02/22 13:57:18
そういえば、copiedはともかくfile_rangeくらいBoostにあってもいいのにって思う。
namespace oven = pstade::oven;
std::size_t n;
std::vector<std::vector<char> > v;
v.reserve(n);
for (std::size_t i = 0; i < n; ++i)
{
std::ifstream is(...);
v.push_back(oven::file_range<char>(...) | oven::copied);
}
921:デフォルトの名無しさん
08/02/22 14:00:54
どう見てもifstreamの行は消し忘れです、本当に(ry。
922:デフォルトの名無しさん
08/02/22 14:56:03
string::compareはありますが、大文字小文字を無視してcompareする場合は、皆さんどうされてるのでしょうか？
923:デフォルトの名無しさん
08/02/22 15:03:55
stricmp
924:デフォルトの名無しさん
08/02/22 15:06:51
文字列まわりはSTLに期待すんな、クソだ
925:デフォルトの名無しさん
08/02/22 15:12:43
そーなんですか。
構造体まわりはSTLで完璧ですが。
で、文字列まわりは何使えば良いですか？
ってstringしか無いじゃん。
あー、ハイパーなstringのソース落ちてないかなぁ。
926:デフォルトの名無しさん
08/02/22 15:17:24
構造体てｗ
927:デフォルトの名無しさん
08/02/22 15:18:47
あ、structもclassも等価らしいですが、
何もしないデータの塊にはstruct使ってます。
変ですか？
928:デフォルトの名無しさん
08/02/22 15:21:17
＞stricmp
試してみましたが、やっぱ、.c_str() 付けないとコンパイル通りませんね。
これくらい標準にして欲しいお。
929:デフォルトの名無しさん
08/02/22 15:36:00
春だなぁ
930:デフォルトの名無しさん
08/02/22 15:42:26
まだ冬ですよ
931:デフォルトの名無しさん
08/02/22 15:57:45
これがvipクオリティ
932:デフォルトの名無しさん
08/02/22 16:13:44
ファイルや文字列処理は微妙にスレ違いな気もするなぁ。
boostでよければboost.string_algoに色々あるしSTLにこだわる必要はないだろ。
boost.string_algoなら>>922はboost::algorithm::ilexicographical_compare。
ところでstricmp/strcmpiって標準だっけ？
933:デフォルトの名無しさん
08/02/22 16:49:51
std::string って、
==
で比較できましたっけ？
934:デフォルトの名無しさん
08/02/22 16:55:53
できる
935:デフォルトの名無しさん
08/02/22 17:53:15
>>932
stricmpもstrcmpiもstrcasecmpも標準Cには存在しない。
最近のPOSIXにはstrcasecmpがあるけど、locale依存なので
画面に表示する文字列をソートするくらいしか使い道がない。
936:デフォルトの名無しさん
08/02/22 18:08:08
>>935
なるほど。㌧
937:デフォルトの名無しさん
08/02/22 20:58:33
一瞬、初心者歓迎スレきたのかと思ったぜｗ
938:デフォルトの名無しさん
08/02/23 00:16:23
似たようなもんかもw
939:デフォルトの名無しさん
08/02/23 00:18:06
string って STL に含まれるの？
940:デフォルトの名無しさん
08/02/23 00:50:55
ど っ ち で も い い
強いて言うならC++標準。
つまんないことにこだわらんでも良いよ。
941:デフォルトの名無しさん
08/02/23 00:51:02
頻出ネタの上に面白くない議論にしかならないのでスルー
942:デフォルトの名無しさん
08/02/24 11:20:20
std::map<int, std::string> string_map;
assert(string_map[1].empry());
assert(string_map[100].empry());
assert(string_map.size() == 2);
つまり、存在しないキーを operator[] で指定すると
そのキーが自動的に挿入されて値はデフォルトコンストラクタ
で作成されてしまうということですか？
うむむ、例外になってくれればいいのだが。
std::vector でも operator[] は例外を出さないから
それに対応した動作ということなんでしょうか？