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/06/30(日) 14:31:31.86

>>296
貴様、パイソニアンだな。

ずしゃんずしゃん。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/06/30(日) 15:34:49.82

みんなC++がここまで残ることになるとは予想してた？
このままだとC++30とか40とか普通に来そう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:01:24.12

OSを除けば基礎的なソフトはだいたいC++でしょ
ふつーに重要言語の1つ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:06:12.25

C++11以降標準のフットワークが軽くなってありがたい
その代わり要るんかこれ？みたいのもガンガン入ってくるけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:09:27.02

>OSを除けば基礎的なソフトはだいたいC++でしょ
docker, kubeはgolangだが？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:09:52.38

ちなみにgitはc

**デフォルトの名無しさん** (ﾗｸｯﾍﾟ) · 2019/06/30(日) 16:10:56.10

>>303
開発者があいつだからだろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:37:46.54

golangが増えてきたね
Cを置き換える感じになりそう
言語仕様もCとPython混ぜたような言語だし

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:42:10.94

c++が使われるとこってのはゲーム、ブラウザ、windows, MSoffice
とか、GUIでかつ計算資源どっかり使うようなプログラムだわ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 16:59:55.50

確かにVC++はMFCが使えるからGUI向きだな！

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 18:33:30.39

clang, llvm, jdk, .net core, chrome,ほとんどのゲームエンジン
この辺C++
他の主要ブラウザも大体C++のはず

dockerはgoで書かれたせいで性能が悪いって言ってる記事を読んだ事がある

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 18:34:08.60

goの性能はjavaより悪い
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 18:40:59.64

要するにC++は「ソースコードが大規模かつ性能がシビアに要求される」場面で使われる。
開発効率はJavaより悪い事が実証されてたはず。
なんかの研究論文もあったし多くの開発者の経験談もある。
だから開発効率を多少悪化させてでも性能を求める場合に使われる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 18:45:18.35

使える人揃えるの大変なんだよ
Rustの導入談とか見ると、
性能に問題があって他言語導入を検討したがC++は使える人がいないのでRustにしましたとか書いてあるし

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 19:27:38.00

マジで？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 19:34:56.51

そもそもポインタが理解できる人が、アメリカの大学の理系の学生でもほとんどいないという話がある。
だから、C++が悪い言語というより、C++がある種の数学みたいに難しすぎて理解できない人が多いので
Javaなんかが必要になったらしい。

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2019/06/30(日) 19:49:13.48

Rustはポインタ理解でない人が使える言語ではない気がする

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 19:56:47.32

ポインタが理解できるとかそういう問題じゃねーわ。
むしろ「〜の概念が理解できる」てだけでドヤって
まともなプログラム書けると思い込むバカが問題なんだわ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 19:57:51.51

ポインタすら理解できない人にプログラミングは難しすぎないか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:16:06.58

>>313はただのデマだろう
ポインタが理解できないなんてことはありえない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:16:57.22

C++がある種の数学ってなんだよ
この板最近一人おかしな作り話書き込み続けてるやつがいるよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:17:37.05

包丁使えない人に料理は難しすぎないか？みたいな話だな。
包丁使えなくてもハサミ使えば料理できるでしょ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:19:17.74

リファクタリング中毒言語
勉強すればするほど書き直したくなる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:21:38.63

なんだろうな
中学生とかかな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 20:57:12.06

どんな書き方しても新しい規格は出てくるわけで、
そこで古い書き方だからとかいちいち引っかかる奴はc++は向いてない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 21:18:32.10

RustスレなのにC++の話で申し訳ないが、この前
　template<class T, class U> void tr_pos(const T& src, U& dst) { ... } // メンバ関数T::get()、U::set()がある前提
というテンプレートを1個書いて、メンバ関数get()やset()を有する無数のクラスA、B、C、...について
任意の組み合わせでの相互変換（および同一型のコピー）を可能ならしめたんじゃわ
C++は数学や！とそのときｵﾓﾀわ

次の日、今度はメンバ関数get()やset()を持たないクラスFooとBarについて
　template<class U> void tr_pos(const Foo& src, U& dst) { ... } // メンバ関数U::set()がある前提
　template<class T> void tr_pos(const T& src, Foo& dst) { ... } // メンバ関数T::get()がある前提
　template<class U> void tr_pos(const Bar& src, U& dst) { ... } // メンバ関数U::set()がある前提
　template<class T> void tr_pos(const T& src, Bar& dst) { ... } // メンバ関数T::get()がある前提
というテンプレートを追加して、{ A, B, C, ... }とFoo、および{ A, B, C, ... }とBar、
および（前日実現済みの）{ A, B, C, ... }内の任意のクラス間のの相互変換を
tr_pos(src, dst)と書いただけで可能ならしめるという壮大な体系を実現したんじゃわ
C++は数学や！という思いをそのときさらに強くしたわ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 21:19:31.58

