C++相談室 part143

■ このスレッドは過去ログ倉庫に格納されています
2019/06/15(土) 13:51:53.57ID:DKQ0QQLH0
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:15:19.28ID:mX2Zy9Do0
>>496
うん、天才様はそれでいいんだろうけど、凡人の世界では書いたコードは必ずテストして報告書を納品するものなんですよ
天才様は我々凡人のやり方とは合わないでしょうから、どうぞお一人で自分のためだけのコーディングを楽しんでください
未テストのクソコードを凡人世界に持ち込まないでくださいお願いします
2019/07/03(水) 18:16:15.13ID:Odxsa8jS0
プログラミングでテストが必要なのは、たとえば、過去に書いた何万行ものコード
を全部は思い出せないので、grep検索などで調査した結果にもと髄手後から機能追加
する時にミスが入り込んだり、ケアレスミスがあるからだ。

ところが、アルゴリズムのようなものは数学のようなもので、完全に正しいことが
天才には分かる。ところがここの人たちは凡才なので分からないから、いつまで
たっても証拠を見せろ、説明せよ、を連呼し続けてるだけだ。しかしそれは、
天才の結論が間違っていることにはならない。
2019/07/03(水) 18:16:39.18ID:NC+hYvon0
あれということは追加したときに足らんときって一時的に約3倍メモリくうのか
2019/07/03(水) 18:17:15.31ID:mX2Zy9Do0
凡人向け情報
ちょっと古いけど2倍とか1.5倍とか色々あるみたいよ
もちろんcapacity超えるサイズが必要になってから伸ばすけど
http://www.kmonos.net/wlog/111.html#_2334100705
2019/07/03(水) 18:18:05.72ID:Odxsa8jS0
>>499
勘違いなどしてない。勘違いだと思い込むのは、ここの人たちが凡人だからだよ。
2019/07/03(水) 18:20:25.23ID:qqPAz+Nsd
天才って普段どんなもの作ってるの？
2019/07/03(水) 18:20:28.94ID:Odxsa8jS0
>>500
数学とプログラミングのテストは異なるといってるんだ。
今回のは数学。プログラミングにテストが必要なのは>>501に書いたような
理由による。天才でも記憶力は有限なのでソースが大きくなると勘違いが
生じることが有ったり、ケアレスミスがあるのでテストは必須となる。
ところが、今回のような例ではテストも何もいらず、結論が見えてる。
2019/07/03(水) 18:22:29.45ID:mX2Zy9Do0
つまんね
自分を天才だと思いこむ狂人を演じる雑魚ってどんだけ殻被らないと自分を守れないの？
もうオモチャにする価値もないわNGします
2019/07/03(水) 18:23:43.51ID:Odxsa8jS0
>>507
思い込みではない。
2019/07/03(水) 18:26:07.57ID:NC+hYvon0
まずvectorはN個の要素を確保するときはN個分でふつうの配列と同じ分だけ確保する
要素追加時にキャパ足りない場合は配列の1.5とか2倍に増加する
この時ID:Odxsa8jS0のいうとおり2*Nとかになるときがあるという話ですね
2019/07/03(水) 18:29:57.28ID:Odxsa8jS0
>>509
最初に確保したまま、絶対に後から追加しないなら、固定長配列で十分だから、
2倍などになっていることの方が通常。ただし、2倍、2倍で増えていく場合でも、
平均のテーブルサイズは、要素数の1.5倍+(固定サイズの制御情報)となる。
2019/07/03(水) 18:30:24.41ID:mX2Zy9Do0
>>509
そうだね
キチガイが間違ってるのは末尾追加に備えて常に2*Nを確保するという主張
2019/07/03(水) 18:31:44.49ID:NC+hYvon0
>>510
指定の2倍とかになる開発環境あげてよ
2019/07/03(水) 18:33:16.53ID:mX2Zy9Do0
>>512
少なくともGCCとclangとVCとiccは違うよ
2019/07/03(水) 18:33:29.09ID:Odxsa8jS0
>>511
アホはだまっとれ。誰も2倍固定などとは思ってない。4倍でもなんでもいい。
とにかく、そのような「感じ」で増加していくということだけだ。「感じで」
といったのは数学的感覚に優れた秀才以上の人でなければ理解できなくて、
凡才には誤解を招くだろうが。
2019/07/03(水) 18:34:26.35ID:Odxsa8jS0
>>513
何度も行ってるが、それはテストの時にたまたまそうなっただけ。
2019/07/03(水) 18:36:00.16ID:NC+hYvon0
>>515
君のいうとおりになった環境とコードあげたら君の勝ちよ
2019/07/03(水) 18:37:25.69ID:Odxsa8jS0
>>516
数学というのはテストしなくても結果が分かるので、馬鹿馬鹿しいので探す
気になれない。天才の中での数学的確信というのはそれくらい強いものなんだ。
2019/07/03(水) 18:38:04.09ID:oDCSMM9SM
引くに引けないバカ
何が危険なのー
2019/07/03(水) 18:38:42.10ID:qqPAz+Nsd
天才様、ReactOSの開発を手伝って下さい。お願いします
2019/07/03(水) 18:39:36.54ID:Odxsa8jS0
>>518
お前みたいに何が危険なのか分からない人が出てくるのが、危険な理由の1つでも
あるんだよ。
2019/07/03(水) 18:42:33.07ID:NC+hYvon0
>>517
テストしなくても分かるなら探すまでもなく名前挙げれるでしょ
2019/07/03(水) 18:46:22.64ID:Odxsa8jS0
>>521
違う。絶対そういう仕組みで無ければ成らないことが分かるだけだ。
どの実装とかそんなものは関係ない。Mr.スポックでもグレイでも
ほぼそれしかできない。
2019/07/03(水) 18:46:23.12ID:qqPAz+Nsd
天才さーん！
2019/07/03(水) 18:48:44.79ID:Odxsa8jS0
>>522
まあ、この件に関しては、宇宙人レベルまで言うのは言い過ぎだったかもしれない。
ただ、現在人類がしている知識ではその程度のやり方しかない。
2019/07/03(水) 18:54:33.31ID:mX2Zy9Do0
キチガイ見えない状態で書いてるけどなんかほざいてるっぽいので
通りかかった初心者が勘違いしないように正しいこと書いておくね

