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/01(月) 10:02:33.15

これか
http://local.joelonsoftware.com/wiki/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 11:10:00.06

Ruby の女神・池澤あやかが言ってる

大学で、C言語を教えるから、ほとんどの人がプログラムを嫌いになる！
だから、Rubyから始めるべきだって！

YouTube に動画を上げてるKENTA も、初心者はRubyから始めるべきだって言ってる！

多言語やってる専門家は、皆、Rubyからって言う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 11:18:05.93

動いているプログラムそのものを記述できるC言語を理解できないとコンピュータサイエンスを修めたとは言えないでしょ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 11:58:55.18

俺もCから始めるべきだって思ってた
ま、俺自身はHSPやった後にCやったんだけど
最初スクリプト言語みたいなライトウェイトなやつやるべきだってのは正しいのかもね

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

実は、プログラミングに興味がある人は多くても、適性が余り無い人の方が多い。
だから、誰でも出来る言語の人気が高まる。それがスクリプト言語であり、
VBやC#だろう。多数決の投票では平易な言語が上位に来る。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 12:20:44.35

個人的にはC++は難しいのではなく面倒くさい言語だと思っている

**デフォルトの名無しさん** (ｽｯﾌﾟ) · 2019/07/01(月) 12:24:01.47

ポインタが理解できないなら参照も理解できないと思うんだけどな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 13:20:50.81

日本にはc言語ポインターだけを解説した本が有るじゃないか
自分はあれを読んで初めて
ポインターの何を理解出来ていないのかが解った
c言語は人間の認識的に誤りやすい書き方になっているのが問題
そういうのをシマンテッスク問題とか言うらしい

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2019/07/01(月) 13:42:23.56

アセンブリ言語を先に勉強すべきだんだよな
それだとメモリとそのアドレスを当たり前のように使うし
それこそがコンピュータなのだとわかる
そのあとで変数や参照はどう受け渡しされるのかを理解すればスムーズ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 15:06:31.19

問題はアセンブリを始めるには手頃なアセンブラが無いというところか？
手頃さで言ったらGASぐらいだと思うんだが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 15:17:48.47

>>343
ところが、
1. TYPE[10][10] aaa; は理解しやすくても、
2. TYPE aaa[10][10];
3. TYPE *aaa[10][10];
4. TYPE (*aaa)[10][10];

3, 4 となると意味不明になる人が多いらしい。また、典型的な例として、
2の場合に、aaa[5] の意味を理解できない人が多い。

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

>>344

多分それは、>>347 みたいな話で、優先順位を「ほどいて」理解できない人
が多いんだと思うが、実は、見た目と離れて、優先順位どおりに、
配列やポインタの記号を「直線化」するとそんなに難しい話ではないんだが、
数学の計算と同じようなことで、それが難しい人がいる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 15:24:39.60

>>342
実際にそういう人もいるが、自分が難しくて理解できないだけなのに、
言語設計に問題があるという風に捕らえる人もいる。そして多数決だと
圧倒的に後者のように感じる人が多くなってしまう。微分積分や
複素数、ベクトルはどれも美しい理論だが、理解できないために、
不要論が出てくるのと同じ。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/01(月) 15:39:49.57

言語設計は誉められたもんじゃないだろ
数学に例えられるレベルじゃない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 15:47:20.77

でもC/C++に変わるものが無いのが現実なんだよね
結局これがベター

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 16:34:31.14

>>350
でも、ポインタの書き方なんかはC設計者によるとても美しい設計とも言える部分。
言語設計が汚いのは、むしろ、C++に後から追加されてきた部分で、特に
最近に付け加えられてきた部分が誰かの言ったように「ハウルの動く城」的
になっている。

ところが、逆のことを言ってしまう人がいて、その人はポインタが理解できる
才能が無い人だと思う。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/01(月) 17:17:50.53

>>351
そりゃ他の言語はC++のクラスを手本にクラスの仕様を決めてるからな

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/01(月) 17:40:46.64

>>352
いや単にポインターまでの概念しか理解できない人だと思うよ
参照、右辺値参照辺りが理解できないで批判する人多い

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/01(月) 17:43:47.18

>>354
右辺値参照が理解できないのは分かるけど、単なる TYPE &aaa みたいな参照型
は、ポインタが理解しにくい人用に用意されたとも言われてる機能で、
ポインタが理解できたのにそれが理解できないとは考えにくい。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/01(月) 18:19:11.58

右辺値と左辺値で参照レベルが変わるのがややこしい原因だと思うけどね。
変数名aを左辺で使うとaという入れ物、右辺で使うとaの中身。
*bを左辺で使うとbの中身のアドレスが指し示す場所、
右辺で使うとbの中身が指してるアドレスの中に入ってる値。

