C++相談室 part143

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/15(土) 13:51:53.57

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part142
https://mevius.5ch.net/test/read.cgi/tech/1554124625/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 18:58:43.37

>>525 の勘違いは、「勉強しなければ分からない」と思っているところに有る。
天才は勉強しなくてもその場で考えれば自力で本に書いてあること同じ結論が
導ける。だから、言葉は分からない。ただ、同じアルゴリズムがひらめく。
そして全てが分かる。

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/03(水) 19:01:31.61

>>419のメモリ使用量でvectorよりlistが勝るというのも間違いだよね。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:02:27.93

>>528
いくらでも有るから言わない。馬鹿馬鹿しいから。
少しは自分の頭で考えてみろ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:03:10.68

>>530
1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 19:06:30.93

>>531
だから書いてるじゃん
お前はいくらでもある例を一つも出してない。
そのくせメモリがーキャッシュがーとか最初の危険という趣旨のことばかり並べ立てる

馬鹿だろ

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 19:08:18.94

listはシーケンシャルアクセスでも異常に遅いけどな。
中間挿入の頻度がシーケンシャルアクセスよりも低い場合はdeque使ったほうが遥かにマシ。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:10:00.22

>>532
やっぱりお前さんは阿呆か？
std::listは１要素に対して要素のデータとポインタ２個消費する。std::vectorはヘッダーとcapacity個の要素のデータだけだ。要素が多ければlistの方が不利。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:10:08.72

>>533
それはコンテナの具体的実装によって危険な場合の書き方が変わってくるから、
数学的な才能だけがあってもSTLの個別具体的な勉強はしてない俺には語れないから
言わないだけだ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:10:43.15

>>535
小学生の算数からやり直して来い。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:10:47.63

std::listはメモリ局所性が低いので現代的なコンピュータだと遅いってのはよく言われてる
サイズが小さいと中間挿入でvectorに負けることさえある

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:12:59.20

>>538
局所性については考えて無かったよ。
でも>>535の主張は間違ってる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:13:32.58

天才様のクソ実装だとvectorは要素数の2倍のcapacityを抱えてなければならないからlistよりでかくなるんだよ
天才様のクソ実装がいかにダメ実装なのかを示す実例なわけだ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:16:07.25

今のコンピュータなんて100MB単位でメモリ食ったって構わんのだしメモリ効率なんてそこまで気にすることか？
気にしなきゃならん組み込みの開発ではSTLなんか使わんだろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:18:43.49

>>540
アホはだまっとれ。

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/03(水) 19:18:47.59

>>539
さっきからずっと小学生の喧嘩のような返ししかできてないけど、もしかしてリアルキッズ？

お前がどんなに自分を天才だと評価して事実天才だったとしても、周りからはただの興奮して引くに引けなくなったバカとしか見えてないよ。
天才アピールしてるし周囲にもそう認識して欲しいなら、それが実現できるように頑張りなよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:20:09.54

>>543
そんなめんどくさいことしても、凡人以下のここの人には理解してもらえない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:21:13.51

まあ、せいぜい数年掛けて理解すればいい。
一生理解できない人も多いのかも知れんが。
そんな世話してられないし、知らん。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:23:47.88

要素を挿入したときにイテレータが無効になってよいかどうかがlistを選択する基準で結論が出てるんですよ。
これ、欧米では20世紀に決着がついてるんです。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:29:21.30

天才は明快な直感に導かれ、才能を実証する。秀才は歴史や書物に学び、凡人は愚鈍な考えや経験に頼る。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 19:59:26.10

>>536
早く教えて何が危険かwwww

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 20:05:24.45

std::listは、連結リストである。rbeginとrendを持っているから、逆方向にも走査できる二重連結リストである。二重連結リストは、1個の要素に対して要素データと2個のポインタを消費する。
要素データのサイズをEとし、1個のポインタのサイズをPとすると、std::listが1個の要素に対して消費するメモリーサイズは、(E + P * 2)バイトとなる。
要素数やルートポインタを含むヘッダ情報のサイズをH1とし、n個の要素があるとすると、合計 H1 + n * (E + P * 2) バイトとなる。

std::vectorは、動的配列であり、要素の個数や要素を格納する連続データへのポインタなどを含むヘッダ情報を持っている。
ヘッダ情報のサイズをH2とする。capacityの個数が実際の要素の1.5倍だと仮定すると、(H2 + n * E * 1.5)となる。