std::vectorのpush_backが要求する計算量は「償却定数時間」で、これはざっくり言うと
たまに長い時間がかかるけどそれが稀なので、平均的には定数で抑えられるってこと
capacityいっぱいのvectorにpush_backをすると領域再確保してO(n)かかるけど、その頻度がnのオーダーより小さければ償却定数時間になる
2倍2倍で広げるってのはそういうこと（再確保の頻度がO(logn)になる）。2倍に限らず1.5倍とかでもいいしそれは実装次第

で、キチガイの主張は「push_backは定数時間！だからその保証のために追加先として始めから2倍の領域を確保してて効率悪いんだ(ﾄﾞﾔｧ…」だけど見ての通り大間違いね
capacityがいっぱいになってから再確保すれば償却定数時間には十分で、要素が追加されるかもわからない最初の段階でそんな事する必要はまったくない
当然ながら実際にGCCとclangとVCとiccは、例えば要素10個で構築されればcapacityを10にする常識的な実装をしている
追加量が読めていて、何度も2倍2倍で再確保するのが無駄な場合はcapacityをあらかじめ広げるreserve()という操作があるので、それを使えば効率的になる

蛇足だけど、キチガイの主張通り常に2倍の領域を確保したとしても、push_backの（償却でない）定数時間は達成できないことも指摘しておく
その2倍が埋まったら結局再配置はしないといけないわけだからね。キチガイ式の実装は再確保のタイミングをずらして、メモリを無駄にしつつ当初の目的も達成できないという
大変悪い見本です。真似しないようにしましょう

以上、長文失礼しました
2019/07/03(水) 18:55:40.74ID:oDCSMM9SM
>>520
おれは>>412を書いたものだが。
あんたは何も具体例書いてない。
2019/07/03(水) 18:56:24.16ID:Odxsa8jS0
>>525
アホ。お前が考えているようなことは最初から分かった上で言ってる。
変な言葉をひけらかしても関係ない。天才には知識が無くてもイマジネーション
だけで全てが分かる。
2019/07/03(水) 18:56:42.45ID:oDCSMM9SM
>>527
危険な具体例はよ
2019/07/03(水) 18:58:43.37ID:Odxsa8jS0
>>525 の勘違いは、「勉強しなければ分からない」と思っているところに有る。
天才は勉強しなくてもその場で考えれば自力で本に書いてあること同じ結論が
導ける。だから、言葉は分からない。ただ、同じアルゴリズムがひらめく。
そして全てが分かる。
2019/07/03(水) 19:01:31.61ID:TLK5eLSla
>>419のメモリ使用量でvectorよりlistが勝るというのも間違いだよね。
2019/07/03(水) 19:02:27.93ID:Odxsa8jS0
>>528
いくらでも有るから言わない。馬鹿馬鹿しいから。
少しは自分の頭で考えてみろ。
2019/07/03(水) 19:03:10.68ID:Odxsa8jS0
>>530
1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない。
2019/07/03(水) 19:06:30.93ID:oDCSMM9SM
>>531
だから書いてるじゃん
お前はいくらでもある例を一つも出してない。
そのくせメモリがーキャッシュがーとか最初の危険という趣旨のことばかり並べ立てる

馬鹿だろ
2019/07/03(水) 19:08:18.94ID:oDCSMM9SM
listはシーケンシャルアクセスでも異常に遅いけどな。
中間挿入の頻度がシーケンシャルアクセスよりも低い場合はdeque使ったほうが遥かにマシ。
2019/07/03(水) 19:10:00.22ID:JWWmhuhv0
>>532
やっぱりお前さんは阿呆か？
std::listは１要素に対して要素のデータとポインタ２個消費する。std::vectorはヘッダーとcapacity個の要素のデータだけだ。要素が多ければlistの方が不利。
2019/07/03(水) 19:10:08.72ID:Odxsa8jS0
>>533
それはコンテナの具体的実装によって危険な場合の書き方が変わってくるから、
数学的な才能だけがあってもSTLの個別具体的な勉強はしてない俺には語れないから
言わないだけだ。
2019/07/03(水) 19:10:43.15ID:Odxsa8jS0
>>535
小学生の算数からやり直して来い。
2019/07/03(水) 19:10:47.63ID:mX2Zy9Do0
std::listはメモリ局所性が低いので現代的なコンピュータだと遅いってのはよく言われてる
サイズが小さいと中間挿入でvectorに負けることさえある
2019/07/03(水) 19:12:59.20ID:Odxsa8jS0
>>538
局所性については考えて無かったよ。
でも>>535の主張は間違ってる。
2019/07/03(水) 19:13:32.58ID:mX2Zy9Do0
天才様のクソ実装だとvectorは要素数の2倍のcapacityを抱えてなければならないからlistよりでかくなるんだよ
天才様のクソ実装がいかにダメ実装なのかを示す実例なわけだ
2019/07/03(水) 19:16:07.25ID:uMmlAeoj0
今のコンピュータなんて100MB単位でメモリ食ったって構わんのだしメモリ効率なんてそこまで気にすることか？
気にしなきゃならん組み込みの開発ではSTLなんか使わんだろ
2019/07/03(水) 19:18:43.49ID:Odxsa8jS0
>>540
アホはだまっとれ。
2019/07/03(水) 19:18:47.59ID:sI4W8GZya
>>539
さっきからずっと小学生の喧嘩のような返ししかできてないけど、もしかしてリアルキッズ？

お前がどんなに自分を天才だと評価して事実天才だったとしても、周りからはただの興奮して引くに引けなくなったバカとしか見えてないよ。
天才アピールしてるし周囲にもそう認識して欲しいなら、それが実現できるように頑張りなよ。
2019/07/03(水) 19:20:09.54ID:Odxsa8jS0
>>543
そんなめんどくさいことしても、凡人以下のここの人には理解してもらえない。
2019/07/03(水) 19:21:13.51ID:Odxsa8jS0
まあ、せいぜい数年掛けて理解すればいい。
一生理解できない人も多いのかも知れんが。
そんな世話してられないし、知らん。
546デフォルトの名無しさん (ﾜｯﾁｮｲ)
垢版 |
2019/07/03(水) 19:23:47.88ID:CGn5f0Sh0
要素を挿入したときにイテレータが無効になってよいかどうかがlistを選択する基準で結論が出てるんですよ。
これ、欧米では20世紀に決着がついてるんです。
2019/07/03(水) 19:29:21.30ID:JWWmhuhv0
天才は明快な直感に導かれ、才能を実証する。秀才は歴史や書物に学び、凡人は愚鈍な考えや経験に頼る。
2019/07/03(水) 19:59:26.10ID:924EnmCA0
>>536
早く教えて何が危険かwwww
2019/07/03(水) 20:05:24.45ID:JWWmhuhv0
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).
となる。
2019/07/03(水) 20:11:03.35ID:JWWmhuhv0
>>549 訂正。(誤)サイズ → (正)メモリー消費量
2019/07/03(水) 20:17:55.39ID:JWWmhuhv0
>>549 この不等式は、トートロジーではない。
よって
>>419
>メモリ使用量という観点では、vectorよりもlistの方が優れる
というのは、常に正しいとは限らない。その点は、>>532 で軌道修正された。