参照レベルを変える演算子のない言語なら意識しないところだが。

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2019/07/01(月) 19:34:03.65

glvalue
rvalue
lvalue
xvalue
prvalue
入門者の皆さんはまず上記の違いを把握することから始めましょう！

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

そういうのしょうもないと思わないってのはほんとセンスないわ。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/01(月) 21:23:38.44

皮肉だろ
否定３つも使うな
お前は国語のセンスない

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

韻を踏んでるのかと思った

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ) · 2019/07/01(月) 21:40:34.52

♪そうゆうの～、しょ～もないって、思わないって、ほんとセンスないないさぁ～

作曲頼む

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

槇原敬之かよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 08:17:38.82

>>357
入門者はCを学んだ後、C++の class、メンバ関数、仮想関数、コンストラクタ、
デストラクタ、演算子のオーバーロード、継承、templateの基本などを学べば
C++の重要な部分は使えるので、xvalue、glvalue、prvalueなどは
すぐには分からなくてもいいと思う。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 08:29:28.55

便利そうに見えても、CやC++の基礎をすっ飛ばしてboostやSTLを学ぶのは
C++の本質が学べないので良くない。それらにも配列やリストなどがあって、
C#などの高級言語風に使えるので初心者は勘違いしてしまいがちだが、
それらは「動的」なものが多く、本来のC++の速度が出ない事がある。
もともとのC++は、静的な配列が基本なので、速度を上げたいなら、
静的な方で済む場合にはなるべく静的なものを使うべき。その基本を知らずに
STLだけを何の配慮も無く使っていたら、昔からのC++のような高速なアプリ
を作るのは困難。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 09:16:37.23

>>364
そんな考えだときりがない。
実測して時間かかってるところだけを改良したほうがいい
速度にほとんど影響しないところでも拘る、時間かかるはめになる。

2019/07/02(火) 09:47:27.28

std::arrayとかあるじゃん

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

たとえ動的な、vector を使っていても、それよりも速いコードを書けないw

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/02(火) 11:01:07.84

それCで良くねってなってSTLとか使うのがおかしいとか言ってくるようになるんだろ？
テンプレートなんか使うんじゃねえとか。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 13:50:47.02

>>368
そうはならない。C++とCの違いは、STLが使えるかどうかではなく、
class、コンストラクタ、デストラクタ、メンバ関数、仮想関数、
演算子の多重定義、template などが使えるかどうかだから。
STLは、言語ではなく、template library。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 13:52:51.90

Cにおいては、「標準ライブラリ」と呼ばれたライブラリは効率が良かったので
特殊な環境や黎明期以外では、それ以外を使う必要性は特になく、ほとんどの
場合それを使えば良いと考えられた。

ところが、STLはそういう設計にはなっていないことが多いので注意が必要だと
言っている。

2019/07/02(火) 14:21:08.67

で、STLのどの辺が具体的に効率悪いの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 15:28:23.54

>>371
Cの基本的な配列などを理解してない人は、コンピュータの動作の細かな仕組み
が分かってないので、挿入時間や末尾追加時間、参照のための時間などが
O(1)やO(N) などと言われてもちゃんと理解できないので、良く分からずに
単純なC風の配列で済むところを、vector などを使って遅くなったりしやすい。
array, vector, deque, list などを目的別に区別して使うためには、Cの配列や
ポインタが理解できないと難しいはずだ。どれもデータを集合させるためのもので、
速度やメモリの効率以外には余り違いは無いが、どういう違いがあるかはCや
アセンブラでの基礎が出来てなければ理解できしにくいと思われる。

たとえば構造体のメンバに配列データを入れる場合、サイズが固定である場合も
多いが、その場合には、文句なしに、TYPE aaa[16]; のような C流の配列で
十分。そこに vector を使ってしまう人がいて、それはかなり効率面で問題となる。
そのような場合には、std::array を使うのも避けるべきである。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 15:38:38.79

>>371
さらに、全ての場所でスマートポインター系を使おうとする人も出てきてしまうのも
問題点。

2019/07/02(火) 16:10:20.92

計算量と配列使うかvector使うかは別の問題なんだけど…
あとarrayの要件分かってる？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 16:14:23.02

>>374
あなたは分かってない。
だからこういう風になる一例。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 16:44:50.17

組み込みなんかだとvector始めSTL全部使えないとかあった
環境によっては標準ライブラリも全部使えないとかあったし
スタックサイズまで気にしなきゃいけないような組み込み系の話

2019/07/02(火) 16:50:12.65

>>375
arrayとｃの配列って速度一緒だろ

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

初めはSTLやフレームワークに依存した書き方で学んでも構わんと思うがね
そういうものが使えない環境で開発する人は、その時にそのための書き方を学べばいい

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 17:29:58.39

