C++相談室 part148

**デフォルトの名無しさん** · 2020/01/31(金) 20:54:06.26

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

前スレ
C++相談室 part147
https://mevius.5ch.net/test/read.cgi/tech/1576659413/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://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/ (日本語)

**デフォルトの名無しさん** · 2020/02/16(日) 15:03:54.38

>>920
意見されたら喧嘩売りたくなる病気なの？

**デフォルトの名無しさん** · 2020/02/16(日) 15:10:11.48

mallocは使い方が余程ひどく無ければ、性能上問題になることはない
問題になっている場合もプロファイラでその部分だけ対策すればどうにでもなる
断片化やmalloc自体の管理領域容量が気になるほどの環境では使わない方がいいが

**デフォルトの名無しさん** · 2020/02/16(日) 15:11:53.22

>>926
それお前じゃね？

**デフォルトの名無しさん** · 2020/02/16(日) 15:13:28.86

>>927
リアルタイム系の仕事したことないならそう言う考え方でもいいと思うよ

**デフォルトの名無しさん** · 2020/02/16(日) 15:17:30.49

そもそもリアルタイム系の処理で、実処理部分でmallocするってのは普通しないよね

初期化時に必要なバッファはあらかじめ確保しておくものでしょ
そこはmallocだろうが静的確保だろうが変わらないし

**デフォルトの名無しさん** · 2020/02/16(日) 15:23:06.64

>>929はループの中で毎回malloc freeしてるからそりゃ性能が気になるよね

**デフォルトの名無しさん** · 2020/02/16(日) 15:24:31.11

>>925
std::vector<TYPE> は、リンクリストではなく、「可変長配列」なので、std::list<TYPE> に比べて、TYPE のコンストラクタがデコボコした頻度で
多めに呼び出されてしまう傾向がある。TYPEのコンストラクタの中で何かをnew していると、new が呼び出される回数をグラフにした場合、
デコボコになるため、速度的に滑らかさがなくなってしまう可能性が考えられる。
それは、newの速度がデコボコなのではなく、std::vector が持つ悪い性質の一つ。
速度的に「滑らか」にしたいならば、std::list の方が適している。
そもそも、C言語がポインタを用意したのは、リンクリストを使いたかったからで、Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
Cの高速性とはリンクリストによるものと言っても過言ではない。
newも、mallocもコンストラクタも、リンクリストと最も相性が良い傾向がある。
cppreferenceなどでも、std::vectorが出てくることが多いが、Cの新かを発揮するにはstd::listの方が良い。

**デフォルトの名無しさん** · 2020/02/16(日) 15:25:54.32

>>932
誤：Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
正：Cはデータ集合用のデータ構造として動的配列ではなくリンクリストを用いるのが伝統。

**デフォルトの名無しさん** · 2020/02/16(日) 15:27:49.69

いやいや、速度がシビアならreserveしとけと
cとの親和性考えなきゃdequeも良いが、cのAPI呼び出し考慮すると結局vectorをうまく使うのが一番良い

**デフォルトの名無しさん** · 2020/02/16(日) 15:28:20.99

>>929
std::vector<TYPE>を使っていて、TYPEのコンストラクタの中でnewするのはリアルタイム処理には向きません。
その場合、std::list<TYPE>に変えれば劇的に速度が安定するはずです。

**デフォルトの名無しさん** · 2020/02/16(日) 15:30:12.10

>>934
CのAPI呼び出しで集合を渡す場合、通常、集合の要素はコンストラクタを持ちません。
その場合は、std::vectorは適すでしょう。
ところが、要素がコンストラクタを持つ場合は、std::listが適します。

**デフォルトの名無しさん** · 2020/02/16(日) 15:32:54.67

vectorで再配置する際にmoveされない前提なのね

**デフォルトの名無しさん** · 2020/02/16(日) 15:33:13.19