>>532
>1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない
2019/07/03(水) 20:23:33.84ID:JWWmhuhv0
しかしこれは「小さいばあいは」の間違いだ。
2019/07/03(水) 20:48:16.58ID:y5Z0HSqrM
凄まじい勢いでスレ伸びてて草
久々に香ばしいのきたな
2019/07/03(水) 21:02:28.13ID:ZH/uFNI10
>>552
その間違いは致命的だろ
おかげで台無しになったんだぞ
2019/07/03(水) 21:20:13.81ID:JWWmhuhv0
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の方がメモリー消費量が少ない。
2019/07/03(水) 21:23:21.80ID:JWWmhuhv0
あれ？　dwMemoryLoadは、MemCheck1の方が小さいのか。。。
分からなくなってきた。。。
2019/07/03(水) 21:31:03.30ID:JWWmhuhv0
>確かにstd::listの方がメモリー消費量が少ない。

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

だから std::vectorの方が消費量が小さいということになる。
2019/07/03(水) 21:32:13.65ID:JWWmhuhv0
よって、自称天才君は敗北。はっはっは。
2019/07/03(水) 21:42:26.72ID:/a+dV4Ct0
180°正反対の間違いをしておいて他人を笑うとは。
2019/07/03(水) 21:55:07.11ID:JWWmhuhv0
中学レベルの問題が直感で分かるような自称天才は、問題を見るとすぐ答えがわかるから、自分が天才・神童だと思い込む。
しかし、複数の変数が絡む数式になると直感は外れるようになる。だから、考える努力をしない自称天才は高校くらいで落ちぶれる。
2019/07/03(水) 22:05:55.22ID:S/aBv8fE0
>>372
リスト・配列の特性、真ん中あたりの要素の削除の計算量などは、情報処理資格の内容にある

