C++相談室 part141

**デフォルトの名無しさん** · 2019/02/22(金) 03:07:43.52

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/

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

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

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

----- テンプレここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2019/03/27(水) 10:08:24.05

>>812
それpush_back or emplace_back使っているのが悪いのでは
cの同等コード書いてもチェックは必要だろ
チェック要らんことが分かっているならresizeしておけ

**デフォルトの名無しさん** · 2019/03/27(水) 10:12:49.51

Cで作っても同じでワロタ

**デフォルトの名無しさん** · 2019/03/27(水) 10:22:17.37

>>813
便利なものがあれば人間は使ってしまうもんだ
その積み重ねがパフォーマンスの差に繋がる
俺は一般には便利なものを使って時間を節約することでボトルネック解消にかける時間を確保でき、
結果的にパフォーマンスはより高くなると思うけど、そこはスケジュールの制約次第だな

**デフォルトの名無しさん** · 2019/03/27(水) 10:29:47.46

Cマスター「C++は配列に追加するときにサイズチェックするから遅い(ｷﾘｯ」

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
こんな雑魚がでかい顔してるからいつまでもセキュリティホールがなくならないんすなあ

**デフォルトの名無しさん** · 2019/03/27(水) 10:34:12.90

Cマスター「要素追加時にサイズチェックするという便利さの積み重ねがパフォーマンスを落とす(ｷﾘｯｷﾘｯ」
やべえ笑い死にしそう
笑い事じゃないけど

**デフォルトの名無しさん** · 2019/03/27(水) 12:49:47.89

プロファイラで調べて本当に問題あるならどうにかするけど
ただわざわざc的に書いても大抵誤差レベルでしか変わらんよね
どちらかと言うとバッファの確保の仕方を工夫した方が効果が大きい

**デフォルトの名無しさん** · 2019/03/27(水) 13:05:12.78

>>816
トレードオフもわからん雑魚

**デフォルトの名無しさん** · 2019/03/27(水) 13:06:52.67

>>810
・以下、要素数が N とする。

・C/C++ の原定義の固定長配列は、要素の代入に1クロックしかかからない。もちろん、
　O(1)で、物凄く速い。なお、固定長なので「代入」であり「追加」ではない。

・Listはリストだから1個の要素の追加はO(1)で、要素数に依存せず安定した速度が出るが、
　内部で、newされるはずなので、最低でも170クロックほどかかってしまう。

・Vectorは動的配列だから、最悪のケースでは要素の追加にO(N)の時間がかかり固定長配列より遅くなる
　と思う（よく知らない）。

**デフォルトの名無しさん** · 2019/03/27(水) 13:34:58.24

>>817
複数の要素を追加するとき、わざわざ事前にまとめてリサイズするか？ということだよ
1要素ずつ処理するのは生ポならかえって面倒になることが多いし、見た目にいかにも非効率そうなコードに見えるから、大抵の人は自然にそうするだろう
一方vectorだとどうだろうね
心理的な問題なの

**デフォルトの名無しさん** · 2019/03/27(水) 13:45:54.22

同じようなことはvectorに限らず一般的に言ええて、
例えばC++はRTTIの便利さ故にCと比較してプログラマが無駄なメモリの確保や破棄を行いやすい傾向がある
逆にCだと無駄に大きなバッファ作りがちだったり、バッファの使いまわしによりスレッドセーフでないコードを書きがちであったりする

**デフォルトの名無しさん** · 2019/03/27(水) 13:46:41.13

すまんRTTIじゃなくてRAIIな

**デフォルトの名無しさん** · 2019/03/27(水) 14:07:44.29

クロックなんてわからんじゃろ

**デフォルトの名無しさん** · 2019/03/27(水) 14:29:28.16

VC++2017なんだけど
デストラクタで投げた例外をキャッチできずabortするのはVC++の仕様？
RAIIとラムダを駆使した自作finally内で
例外投げたらキャッチできずabortしてハマったわ
デストラクタ内で例外投げるのが汚いのは知ってたが
そうか、自作finallyもデストラクタ利用してるからダメなのかな

**デフォルトの名無しさん** · 2019/03/27(水) 14:35:28.06

デストラクタはデフォルトでnoexceptやで

**デフォルトの名無しさん** · 2019/03/27(水) 14:54:30.22

サンクス
デストラクタをnoexcept(false)指定したらcatch出来たわ

てことは自作finallyは念のためnoexcept(false)指定にしたほうが良いのか
それか自作finally内で例外投げるのは完全禁止にするか
悩むわ

**デフォルトの名無しさん** · 2019/03/27(水) 14:56:55.41

まぁでもよく考えたら
例外が発生して自作finallyが実行されてる時に
さらに自作finally内で例外飛ばしたら二重例外になるから危険か
なるほどなるのど

**デフォルトの名無しさん** · 2019/03/27(水) 17:38:06.36

>>820
意味がわからん
そもそもCでも固定長配列の代入は実データのコピーを伴いO(n)だ
アドレスや参照のやり取りならO(1)

**デフォルトの名無しさん** · 2019/03/27(水) 17:50:46.31

全体じゃなくて一要素やろ？

**デフォルトの名無しさん** · 2019/03/27(水) 17:55:38.42

あーそう言うことか
固定長的に使いたいなら始めにresizeするだけじゃない

便利だからチーム内で使ってしまう人がいることを問題にするより、使わずにいちいち独自コードで処理されて余計遅くなったり、バグ仕込まれたりする方が余程ヤバイだろ

**デフォルトの名無しさん** · 2019/03/27(水) 18:00:35.88

先生、配列の長さにリミットを設ける方法を教えてください

**デフォルトの名無しさん** · 2019/03/27(水) 18:00:36.53

まぁそれでも範囲チェックは入るし、常にヒープ使われるし
それすら問題になるようなクリティカルな場所なら生配列なりarray使えばいいと思うけど
適材適所じゃないかねぇ

**デフォルトの名無しさん** · 2019/03/27(水) 18:03:25.00

operator[]なら範囲チェック入らんよ

**デフォルトの名無しさん** · 2019/03/27(水) 18:14:58.29

末尾に追加の話だろ

**デフォルトの名無しさん** · 2019/03/27(水) 18:15:04.13

うお、マジだ誤解してた

**デフォルトの名無しさん** · 2019/03/27(水) 18:20:39.73

>>836は>>834宛
まぁ要素数わかってて末尾に入れてくのはナンセンスやね
速度を気にしない場所ならどうでもいいけど

**デフォルトの名無しさん** · 2019/03/27(水) 18:39:59.51

よくあの時代にこのような洗練されたライブラリを設計できたものだと思います。
もしかすると宇宙人にもらったのかも。

**デフォルトの名無しさん** · 2019/03/27(水) 20:06:12.42

配列の長さチェックのオーバーヘッドとかなんかものすごくデジャブ感のある議論だな。
肯定、否定どちらにしてもマウンティングかましたくなる題材なんかね。

**デフォルトの名無しさん** · 2019/03/27(水) 21:09:05.61

標準コンテナで問題になるのはやっぱりヒープだよ
境界チェックとか仮に無断だとしても一定時間で終わる処理
ヒープ使われると最悪システムコールで負荷変動大きすぎる

ちなみにアロケータは要素数で管理できないから面倒
あとvectorで最初にreserveしても最大長越えないチェックが必要で面倒

でこれらを解決するコンテナがboostにあるのでそれを使う

**デフォルトの名無しさん** · 2019/03/27(水) 21:18:02.40

あと標準ライブラリのリンクリストはそもそもの設計が非効率
(クリーンな設計ではあるが)
素朴なcの実装と比べてかなり差がでる
これも代替がboostにある

**デフォルトの名無しさん** · 2019/03/27(水) 21:25:03.72

>>835
末尾追加の話なら、Cでも同じだけコストかかるだろ。
>>840
arrayならstackに積まれる。

◆QZaw55cn4c · 2019/03/27(水) 21:31:48.60

>>820
なんか変じゃないですか？
list や vector のときは要素の「追加」なのに、生配列だけ要素の「代入」と設定するのですか？
list や vector で要素の「追加」を考察するのなら、生配列の場合も要素の「追加」を検討してください

**デフォルトの名無しさん** · 2019/03/27(水) 21:38:22.09

>>842
arrayは固定長
欲しいのは最大長を事前に確定しつつ、その範囲で可変長で使えるvector
という話ね

**デフォルトの名無しさん** · 2019/03/27(水) 21:45:52.93

ここのCマスター様は、現在の配列長と挿入インデックスのチェックしてreallocしてなんていう
パフォーマンスの悪い便利さに甘えた処理などしない
堂々とv[N]に無条件代入を行って超高速O(1)追加を実現するのだ

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/03/27(水) 21:50:08.37

事前のresizeかreserveでええんとちゃう？

**デフォルトの名無しさん** · 2019/03/27(水) 21:51:09.94

事前に分かるならスタック固定長でいいじゃん

**デフォルトの名無しさん** · 2019/03/27(水) 22:02:47.67

reserve あれば困る事なんてないやろ

**デフォルトの名無しさん** · 2019/03/27(水) 23:54:55.06

一般的には無いよ
局所的な話を持ち出してああだこうだ言ってるのが今
そして何をするつもりかは誰も知らん

**デフォルトの名無しさん** · 2019/03/28(木) 00:42:33.33

>>829
要素数がN、データの大きさは4バイト、と仮定した場合の話。

**デフォルトの名無しさん** · 2019/03/28(木) 00:47:43.37

>>843
4バイト整数のN要素の配列を仮定しているが、Cの単純な固定長配列だと
4バイト整数はコピーするのが当然。
ところが、Listだと、「追加」するしかない。動的配列である
Vectorも、基本的には「追加」が基本。そうでなければ「動的」と言わない。

**デフォルトの名無しさん** · 2019/03/28(木) 00:53:54.09

vector.data()、basic_string.c_str()はCと同じの配列の連続アドレスを保証する数少ないインターフェースでしょ。

**デフォルトの名無しさん** · 2019/03/28(木) 01:07:32.08

正直stringがゼロ終端を保証したのはちょっとどうかなと思ってる
いや便利なんだけどさ・・

**デフォルトの名無しさん** · 2019/03/28(木) 01:15:59.09

>>853
特に不都合無いのだからいいだろう

**デフォルトの名無しさん** · 2019/03/28(木) 01:39:16.25

アドレスと一緒にバッファサイズを渡せないAPIが世の中に無数にある。ヌル終端は優しさ。

**デフォルトの名無しさん** · 2019/03/28(木) 03:12:24.24

そもそも printf が

**デフォルトの名無しさん** · 2019/03/28(木) 05:04:36.64

>>851
なぜかC言語は固定配列でC++だと動的が基本らしい
前提違うのに速度ガーとか言われてもなぁw

◆QZaw55cn4c · 2019/03/28(木) 05:12:10.50

>>855
ヌル文字をデータとして扱えない、という決定的なウィークポイントが発生しますね…
昔、ツールがヌル文字を扱えない、という点が後から発覚してとても困った経験があります

**デフォルトの名無しさん** · 2019/03/28(木) 07:13:39.49

>>851
ようゴCマスター様
マスター様は知らなくてビックリするけど、C++ではvectorやlistは要素数が実行時に決まるときに使うんだ
そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
reallocっていうらしいんだけどさ
使うときは確保済みのバッファの長さをいちいち調べて、足りなかったら再確保して必要に応じて要素を全部コピーするらしいっすよ
もちろんそんな馬鹿げたオーバーヘッドを払う奴はC++かぶれのド素人だけだけどな
真のCプログラマは一度確保した配列の自由なインデックスにコピーすることでvectorの無意味なオーバーヘッドを回避し超高速O(1)を実現するのだ

**デフォルトの名無しさん** · 2019/03/28(木) 08:00:11.54

なんかツッコもうと思ったら既に>>813に書いてあった

**デフォルトの名無しさん** · 2019/03/28(木) 10:11:22.12

>>857
C++の配列は固定長が基本。
STLやboostは、C++とは異なる。

**デフォルトの名無しさん** · 2019/03/28(木) 11:32:51.21

>>859
>そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
>reallocっていうらしいんだけどさ

Cでは、realloc は推奨されて無い。
Cで、要素数が実行時に決まるような集合を扱いたい場合は、自前で
ポインタでリンクする、リンクリストを使う。
毎回それをやると間違いやすいので、賢い人は、自前でリストライブラリを作って
それを用いて操作する。

**デフォルトの名無しさん** · 2019/03/28(木) 11:39:08.71

Linuxのソースなんだけど
close(0) close(1) close(2)って書いてあるの見つけたのだが
これってなんの効果が期待できるの？
ファイルディスクリプタ？だと思っていてオープン等をした値番号だと思ってたけど、0 1 2に該当するのがなんなのかと

**デフォルトの名無しさん** · 2019/03/28(木) 12:01:08.00

stdin, stdout, stderr

**デフォルトの名無しさん** · 2019/03/28(木) 12:18:22.29

iteratorでstartとendの中に納まってることが保証されてるのに
各要素にアクセスするときにまた範囲チェックとかあると無駄やん
そりゃ書こうと思えばいくらでも危険なコードは書けるけど
安全なときはそういうの省いて高速化出来るのがCの良いところなのに
(レジスタの値が知らない間に壊れても正常に動くようにとか言ってるなら知らん)

**デフォルトの名無しさん** · 2019/03/28(木) 12:31:30.80

>>861
固定とか決めつけてるのを別にしても何を言いたいのかさっぱりわからん

**デフォルトの名無しさん** · 2019/03/28(木) 12:34:41.89

>>862
で、そのオレオレ車輪の再発明クソライブラリは
std::vectorやstd::listより何が優れてるの？
範囲チェックしないから高速wなの？

**デフォルトの名無しさん** · 2019/03/28(木) 12:45:22.23

差異があるとすれば、deep copyだね
決めつけ良くない

**デフォルトの名無しさん** · 2019/03/28(木) 12:48:36.64

>>862
ランタイムでサイズが決まる動的配列にリンクリスト使うのはさすがにダメすぎる

**デフォルトの名無しさん** · 2019/03/28(木) 12:56:24.56

>>863
デーモンになりたいんだろうな

**デフォルトの名無しさん** · 2019/03/28(木) 13:00:41.99

>>869
そもそも、C で出来ないことは、コンピュータのアーキテクチャ上、ほぼ
絶対に出来ない事。
だから、Vectorが、効率面でCを上回ることは絶対に有り得ない。

**デフォルトの名無しさん** · 2019/03/28(木) 13:05:17.92

>>869,871
ソートはどうなの？（・∀・）ﾆﾔﾆﾔ

**デフォルトの名無しさん** · 2019/03/28(木) 13:06:22.45

春休みでスレの勢いが上がり、スレの品質が落ちた。

**デフォルトの名無しさん** · 2019/03/28(木) 13:22:32.10

義務教育でプログラミングとか教えたら
もっと変なの増えそう
python界隈に来ないで欲しい

**デフォルトの名無しさん** · 2019/03/28(木) 13:29:56.71

>>874
こういう金融とかの兵隊養成用だから競合はしないと思う
https://pbs.twimg.com/media/DwtF98FUwAIU166.jpg

**デフォルトの名無しさん** · 2019/03/28(木) 13:49:18.36

そのへんの化石言語はいい加減消滅させるべき

**デフォルトの名無しさん** · 2019/03/28(木) 13:51:20.07

化石じゃないまだドメイン次第で現役Fortranだってこの間新しい仕様出たし！ってつっかかられるぞ
08をちゃんと実装したコンパイラ出してから言ってくれよって気持ちだが

**デフォルトの名無しさん** · 2019/03/28(木) 14:01:46.15

>>873
お前が言うな

**デフォルトの名無しさん** · 2019/03/28(木) 14:03:11.91

_____(コボル)

答え COBOL

_____(フォートラン)

答え FORTRAN

これのどこが問題集やねん！

**デフォルトの名無しさん** · 2019/03/28(木) 14:08:39.40

来年度からこれが流通するぞ

**デフォルトの名無しさん** · 2019/03/28(木) 15:14:03.54

ほんと役人どもがやることはいつもずれてる

**デフォルトの名無しさん** · 2019/03/28(木) 16:17:03.97

>>880
その言葉を見る限り、あなたは日本人じゃない気がする。
この文脈で、あなたが言いたかったのは、
「来年度からこれが流通するぞ」ではなく
「来年度からこれが常態化するぞ」
という事だったと思うから。

**デフォルトの名無しさん** · 2019/03/28(木) 17:38:04.05

>>871
それ言い出すなら逆もまたしかりだろ
extern "C"すればCで出来てC++に出来ないことはないぞ。

**デフォルトの名無しさん** · 2019/03/28(木) 17:39:39.59

だいたいC++にはasmがあるしな
アセンブラで出来ることは出来るんじゃね

**デフォルトの名無しさん** · 2019/03/28(木) 18:18:56.58

>>881
おまえらが役人からずれてるんだろ。
日本は公務員のための国やぞ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:20:50.90

それは一理ある
日本は官僚統治国家だから

**デフォルトの名無しさん** · 2019/03/28(木) 18:30:14.54

公僕が・・・舐めてると潰すぞ

**デフォルトの名無しさん** · 2019/03/28(木) 18:32:28.62

888

**デフォルトの名無しさん** · 2019/03/28(木) 18:42:36.05

でも、ターゲットにRubyとC++を選択したのは正解だと思ってるよ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:43:27.34

Rubyはない

**デフォルトの名無しさん** · 2019/03/28(木) 18:45:09.06

日本政府は日本人と将来の日本の年金などのための政治を行えばいいのだから、
日本人が作ったものを使うように推進するのは悪いことではない。
余りにも使いにくいもので無い限りは。
だからWordをやめて一太郎を使うようにしたり、Rubyを使うようにしたり
するとすれば、それは英断だよ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:45:11.14

RubyはWindowsでまともに動かないから、Linux採用するのかな。

**デフォルトの名無しさん** · 2019/03/28(木) 18:48:52.21

>>892
自分の環境では、Windowsで普通に動いてると思ってるけど。

**デフォルトの名無しさん** · 2019/03/28(木) 18:49:56.61

関数型教えればいいのに。

**デフォルトの名無しさん** · 2019/03/28(木) 18:58:40.35

教えるなら実用性と手軽さからしてC++、Javascript、python

**デフォルトの名無しさん** · 2019/03/28(木) 18:59:00.99

>>883
えっ配列初期化子がC++でも使えるように？

**デフォルトの名無しさん** · 2019/03/28(木) 19:00:37.17

>>891
国産のを応援するのは判るが
それが利権になってただのクズが集まって来たり
金貰うと進歩が止まったりするのが日本の悪いところ

**デフォルトの名無しさん** · 2019/03/28(木) 19:04:55.98

国産であっても良いものでなければ応援するべきではない
Rubyは滅ぶべき言語トップ10に入る

**デフォルトの名無しさん** · 2019/03/28(木) 19:07:54.30

>>896
書き方同じじゃなくても同様の事が出来るだろ
cで出来ないこと無いって話にたいしてなのだから

**デフォルトの名無しさん** · 2019/03/28(木) 19:20:56.01

PythonとRubyだったら、Rubyもそんなに悪くは無いと思う。
Pythonは可読性が悪いように感じる。空白インデントだけでブロックや
関数の終わりを決めてしまうので、内部関数が終わってるかどうか分からず、
人の書いたソースが読みにくくて困ったことがある。

**デフォルトの名無しさん** · 2019/03/28(木) 19:39:26.72

C++er的には
動的型の時点でノーサンキューだろ
そういうのが嫌でC++使ってるんじゃないのか

**デフォルトの名無しさん** · 2019/03/28(木) 19:40:51.32

特にRubyは教祖様が
絶対に型は書きたくない
って駄々こねてるから

これはもう日本のガラパゴス化が一層激しくなるな

**デフォルトの名無しさん** · 2019/03/28(木) 19:43:44.68

pyは読みより書きの方が問題
間違えてインデントけずっても気づかないことが多い

**デフォルトの名無しさん** · 2019/03/28(木) 19:51:12.67

>>901
個人的には型のある言語の方が好きだ。
型があった方が、変な問題にはまる率が下がるので開発が速く進む。
大規模開発には絶対、型が必要。
初心者にも大人気言語だった元祖のBASICも、Aが浮動小数点型、A$が文字列型で、
確か、A% が整数型。配列は DIM A(100) や、DIM B%(10,10) などで、
宣言は省略できる場合が多いが、ちゃんと型はあった。
Rubyなどは、A にあらゆる型が入れられるので、関数呼び出しなどが
かなり怖い。間違っていても問題の切り分けが出来ないので「はまったら」大変。
だから、とても慎重にコードを目で見ないといけなくなる。

**デフォルトの名無しさん** · 2019/03/28(木) 19:52:41.47

>>903
Pythonで、良く分からなかったのが、インデントの空白の個数。
2個でも4個でも好きな量を選べるのだろうか？

**デフォルトの名無しさん** · 2019/03/28(木) 19:55:00.97

言語仕様上は揃ってさえいればいい

**デフォルトの名無しさん** · 2019/03/28(木) 19:59:44.37

>>906
やはりそうだったんだ。だから余計に解読できなかったんだな。
エディタでカラムを数えたり、上まで戻ったりして、やっと認識していた。
でも不安が残った。ブロックが終わってるのかどうか物凄く分かりにくい。

**デフォルトの名無しさん** · 2019/03/28(木) 20:02:46.54

今のPythonはカオスだからな
見易い文法目指していたはずが
内包表記やらラムダやら見づらくする文法が増えて推奨までされている

フレーム作るか否かもわかりづらいことこの上ない

◆QZaw55cn4c · 2019/03/28(木) 20:22:58.04

>>851
「実装A, B, C があり、機能 f について、A.f, B.f C.f のそれぞれに、こんなメリデメがあります！」
なら理解できますが、>>820 は、
「A.g, B.f, C.f のそれぞれにこんなメリデメがあります！」
でしょう？それって変じゃないですか？
A.g とかじゃなくて、A.f で比べて欲しいのですが？

**デフォルトの名無しさん** · 2019/03/28(木) 20:33:45.97

>>908
最近の言語全般に言えることだな。
無駄機能入れすぎなんだよ。
クソみたいなシンタックス入れるくらいならライブラリを充実させるほうが正しい。

**デフォルトの名無しさん** · 2019/03/28(木) 20:46:24.22

メリデメっていうやつw
すまんがめっちゃ底辺臭する

**デフォルトの名無しさん** · 2019/03/28(木) 20:56:41.12

ハイクラスの人はなんて言うんだよ。