>>936
補足すれば、APIは、リング0のシステムランドで実装されていることが多いため、
リンクリストの様な複雑な構造が用いられることが少ないのです。
しかし、それはAPIに限った話で、Cは誕生したときから、要素数が変化する
集合には、動的配列よりもリンクリストを用いるのが伝統でした。
伝統と言うよりも、リンクリストこそがCの核心・本質といっても過言では有りません。

**デフォルトの名無しさん** · 2020/02/16(日) 15:35:27.77

>>937
C言語とはリンクリストのことです。
動的配列は、Cの文化ではありません。

**デフォルトの名無しさん** · 2020/02/16(日) 15:36:04.25

アドレスで直にアクセスできる言語の強みはリンクリストで活きるからごもっとも

**デフォルトの名無しさん** · 2020/02/16(日) 15:40:23.46

>>930
そう言う事
平均的には間に合っても確保や解放にかかる時間が読めなくなる
100万回に１回でもダメならダメっていう世界だしね

>>931とかはそう言うことがわかってないので頓珍漢なレスになってるw

**デフォルトの名無しさん** · 2020/02/16(日) 15:40:27.92

>>934
reserveしただけだとOSによっては実メモリ確保しなさそう…
で初回アクセスでおもむろにページが用意されれる
ﾖｶﾝ

**デフォルトの名無しさん** · 2020/02/16(日) 15:42:34.49

それだとmalloc使うこと自体不味いだろ
確率でmmapしちゃうのだから

**デフォルトの名無しさん** · 2020/02/16(日) 15:44:00.56

別に
>>925の前半でおk

**デフォルトの名無しさん** · 2020/02/16(日) 15:46:21.91

もちろん初期化時以外でね

**デフォルトの名無しさん** · 2020/02/16(日) 16:01:46.00

>>937
moveを使いたい場合、要素の TYPE クラスに move 用の記述が必要となるため、手間がかかります。

**デフォルトの名無しさん** · 2020/02/16(日) 16:01:54.10

is_pod_vで事前条件を確認してるけど、PODはなくなるんだってね。

**デフォルトの名無しさん** · 2020/02/16(日) 16:02:29.34

>>935
まあお前がそう思うならそうなんだろうな
お前ん中ではな…

**デフォルトの名無しさん** · 2020/02/16(日) 16:07:00.64

listで美味しいのはsplice使いたい時くらいだろ
multi threadのログ統合したい時とかに、lockに必要な時間を最小化出来る

**デフォルトの名無しさん** · 2020/02/16(日) 16:26:27.54

>>947
POD = trivialかつstandard_layout
だから後者を使うようにすればいい

**デフォルトの名無しさん** · 2020/02/16(日) 17:05:35.53

子スレッドを休眠状態で作る方法ない？
起動直後にcondition_variable::waitとかじゃなく
初期状態として

**デフォルトの名無しさん** · 2020/02/16(日) 17:13:29.37

何のために？それによる

**デフォルトの名無しさん** · 2020/02/16(日) 18:53:05.64

>>950
ありがとん。

**デフォルトの名無しさん** · 2020/02/16(日) 21:26:26.27

>>953
いえいえ

**デフォルトの名無しさん** · 2020/02/16(日) 23:16:48.80

>>924
まあそりゃね

使えるようにしてもPCやスマホのように自由には使えないぞ
こまめに確保解放なんてことはしない
基本最初に確保して終わり
解放はしない
だから確保しか出来ないヒープも選べる

**デフォルトの名無しさん** · 2020/02/16(日) 23:20:30.34

>>927
それはPCやスマホなどリッチな環境の場合

>>931
一見軽そうで重い関数があったりするから
同じ人が同じ時に作ってたらそんな処理にはしないだろうけど

**デフォルトの名無しさん** · 2020/02/17(月) 00:08:48.44