ヒープに確保するならstd::vectorが実用上ほぼ最速

2019/07/02(火) 17:45:38.13

ダメだこりゃ
もうちょっとマシな答え返ってくるかと思ったが

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

>>380
雑魚の癖にえらそうにすんな。
お前は生ポインタ怖くて使えないだけだろ。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:05:26.83

スマポはしゃーない
ライブラリがヒープに構築するオブジェクトを例外安全に使おうと思ったら使わんと

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:09:34.75

vecorというかSTLコンテナ全般だけど、push_back(void)みたいなデフォルトコンストラクタでの要素構築があればもっと良かった。
なんでないのかな。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:10:54.83

std::arrayでなく生配列を使うべき理由なんてC++03以前との相互運用性以外には一切ねえよクソ雑魚

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:11:09.91

vectorも然りで、例外時にちゃんと捨ててくれないと困るときにはnewなんかやってられんし。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:13:44.29

>>383
emplace_backを空で呼べばぁ？

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:14:56.47

ところで生ポ怖いとかそんなヌルい理由でSTL使うやつおるの？w
ポインタ覚えたてのボクちゃんがイキってはるように見えますね。

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 18:17:41.70

てか使わん理由がない
unique_ptrならオーバーヘッド0だろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:18:10.18

>>386
それでもmoveが発生するでしょ。美しくないw

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 18:19:02.38

>>389
moveは発生しないだろ？

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

ナマポは怖いよ
あれの不適切な取扱いのせいで数限りないバグとセキュリティホールが生まれて莫大な損害を生み出してる歴史に学ぶべきだ
そうなれば適切な取扱いを強制する仕組みをなるべく取り入れるのは至極当然のことだ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:23:26.11

>>390
MSVCとclangで試した範囲では、基本的にはスタック上に構築されたインスタンスをメモリコピーするアセンブリが生成される。
もちろん最適化で消えることもあるけど、全てというわけではない。
内部で確保されたメモリに対してplacement newで直接コンストラクタを呼び出すのと比べると若干のオーバーヘッドになる。

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 18:26:53.67

それコンパイラかオプション腐ってね？
moveが無駄ってのがemplaceの存在意義だろ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:30:07.12

>>393
emplaceはmoveコンストラクタを呼び出すための関数でしょ。
push_backだとcopyコンストラクタが呼ばれる。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:34:24.96

コンストラクタしか呼ばんよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:36:54.51

push_backにも右辺値参照取るオーバーロードがあるんだけど？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:37:04.80

emplace系（moveコンストラクタ）の利点は一時オブジェクトのデストラクタを呼ばなくて良いことであって、
メモリコピー自体は発生するよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/02(火) 18:41:38.86

すまん、おれが間違ってた、emplace_back(void)なんてものがあったんだなwwww

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/02(火) 18:42:45.57

ないない
アセンブリ出力なんか見なくても
各コンストラクタに自分の素性を出力させるようにしてテストすりゃあわかる。
emplace_backはコンストラクタしか呼ばない
ムーブやコピーなどの余計なコンストラクタは呼ばれない。
v.emplace_back(A())
なんてアホなことやってたら呼ばれるけどなw

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 18:45:36.48

てかplacement newさせるための機能だから

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

よくよく規格読むとemplace_backの要件のところでなぜかvectorに限って要素型にMoveInsertable要求してるな
(Table 88 - Optional sequence container operations)
vectorに限ってはID:z0GlqJ7U0の言う通りmoveするのかもしれんが何故だろう
アロケータ絡み？

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 19:20:16.00

それ、領域の再確保で既存要素をmoveする必要があるからじゃね

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

そうかと思ったんだけどdequeにはこの要求ないんよね

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/02(火) 19:40:57.73

dequeの場合、最初と最後に限っては既存要素の移動が必要ないからだろう

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

>>401
size()がcapacity()を超えた時ごっそり移すから

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

>>391
実際はナマポによる問題よりもスマポの取り扱いのわからんバカによる間違った使い方のが多いけどな。
重要なのは言語による強制じゃなくて、教育だわ。
そこのコストを無駄にケチるバカ企業はどんな言語使っても無駄。

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/02(火) 23:11:40.30

なんかその間違えた使い方一覧とか見てみたくなるな

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

>>406
結局、生ポインタや生配列も必ず必要になるから、仕組みを理解せずに使えば
コンテナやスマートポインターの方こそが危険の原因になるのは容易に想像できる。
結局、実装の詳細を知らなければ危険なので、初心者向けでない。

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

>>408
生ポインタや生配列をコンテナやスマートポインターに置き換えて危険の原因になる例おしえて。

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

>>408
俺も教えて欲しい。何が危険なの？

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