listよりvectorの方がサイズが小さいと仮定すると、
H1 + n * (E + P * 2) > H2 + n * E * 1.5.
n * (E + P * 2 - E * 1.5) > H2 - H1.
n * (P * 2 - E * 0.5) > H2 - H1.
n > (H2 - H1) / (P * 2 - E * 0.5).
となる。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 20:11:03.35

>>549 訂正。(誤)サイズ → (正)メモリー消費量

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 20:17:55.39

>>549 この不等式は、トートロジーではない。
よって
>>419
>メモリ使用量という観点では、vectorよりもlistの方が優れる
というのは、常に正しいとは限らない。その点は、>>532 で軌道修正された。

>>532
>1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 20:23:33.84

しかしこれは「小さいばあいは」の間違いだ。

2019/07/03(水) 20:48:16.58

凄まじい勢いでスレ伸びてて草
久々に香ばしいのきたな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:02:28.13

>>552
その間違いは致命的だろ
おかげで台無しになったんだぞ

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:20:13.81

Borland C++ 5.5.1でGlobalMemoryStatusテスト。

MemCheck1.cpp (std::vector<DWORDLONG>)
https://gist.github.com/katahiromz/b4f73c25a92f60b1b40b544a3b0474e1
4170416128

MemCheck2.cpp (std::list<DWORDLONG>)
https://gist.github.com/katahiromz/b460644fc9ca5202e7ffc017b9a1dfa2
4031049728

要素の個数は0xFFFFFF個。確かにstd::listの方がメモリー消費量が少ない。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:23:21.80

あれ？　dwMemoryLoadは、MemCheck1の方が小さいのか。。。
分からなくなってきた。。。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:31:03.30

>確かにstd::listの方がメモリー消費量が少ない。

これは間違い。Availが少ない → 消費量が多い

だから std::vectorの方が消費量が小さいということになる。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:32:13.65

よって、自称天才君は敗北。はっはっは。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:42:26.72

180°正反対の間違いをしておいて他人を笑うとは。

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:55:07.11

中学レベルの問題が直感で分かるような自称天才は、問題を見るとすぐ答えがわかるから、自分が天才・神童だと思い込む。
しかし、複数の変数が絡む数式になると直感は外れるようになる。だから、考える努力をしない自称天才は高校くらいで落ちぶれる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:05:55.22

>>372
リスト・配列の特性、真ん中あたりの要素の削除の計算量などは、情報処理資格の内容にある

C++ は最高難易度の複雑さだから、さすがに資格を持っていない香具師は、門前払い！

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:07:27.64

>>559
まあよくあることだわ。
扱いには困るが。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:11:09.39

std array使わないで生配列推奨する意味がわからない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:26:30.32

どのようにプログラミングしても、vector には勝てない！
真ん中あたりの要素の追加・削除で、大量の要素がズレても、それでもvector が有利！

だから素人は、vector を使っておけばよい

リストは、ランダムアクセスできない。
常に線形探索だから、O(n)

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:29:53.07

>>564
お前はRubyだけ弄ってればいいよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:30:37.31

>>563
記述が少ない

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:32:11.35

allocaもいいぞ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:43:27.14

Rubyのしくみ、2014
Rubyの実装系、Ruby1.9のRuby仮想マシンの本に書いてあるけど、

Rubyでは、Hashの要素数が増えていくと、再編成される

バケット数は、2の累乗付近の素数を使う。
つまり、倍々に増やしていく
8+3, 16+3, 32+5, 64+3, 128+3, 256+27, 512+9...

1つのバケットには、平均して5つの要素を入れる(衝突)。
11*5=55, 19*5=95, 37*5=185...

つまり要素数が、56, 96, 186...個になると、
バケット数を増やして、再編成する

普段、1万個の要素を追加するのに、8msかかるが、
再編成するタイミングでは、20msかかる。
要素数が増えていけば、もっとかかる

10万個なら200ms、100万個なら2秒と、再編成があるたび、ドンドン増えていく

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 22:47:35.04

>>563
std::arrayはサイズで型変わるから
そこが面倒なこともある

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:06:06.02