白物家電のマイコンやら、pfcのマイコンやらもやったが、そんなのはそもそもmalloc使うような環境じゃなかったしなぁ
RAMもkB単位で少ないし、自由に関数呼べるほどスタックも無いし
割り込み部分はアセンブリで書いてた

**デフォルトの名無しさん** · 2020/02/17(月) 00:14:53.75

今は冷蔵庫や電子レンジもAI積んでネットワークに繋がるIoT時代だけど
それでも組み込みって未だにそんな感じなの？

**デフォルトの名無しさん** · 2020/02/17(月) 00:16:48.70

まあそれは特に東南アジア向けだったし
日本よりさらにチープだったのかも

**デフォルトの名無しさん** · 2020/02/17(月) 00:19:59.06

>>958
そんなのごく一部

**デフォルトの名無しさん** · 2020/02/17(月) 00:20:59.44

いまだにチープな8bit CPUもたくさん使われている

**デフォルトの名無しさん** · 2020/02/17(月) 00:23:25.57

cortex-m0とか載ってたらもう小躍りしちゃうくらいのリッチさだよね

**デフォルトの名無しさん** · 2020/02/17(月) 00:34:16.83

リッチなCPUを使うって事は
それだけ求められる事が大きいわけで

**デフォルトの名無しさん** · 2020/02/17(月) 07:41:59.44

でもCPU節約するために人件費かけて結局商品高いじゃん

**デフォルトの名無しさん** · 2020/02/17(月) 09:22:40.01

趣味じゃないんだから
当然トータルで考えるよ

開発工数、単価、機能性能、信頼性、供給、大人の事情、...

**デフォルトの名無しさん** · 2020/02/17(月) 10:36:24.72

ゲーム業界の人だけど
new使っても問題ないってのはおれの常識とは異なる

まず問題が広すぎる
言いたいことはデフォルトのグローバルヒープを無邪気に使っていいか
ということだと仮定すると
AAAクラスでそんな杜撰なことしてるところはないと思う

組み込みもそうだがリアルタイム性が必要とされるところでは、メモリ予算というものがある
グラフィック、オーディオ、ネットワークなどのモジュールごとにメモリいくらと決められる
モジュールの責任者はその中でやりくりする
ここで大事なのはメモリの最大使用量を保証しなければならないってこと

必要ならローカルのヒープは作ったりするが、この時点で担当者が気ままにnewってのは認められない
基本的にすべてコントロールされる
現実的に最大量が正確に見積もれないものもあるがそれでも最大量は決める

**デフォルトの名無しさん** · 2020/02/17(月) 10:57:08.38

といってもグローバルヒープを使わないわけじゃない
オープンソースのもので無邪気にmallocするものは多数あるが、それほど荒ぶらなければそのまま使う
(リアルタイム性が不要なら仮想メモリに任せる)

あとmalloc遅くないという論調の人がいるけどそれはベストケースの話でしょう
ヒープメモリが不足したり一度に巨大なメモリを確保する場合はシステムコールになるからずっと遅くなる
ワーストが見積もれないものはリアルタイムで使いづらい

まぁ昨今は仮想マシン上で動くゲームが多数あるわけで気にしなくていいレベルという意見はある
ただesports系で一瞬カつくとか商品性に関わるわけで
また後から直すのも地獄なので
最初から計画的に作るべきだろう

**デフォルトの名無しさん** · 2020/02/17(月) 11:06:49.04

ここC++スレだよね、つかぬことだけど
記憶管理はいつでも如何様にもカスタマイズできるようにtypename Allocatorになってるわけじゃん
なんでいきなり組み込みには向かないとかキリッてんの？

**デフォルトの名無しさん** · 2020/02/17(月) 12:20:34.06

>>968
typename Allocatorとかすげぇ初心者っぽい
キリってるのはお前だ

**デフォルトの名無しさん** · 2020/02/17(月) 12:22:54.84

>>969
ｋｗｓｋ

**デフォルトの名無しさん** · 2020/02/17(月) 12:39:53.15