さらに次の日、Foo型オブジェクトsrcとBar型オブジェクトdstについてtr_pos(src, dst)と
書いたらビルドエラーになったわ；
仕方ないので関数のオーバーロードを使って
　void tr_pos(const Foo& src, Bar& dst) { tr_pos(src, A); tr_pos(A, dst); }
　void tr_pos(const Bar& src, Foo& dst) { tr_pos(src, A); tr_pos(A, dst); }
のようにして解決したんじゃわ
C++はちょっとしたテクニックを要する数学や！とそのときｵﾓﾀわ

さらに次の日、Foo型同士、およびBar型同士でコピーしたくなったので、
一昨日書いたテンプレートを特殊化したら行けるやろ、と思って
　template<> void tr_pos<Foo>(const Foo& src, const Foo& dst) { ... }
　template<> void tr_pos<Bar>(const Bar& src, const Bar& dst) { ... }
と書いたらコンパイラが一昨日書いたテンプレートではなくて昨日書いた
オーバーロード関数を特殊化しようとしてビルドエラーになるわrz
C++はいろいろ破綻している罠だらけの言語やとそのとき確信したわ；

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/06/30(日) 21:42:30.00

C++スレでC++の話をして何が悪いの

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 21:45:46.60

C++の話は悪くないかもしれないが、関数テンプレートの部分特殊化ができないというC++の仕様は悪い
※ 個人の感想です

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/06/30(日) 21:47:02.52

>>324
念のため確認なんだけど
　template<> void tr_pos<Foo,Foo>(const Foo& src, const Foo& dst) { ... }
　template<> void tr_pos<Bar,Bar>(const Bar& src, const Bar& dst) { ... }
じゃなくて？

2019/06/30(日) 21:47:07.25

皮肉もわからんか

オーバーロードの解決順を制御するTipsがあった気が
この辺はマジで分かりにくいわ
コンパイルオプションで名前解決の過程が可視化できるとありがたいんだけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 21:50:50.85

constexpr ifで解決

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 22:04:25.11

>>327
うおﾎﾝﾏやできた！
mjk、、、

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/06/30(日) 22:15:40.66

さらに言えば<Foo,Foo>と<Bar,Bar>の所消しても動かん？

template<>void tr_pos(const Foo...

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/30(日) 22:49:04.24

>>331
それはさすがに駄目で、VC++で次のエラーになる
　error C2912: 明示的な特殊化; 'void tr_pos(const Foo&,Foo &)' は関数テンプレートの特殊化ではありません。
原因は1日目に追加したtr_pos<T, U>(const T&, U&)、および2日目に追加したtr_pos(const Foo&, U&)、tr_pos<T>(const T&, Foo&)の
3種類のうちのどれを特殊化すべきなのかわからないかららしい

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

まとめ: >>323-324の状況において、特殊化は次のように手段を使い分けねばならない

(1) 3日目のtr_pos(Foo, Bar)の追加は、関数テンプレートの特殊化ではエラーになるので関数のオーバーロードで特殊化する必要がある。
　（理由）
　tr_pos(Foo, Bar)は以下の関数テンプレート全てに当てはまってしまい、コンパイラが特殊化対象を特定できない。
　tr_pos<T, U>(T, U), tr_pos(Foo, U), tr_pos(U, Bar)

(2) 4日目のtr_pos(Foo, Foo)の追加は、関数テンプレートを>>327のように型パラメータ<T, U>を全て指定して明示的特殊化するなら逝ける
　（理由）
　関数引数にBarが現れないことから、tr_pos(U, Bar)は特殊化対象から外れる。
　型パラメータ<T, U>を両方明示することにより、tr_pos(Foo, U)も特殊化対象から外れる。
　==> 残るtr_pos<T, U>(T, U)が特殊化対象の関数テンプレートであるとコンパイラが判断できる。

(3) 一方、4日目のやつを暗黙的特殊化で行おうとするとビルドエラーで失敗する。
　（>>332でも述べたが、上記(1)と同じことになる。

T::get()やU::set()を持たないクラスであるFooやBarを無理やりtr_pos()というシグネチャで他と統一的に扱おうとした結果ｽｹﾞｰ薄氷を踏むようなプログラミングになっていた、
ことがわかった、、

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

constexpr if使えって

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

>>333ﾌﾟﾁ訂正orz
誤： tr_pos(U, Bar)
正： tr_pos<T>(T, Bar)

>>334
手元の環境はC++14なので使えないっぽい
および、>>323-324のガンはtr_pos(Foo, U), tr_pos<T>(T, Bar)の2つのテンプレートの名前が
tr_pos<T, U>(T, U)と同じであることにあるのは確定的に明らかなので、これを治療するのが筋
constexpr ifに逃げるのはいささか筋が悪いかと、

※ tr_pos(Foo, U), tr_pos<T>(T, Bar) を、それぞれtr_pos以外の固有の名前に改名し
　　（例えばtr_pos_from_Foo,とtr_pos_to_Bar）、
　　tr_pos<T, U>(T, U)にてそれらを使って共通の名前tr_posで実体化するテンプレートを書くならば、
　　テンプレート機能の中だけで目的（tr_pos(T, U)式のシグネチャへの統一）を果たせてシンプル＆スマートに解決する。

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

>>317
アメリカのコンピュータ科学系の学生の7割がポインタが理解できないらしい。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 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