>>558
違う。
vector は、最悪、a*N*sizeof(TYPE) + (制御情報サイズ) だ。
listは、常に、N * ( sizeof(TYPE) + ポインタサイズ * b ) + (制御情報サイズ) だ。
aは、実装依存で、典型的には2。vectorを確保した直後を除いて1であることはない。
b は、1または2。

あなたのやったテストでは、vector を確保した直後だから、a=1になっていただけ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:08:20.45

bが1ですむ可能性があるとかw

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 23:18:47.11

vectorとかlistとか初心者向けの話題いつまでやんの？
まさにパーキンソンの凡俗法則だな
天才様が主導してるわけだがw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:22:56.33

使用メモリって観点だと、realloc時は要素数の1+a倍だから、最悪値もそれになる
まあ、要素数の見積もりが全くできない状況でもaは容易に制御可能でcapacity見ながらreallocが起こる直前のpush_back前にreserveかけりゃ済む
最悪1要素ずつ拡張すればa~1
性能は最悪だがw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:26:03.86

参考書に答え書いてあるものを永久に語り続けるのおもろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:42:03.45

std::list<std::string> lines;
std::string l;
while(std::getline(std::cin,l)){
lines.push_back(l); //(1)
//lines.push_back(std::move(l)); //(2)
}
だと(1)の方がいいよね
特に行内の文字数、行数が大きくなると速度差はかなり大きくなる。
stringじゃなく同様のvectorでも同じ
listだと(2)が速いだろうけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:42:46.34

>>549
あなたの誘導に沿って説明しよう。
要素の型をTYPEとすると、要素の1つのバイト数を、E=sizeof(TYPE)であり、
それが、x 個ある場合を考える。
L(x) = H1 + x * (E + P * 2)　　// list に必要なバイト数
V(x) = H2 + x * E * 1.5　　　　// vector に必要なバイト数
となっている。
P は、ポインタ1つ当りのバイト数であり、Windows の 32BIT モードの時は、4 である。

これらの関数は、どちらも n に対する1次関数で、
グラフにすると、傾きはそれぞれ、
a_L = E + P * 2　　　// list の必要バイト数の傾き
　　= E + 8
a_V = 1.5 * E　　　　// vector の必要バイト数の傾き
だ。

要素1つ辺りのサイズ E が十分大きい場合、たとえば、100バイトの時を考えれば、

a_L = 100 + 8 = 108
a_V = 1.5 * 100 = 150

となる。

だから、V(x)の傾きの方が、L(x) の傾きのよりも大きい。
だから明らかに V(x) の方が効率が悪い事になる。H1, H2 がどんな
値であれ、要素数 x が十分大きい場合にはメモリ効率の良さは
xに対するグラフの傾きで決まる。H1, H2 は、いわゆる「y切片」
を決めるだけで、x が大きい時には影響はなくなっていくから。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:43:59.85

>>576
[続き]
>>549 の最後の方は：

『listよりvectorの方がサイズが小さい』・・・・☆
と同値な条件は、
H1 + n * (E + P * 2) > H2 + n * E * 1.5　　・・・・(1)
⇔
n * (P * 2 - E * 0.5) > H2 - H1　　・・・・(2)

である、というところまでは正しい。ところが、中学校で習ったように、
不等式では、両辺を負の数で割るると、不等号の向きが逆になってしまう。
だから、割る数が正か負かを気をつけないといけない。
今、E = 100, P = 4 だから、
(P * 2 - E * 0.5) = 4 * 2 - 100 * 0.5 = 8 - 50 = -42
となり、負の値である。E が1000や10000の場合は、どちらも
もっと絶対値の大きな負の値となる。だから、この部分は要素のサイズ
が十分大きいと必ず負の値である。ゆえに、(2) をこの数で割ると、
n < (H2 - H1) / (P * 2 - E * 0.5)　　・・・・(3)
となり、あなたの書いた式とは不等号の向きが逆となる。

さて、この(3)の意味は、右辺の値は、Eの値が100の場合は、分母は負の値であるが、
分子の H2-H1 の値は実装依存なので、右辺全体としては、正か負かも定まらない。
そこで、右辺の値を R とおくと、n < R という式になる。
この意味は、ある値 R よりも要素数 n が小さいと、この式が成立する、
ということである。この式は、あなたが書いたように、
☆と同値な式である。だから、ある値 R よりも要素数 n が小さいと、
☆が成立することを意味している。つまり、要素数が十分小さいときに
のみ「list より vector のサイズが小さい」のである。逆に、
要素数が十分大きければ、「list より vector のサイズが大きい」
ことが言える。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:44:44.32