こうやって具体例も出さずに古い知識と気分と思い込みでコンテナやスマポを意味なく禁止してナマポや生配列を強要する老害が一番危険

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

生ポ受け取って処理して返す関数の中で
受け取った生ポをユニポに入れてしまって
関数から抜けるときに消えちゃうバカとか？

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

それは生ポの危険性やん

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

>>409
全部置き換えることは出来ないから。

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

なんだキチガイか

2019/07/03(水) 07:58:15.56

コンテナなりで確保して必要なときにポインタで渡すだけだろ

2019/07/03(水) 08:21:07.41

結局このての老害が居座ってるのがこの言語の一番の欠点だわ
下手にC言語と互換性があるから頭の悪いナマポおじさんが初心者に間違った知識を広げていくという

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

>>379
vector で、TYPE型のオブジェクトを N 個収める場合、通常は、
2 * N * sizeof(TYPE) + (制御情報)
程度のバイト数が必要になる。一方、Cの生配列の場合、
N * sizeof(TYPE)
で済む。重要なのは、必要メモリに2倍もの開きがあるということ。
つまり、配列なら10MB で済むところが、vector だと20MB必要になる。

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

メモリ使用量という観点では、vectorよりもlistの方が優れる。
vectorは、メモリを2倍使用することで末尾追加の時間をO(1)に抑えているだけ。
固定長で済む場合はCの生配列を使うべき。
サイズを徐々に大きくしていくようなばあいは、vectorよりもlistの方が良い場合が
多い。ただし、listはランダムアクセスには向いてないが。

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

なお、TYPE のサイズが大きい場合に vectorを使うと、Core i7 でも Celeron 並み
にCPUキャッシュメモリが減ったかのようになり、せっかくのハイエンドなパソコンが
エントリーモデルのパソコン並みの速度になってしまうかも知れない。

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

生配列かvectorかlistかって論点古すぎ
今c++の複雑さはそういうとこじゃないから
他の言語含めてもうちょっと勉強しろ

2019/07/03(水) 09:15:31.03

明らかにC++03時代の入門見て覚えた知識を頑張って披露してます状態だな
勉強足りなすぎ

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

typeのサイズが大きい場合に生配列使うとそれはそれで問題にならん？

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

>>421 >>422
雑魚は黙っててくれ。レベルの低い人は自分がレベルが低いことに気が付かない。
このままだと日本のITは壊滅的なままだから。

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

>>424
はいはい雑魚雑魚
boostのstatic_vectorって調べてみな
生配列とvectorのいいとこどりのコンテナだ
eastlにも似たようなのあったはず
おれも大概おっさんでc++にネガティブな思いはある
だけどお前みたいな老害にはなりたくないな

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

>>425
static_vector みたいなアホみたいなものを持ち出して。
黙ってろよ馬鹿は。
想像力が足りない人が既にあるものをいくら勉強だけしても駄目なんだよ。

2019/07/03(水) 10:02:15.82

約2倍使うのって追加するときに内部のサイズが足らん場合だけだろ
後別に遅くないがな

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

基礎をすっとばすのが良くないというのは同意だわ
C++はスクリプト言語の代わりにはなれない

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/03(水) 10:41:14.59

>>418
その*2はどこから出てきたんだ？
生で10MBでサイズ既知なら、vectorでも10MB+固定サイズ制御情報にしかならんだろ

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

そんな細けーこと気にするならデフォのnewやmalloc使ってたら笑うぞ

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

>>429
vectorは構造上はリンクリストではなく、Cの生配列と全く同じ形式で
要素を単純な配列として持っているが、最初に最大要素数を指定しなくても
後から動的に要素数を増やす機能も持っている。この機能の実現の際、もし、
今入っている要素数とぴったり同じだけの個数が入る配列でデータを持っているだけだと、
1個ずつ末尾追加したときに、毎回、今までと同じ大きさの新しい配列を new し、
古い配列のN個の要素を全て新しい配列にコピーする動作をしなくてはならず
とても時間がかかってしまう。それを防ぐために、原則的には今入っている
要素の2倍の配列を内部的に持つことにされている。そうすることによって、
要素数が2倍に到達するまでは、末尾追加しても今言った「new してから全てコピーする動作」
をしなくて済むようになる。そのために、必要メモリが生配列の二倍必要になっているらしい。

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

最悪の場合を言ってるのだろう
平均で見なきゃ意味ない
そんなこと言ったらクイックソートだって

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

そもそも好きに使って経験を積みゃいいんだし手法を統一する必要もない

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

>>432
最悪で2倍、平均だと 1.5倍。

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

なら許容範囲だね！！よかったよかった

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

shrink_to_fitでも使えや

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

>>435
CPUの内部キャッシュは、ハイエンド機種でも8MB程度しかないので、
むやみにメモリを使った場合の速度低下は著しい。