C++ は最高難易度の複雑さだから、さすがに資格を持っていない香具師は、門前払い！
2019/07/03(水) 22:07:27.64ID:Mf/6Ojwj0
>>559
まあよくあることだわ。
扱いには困るが。
2019/07/03(水) 22:11:09.39ID:MMRf6v9s0
std array使わないで生配列推奨する意味がわからない
2019/07/03(水) 22:26:30.32ID:S/aBv8fE0
どのようにプログラミングしても、vector には勝てない！
真ん中あたりの要素の追加・削除で、大量の要素がズレても、それでもvector が有利！

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

リストは、ランダムアクセスできない。
常に線形探索だから、O(n)
2019/07/03(水) 22:29:53.07ID:JvcEtzLy0
>>564
お前はRubyだけ弄ってればいいよ
2019/07/03(水) 22:30:37.31ID:U3PwexmG0
>>563
記述が少ない
2019/07/03(水) 22:32:11.35ID:JWWmhuhv0
allocaもいいぞ。
2019/07/03(水) 22:43:27.14ID:S/aBv8fE0
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.04ID:+l3ADsTnM
>>563
std::arrayはサイズで型変わるから
そこが面倒なこともある
2019/07/03(水) 23:06:06.02ID:Odxsa8jS0
>>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.45ID:MMRf6v9s0
bが1ですむ可能性があるとかw
2019/07/03(水) 23:18:47.11ID:+l3ADsTnM
vectorとかlistとか初心者向けの話題いつまでやんの？
まさにパーキンソンの凡俗法則だな
天才様が主導してるわけだがw
2019/07/03(水) 23:22:56.33ID:MMRf6v9s0
使用メモリって観点だと、realloc時は要素数の1+a倍だから、最悪値もそれになる
まあ、要素数の見積もりが全くできない状況でもaは容易に制御可能でcapacity見ながらreallocが起こる直前のpush_back前にreserveかけりゃ済む
最悪1要素ずつ拡張すればa~1
性能は最悪だがw
2019/07/03(水) 23:26:03.86ID:U3PwexmG0
参考書に答え書いてあるものを永久に語り続けるのおもろ
2019/07/03(水) 23:42:03.45ID:MMRf6v9s0
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.34ID:Odxsa8jS0
>>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 が大きい時には影響はなくなっていくから。
577デフォルトの名無しさん (ﾜｯﾁｮｲ)
垢版 |
2019/07/03(水) 23:43:59.85ID:Odxsa8jS0
>>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.32ID:U3PwexmG0
もういいってしょうもない話
2019/07/03(水) 23:45:33.05ID:MMRf6v9s0
数学得意とか言うわりに内容が中学生レベルなのをわざわざ説明するとか
2019/07/03(水) 23:45:34.35ID:Odxsa8jS0
>>576
誤：これらの関数は、どちらも n に対する1次関数で、
正：これらの関数は、どちらも x に対する1次関数で、
2019/07/03(水) 23:48:05.25ID:Odxsa8jS0
>>579
ここにいる人たちが、懇切丁寧に説明しないと分かってくれないからだよ。
2019/07/03(水) 23:50:03.60ID:U3PwexmG0
3行以下にできないなら説明しなくていいです・・・
2019/07/03(水) 23:53:56.60ID:MMRf6v9s0
メモリ容量が厳しいときにreserveしないなんてあり得ないし、Typeがでかく、要素数不明なときにそのままvectorに放り込むとかも普通しないよね