もういいってしょうもない話

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:45:33.05

数学得意とか言うわりに内容が中学生レベルなのをわざわざ説明するとか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:45:34.35

>>576
誤：これらの関数は、どちらも n に対する1次関数で、
正：これらの関数は、どちらも x に対する1次関数で、

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:48:05.25

>>579
ここにいる人たちが、懇切丁寧に説明しないと分かってくれないからだよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:50:03.60

3行以下にできないなら説明しなくていいです・・・

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:53:56.60

メモリ容量が厳しいときにreserveしないなんてあり得ないし、Typeがでかく、要素数不明なときにそのままvectorに放り込むとかも普通しないよね

それこそスマポとか使ってでもlist使わない方がましな場合が殆んど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:54:04.68

>>582
数学や科学の世界は、簡潔に説明なんか出来ないんだよ。
だから、簡潔を望む人は科学や数学には向いてない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:54:50.78

（自分が知っている部分だけ）懇切丁寧に説明しないと
＝知らない部分は無視して天才どうのこうので議論を拒否する

説明した部分に疑問持ってるレスどれ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:55:01.46

ヒント：ここは5ch

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:58:40.02

大体が生配列とvectorの比較だったわけだが、なんで可変長でのメモリ使用でlistと比較しているんだ？

vectorじゃなく生配列使うべき有意な優位性を説明しろと

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:59:40.90

>>583
要素数と要素のサイズが大きいとき reserve()するのに時間がかかる。
昔から知られているが、リンクリストだとその手の作業が必要ないので、
速度とメモリの両方の効率がバランスが良い。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:04:14.98

そもそも、最大限使えるメモリ容量から計算してreserveしておけば、listよりより多くの要素数格納できるんだな。

listの場合malloc的なものの管理領域も大きくなるってのも、メモリ厳しい場合には無視できない

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:04:37.74

>>560
行列がわからない自称上級者の蟻さん、ﾁｰｯｽ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:05:06.10

>>587
生配列に必要なバイト数：
A(x)=E * x
vector に必要なバイト数
V1(x) = H2 + 1.5 * E * x　　　// 平均時
V2(x) = H2 + 2 * E * x　　　　// 最悪時

これらをみるだけでも、生配列の方が効率がいい事が分かる。
要素を書き込む時にも、生配列は典型的には1クロック。
vectorだと、境界チェックが入るので5クロックくらいは必要となる。
境界チェックは条件 jump なので、パイプライン類の乱れが生じ
だいぶ遅くなることが有る。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:05:27.97

listとvectorの違いなんて皆わかった上で議論しているのに天才さんはバカなの？
最近アルゴリズム入門書でも読んで語りたいだけなの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:08:18.15

>>589
それもあるが、reserve()は時間がかかるので、扱うデータが巨大な場合には、
無駄が多くなるのと、reserve()するまでの最悪時には2倍の領域が必要となる事が
メモリ用件が厳しいときには問題となることも有る。
ただし、listにもデメリットは有る。それは、1要素を追加するときに new されるので、
典型的には150クロック程度の時間がかかってしまうことだ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:08:37.45

容量既知なら配列との差は管理領域とヒープが別になるオーバヘッドだけ

ヒープが別になるってのを責めて来るならまあ分かるが、容量既知なのに全くその情報使わない最悪値で比較とかセンス無さすぎ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:10:31.88

>>592
このスレの99%の人が分かってない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:11:56.58

size 0でのreserveは別に時間かからんだろ
それこそlistで要素追加でnewされるの1回分と大差ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:15:07.03

MATLABで演算するときforループを使って一つずつ計算するよりもsumやmeanなどの関数を行列に対して行う方が圧倒的に速いのですが
C++にもMATLABのように一括で高速に行う方法がありますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:17:08.19

>>593
なお、要素が、サイズが小さくて、かつコンストラクタを持たないような
単純なデータだとreserve()の時間が list の (150 * 要素数) (クロック)
よりも短いことも少なくて済む事もあるが、サイズが600バイトを超えたり、
要素の中に、newして持っているデータがあるような場合があったりする
場合や、要素のコンストラクタが重い作業を行うには、reserve()は、
listよりも遅くなる。