>>968
標準ライブラリでもallocatorが指定できないものもあるんだよ
もはや今のc++で標準ライブラリを全面的に使いつつ、ヒープを個別に差し替えるのはかなり非現実的だ
allocatorを差し替えられてもnewするタイミングや量はリバースエンジニアリングしないとわからない
それが問題になることもある

**デフォルトの名無しさん** · 2020/02/17(月) 12:48:18.84

てか、静的確保したメモリブロック使うアロケータ書いてそれで標準コンテナ使うのが基本じゃね
まあeastlでも良いが

**デフォルトの名無しさん** · 2020/02/17(月) 12:51:50.81

>>971

> 標準ライブラリでもallocatorが指定できないもの
例えば？

newだってoperator newですぐカスタマイズできるし
placementで環境依存の細かい設定もできる

ライブラリはISO/IEC14882に固執する必要はなく
サードパーティでも内製でもより都合のよいほうを使えばいい
というだけの話

**969** · 2020/02/17(月) 12:56:55.88

カスタマイズの話なら真っ先にnewの話をすべきなんだが順番おかしくね？
ていうか今時はallocatorより先にpolymorphic resourceだと思うが

というかそもそもmallocの速度の話からであって、いきなりallocatorの話したり
C++全体を否定されたかのように過剰反応するとか・・

**デフォルトの名無しさん** · 2020/02/17(月) 13:12:34.13

仕様通りに書けばいい感じにうごいてくれて、責任は俺にはないとか
思い込んでんじゃってるキッズなんだろう。
デバッグするなんてことはもちろん頭にない。

**865** · 2020/02/17(月) 13:34:28.75

>>890からの流れでは直後からnewが出てきてたろ
C++が組み込みに向かないという主張の
理由がmallocじゃおかしいだろ
それしか使えんわけでもなし

**デフォルトの名無しさん** · 2020/02/17(月) 13:44:11.06

>>968に突っ込むと>>890に同意したことになるのか

**デフォルトの名無しさん** · 2020/02/17(月) 14:00:21.02

>>973
> > 標準ライブラリでもallocatorが指定できないもの
> 例えば？

でしょ？
お前さんは人並み以上にc++知ってると思うけどこの事実知らない
どこで使われてるか知らなきゃ置き換えができないよね

答えはあえて教えない
標準ライブラリのヘッダーをnewでgrepすればallocatorを通さないものが見つかるさ
自分で確認してこりゃ置き換え無理だわと悟って欲しいw
もし見つからないなら後で書くよ

ちなみにグローバルにnewを置き換えるぐらいならmallocのバイナリを差し替えた方が早いし確実

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/17(月) 14:31:40.00

おっ。
野党みたいなことを言い始めたぞ。

**デフォルトの名無しさん** · 2020/02/17(月) 14:37:47.70

>>979
横からだが、具体的に誰のどこを指してそう思ったのかよろしく

**デフォルトの名無しさん** · 2020/02/17(月) 14:59:36.07

>>966
もちろん、むやみやたらと使って全く問題ないわけではない。
が、本当に必要な箇所で使う程度なら(多くの場合)余り問題ないという程度。
大体ゲームの場合のnewやmallocは、敵や弾やイフェクト、3Dオブジェクトなど
を1つずつ収めるために使うことが多いが、ゲームの1シーン内に登場する個数が
newやmallocが問題ない程度に元々なっている事がわりと多いと言うだけ。
3Dの雑草の葉っぱ一枚単位で new したりすると問題になってくるかもしれない。

**デフォルトの名無しさん** · 2020/02/17(月) 15:51:15.09

>>981
なんとも感覚的な話だね
だいたい動けばOK！って感じ？
おれは仕事でそういうもの作りはしない

**デフォルトの名無しさん** · 2020/02/17(月) 16:08:54.93