それこそスマポとか使ってでもlist使わない方がましな場合が殆んど
2019/07/03(水) 23:54:04.68ID:Odxsa8jS0
>>582
数学や科学の世界は、簡潔に説明なんか出来ないんだよ。
だから、簡潔を望む人は科学や数学には向いてない。
2019/07/03(水) 23:54:50.78ID:efP/7s/50
（自分が知っている部分だけ）懇切丁寧に説明しないと
＝知らない部分は無視して天才どうのこうので議論を拒否する

説明した部分に疑問持ってるレスどれ？
2019/07/03(水) 23:55:01.46ID:U3PwexmG0
ヒント：ここは5ch
2019/07/03(水) 23:58:40.02ID:MMRf6v9s0
大体が生配列とvectorの比較だったわけだが、なんで可変長でのメモリ使用でlistと比較しているんだ？

vectorじゃなく生配列使うべき有意な優位性を説明しろと
2019/07/03(水) 23:59:40.90ID:Odxsa8jS0
>>583
要素数と要素のサイズが大きいとき reserve()するのに時間がかかる。
昔から知られているが、リンクリストだとその手の作業が必要ないので、
速度とメモリの両方の効率がバランスが良い。
2019/07/04(木) 00:04:14.98ID:+bvr5vAX0
そもそも、最大限使えるメモリ容量から計算してreserveしておけば、listよりより多くの要素数格納できるんだな。

listの場合malloc的なものの管理領域も大きくなるってのも、メモリ厳しい場合には無視できない
2019/07/04(木) 00:04:37.74ID:BGPK0DtMM
>>560
行列がわからない自称上級者の蟻さん、ﾁｰｯｽ
2019/07/04(木) 00:05:06.10ID:OupeWpkE0
>>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.97ID:OMb74HbU0
listとvectorの違いなんて皆わかった上で議論しているのに天才さんはバカなの？
最近アルゴリズム入門書でも読んで語りたいだけなの？
2019/07/04(木) 00:08:18.15ID:OupeWpkE0
>>589
それもあるが、reserve()は時間がかかるので、扱うデータが巨大な場合には、
無駄が多くなるのと、reserve()するまでの最悪時には2倍の領域が必要となる事が
メモリ用件が厳しいときには問題となることも有る。
ただし、listにもデメリットは有る。それは、1要素を追加するときに new されるので、
典型的には150クロック程度の時間がかかってしまうことだ。
2019/07/04(木) 00:08:37.45ID:+bvr5vAX0
容量既知なら配列との差は管理領域とヒープが別になるオーバヘッドだけ

ヒープが別になるってのを責めて来るならまあ分かるが、容量既知なのに全くその情報使わない最悪値で比較とかセンス無さすぎ
2019/07/04(木) 00:10:31.88ID:OupeWpkE0
>>592
このスレの99%の人が分かってない。
2019/07/04(木) 00:11:56.58ID:+bvr5vAX0
size 0でのreserveは別に時間かからんだろ
それこそlistで要素追加でnewされるの1回分と大差ない
2019/07/04(木) 00:15:07.03ID:pXTZ8sNQ0
MATLABで演算するときforループを使って一つずつ計算するよりもsumやmeanなどの関数を行列に対して行う方が圧倒的に速いのですが
C++にもMATLABのように一括で高速に行う方法がありますか？
2019/07/04(木) 00:17:08.19ID:OupeWpkE0
>>593
なお、要素が、サイズが小さくて、かつコンストラクタを持たないような
単純なデータだとreserve()の時間が list の (150 * 要素数) (クロック)
よりも短いことも少なくて済む事もあるが、サイズが600バイトを超えたり、
要素の中に、newして持っているデータがあるような場合があったりする
場合や、要素のコンストラクタが重い作業を行うには、reserve()は、
listよりも遅くなる。

だから、要素が今後のプログラミングの過程でどんなものになるか分からない場合には、
listは安定した速度が維持できるが、vectorはだんだん遅くなっていく恐れが有る。
2019/07/04(木) 00:19:04.81ID:Evy1L2/hM
クロックとか言ってるやつもロートルだな
全く世の技術についていけてない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。