だから、要素が今後のプログラミングの過程でどんなものになるか分からない場合には、
listは安定した速度が維持できるが、vectorはだんだん遅くなっていく恐れが有る。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:19:04.81

クロックとか言ってるやつもロートルだな
全く世の技術についていけてない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:19:14.34

>>597
ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:19:40.29

>>596
「>>598」にも書いたが、要素のサイズが大きい場合や、要素のコンストラクタの
重い場合には、reserve()はとても遅くなる。要素のコンストラクタの中で
メンバの確保やコピーのためにnewが1つでも行われる場合には、listよりもほぼ必ず
遅くなる。コンストラクタ内のnewがN個だとlistのN倍遅くなる。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:21:13.94

ハイパフォーマンス必要なとこでlistなんか使わないからど素人さん

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:25:40.63

>>601
それに、reserve()のためには、一般的には、要素は、コピー・コンストラクタを
持つ必要がある。一方、listの場合には、コピ・コンを省略できる。
C++を使っていると分かるが、デフォルト・コンストラクタを作ることはほぼ必須
だが、コピ・コンはめんどくさいので書きたくないことが多い。その場合に、
listの方が楽。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:26:45.21

>>602
vectorとreserve()の組み合わせはもっと駄目だ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:27:30.60

forward_list
とか知らないんだろうな
バカそうだし

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:31:07.37

>>601
要素既知の配列と同様の用途の場合、まともなスキルのあるプログラマなら、サイズ指定constructor、empty状態でのresize、empty状態でのreserve
のいずれかを使う。
そうするとmalloc一回と、前者二つは要素数分の要素型の配置newデフォルトもしくはコピーconstructorが呼ばれる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:31:14.53

>>604
お前の頭中、vectorかlistしかないのなw
もとの生ポ押しはどうしたの？w

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:36:08.58

vector相当にcapaciry()+xなreserve相当をするCArrayってのがあってだな
MS自身がどうしてもこれじゃなきゃ駄目な場合以外使うなと言うくらいの糞

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:36:47.68

>>606
要素数既知なら、最速が TYPE aaa[N] で次が new TYPE[N]。
逢えて vector を使う意味がない。

empty状態の reserve() とかしてまで vector にこだわる意味が分からない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:38:37.52

>>607
むしろ逆で、生配列使えばいい場面で、何故か vector に固執する人がいるんだよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:39:15.33

どこにそんな人居たの？
レス番あげてよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:48:01.35

サイズ完全固定ならstd::array
最大サイズが既知なら少し無駄だがvector
格納領域内包する最大サイズ指定のvector擬きがあればベストなんだが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:51:39.87

後はサイズが大きくてスタック上に確保したくない時もvector使うだろ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:53:59.44

>>613
その場合は、TYPE *pAaa = new TYPE[N];

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:56:53.06

まだやってるのかw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:00:33.98

>>614
それ最悪
例外安全性放棄ほぼ確定

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:02:18.21

自称天才すげーな
自分が何かいてるのか分かってないんだろうな
規格も読んでなさそう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:05:54.39

>>614
てか今時こんなコード書く奴いたら、できうる限り関り合いにならないようにするね。

こんなのが先輩面して新人に教育してたらもう最悪

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:21:19.34

>>618
あなたは、C++とC#の速度が変わらないと思ってる系統の人だよね。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:21:50.22

>>597
ベクトル演算とか、並列処理とか

OpenCL, CUDA とか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:52:09.26

shared_array はまだ標準化されてないんだね。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:32:03.47

たぶんこのおっさん例外安全って何かわかってないw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:56:32.67

>>622
std::array を使うと例外安全が確保されて、
TYPE *pArr = new TYPE[N];
だと確保されないと思うのはなぜ？

絶対に確保できないと言い切れる根拠でもあるの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:58:14.89

>>623
誰がヒープ回収するねん...

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:00:26.38

とりあえずnewとかmake_sharedとかIDEがなくても型が明らかな場合はauto使おう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:00:52.24

>>624
「ヒープを回収する」
とはどういう意味か分からない。

メモリ確保の失敗は大体回復不可能なはずなんだけど、どうするつもりなの。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:01:53.76

「メモリ確保に失敗したこと」のメッセージを出す以外に対処法はないと
思うんだけど。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:16:52.36

なんでnewで例外起こる話しているんだか
本当に全くわかっていないのね