コンシューマかPCかでも違うだろうし
（自分はさほど詳しくないが、基本コンシューマは標準ヒープ使わないはず）
ジャンルによっても違うんじゃね
PCのMMORPGなんかだとシーン中のメモリ確保は必須だろうし
あと草は普通同じメッシュやテクスチャ使うだろうし、揺れを入れるにしても一つ一つにデータ持たせるなんてアホなことしないだろ

**デフォルトの名無しさん** · 2020/02/17(月) 16:15:08.76

>>978
「後で」かｗ
もう1000間近だし期限切らないでおけば時効だろってか？

**デフォルトの名無しさん** · 2020/02/17(月) 16:32:36.59

いやそれくらい調べろって話だろ。。馬鹿が。

**デフォルトの名無しさん** · 2020/02/17(月) 16:44:43.28

>>985
sgjaAMaLが、自分の話に傾聴してきた人の質問に答えなかった
つまり自分の考えを伝える努力を中止したということでしかない

何人も自らの意見を他人に伝えるには
その意見を説明するしかなく
説明をやめることは沈黙に等しい

**デフォルトの名無しさん** · 2020/02/17(月) 16:55:56.23

黙って調べてくれば？
調べて無いと結論づけられればまた偉そうに出来るだろw

**デフォルトの名無しさん** · 2020/02/17(月) 17:15:39.87

ちゃうねん。
僕が組み込みいうたのはArduinoのことな。
RAM2KBやし。

**デフォルトの名無しさん** · 2020/02/17(月) 17:31:33.05

Arduino面白いよ。

**デフォルトの名無しさん** · 2020/02/17(月) 18:25:59.21

>>984
条件は明示してるんだからおれが書くかはお前に委ねられている
1000が迫っているぞw

**デフォルトの名無しさん** · 2020/02/17(月) 18:30:32.07

この手の人最後まで答えないか
答えても的外れなのしか見たことないわ

**デフォルトの名無しさん** · 2020/02/17(月) 18:32:18.22

だね
消えて良いよ

**デフォルトの名無しさん** · 2020/02/17(月) 19:27:27.34

>>978
std::arrayとか言わないよね

**デフォルトの名無しさん** · 2020/02/17(月) 19:33:45.21

arrayのどこに動的メモリ確保が出てくるんだよ
アホか

**デフォルトの名無しさん** · 2020/02/17(月) 19:46:45.93

なぞなぞですか。

**デフォルトの名無しさん** · 2020/02/17(月) 23:00:17.88

漏れはnewのときたまの遅さの可能性に警鐘を鳴らしたからｾﾌｾﾌ、

**デフォルトの名無しさん** · 2020/02/17(月) 23:06:03.72

やっぱnew/deleteのレイテンシーを設計に乗せるには非ページプールメモリにアロケートするべきですよねー

**デフォルトの名無しさん** · 2020/02/17(月) 23:19:17.27

なんかスレ止めてたら悪いから書いておくよ
ひとつは17からallocatorがdeprecatedになったstd::functionね
これは結構知られてるばずだ
定期的にこれ濫用する人が現れるんだけど中身理解してから使うか判断しろと職場では言っている代物

もうひとつあげるなら、
処理系によってかなり違うかもだけどstd::threadも中でこっそり内部クラスをnewしてるはず
ただスレッド間で引数を引き渡すためのものでサイズは小さいしスレッド作るコストの方が遥かにでかいから問題にはなりにくい

他にもあるけどとりあえずこんなもんで

**デフォルトの名無しさん** · 2020/02/17(月) 23:46:06.60

std::functionを使わないと1 bitもプログラムが書けなくなった漏れｶﾞｲﾙ、
クロージャをいちいちクラス定義から手で書く日々に戻るのはいやじゃー

**デフォルトの名無しさん** · 2020/02/17(月) 23:54:13.03

1000なら>>986, >>991-992が土下座

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 17日 3時間 0分 7秒