[過去ﾛｸﾞ] C++相談室 part164 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
184(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c13e-2rqm) 2023/06/14(水)09:19 ID:O3itrano0(1) AAS
>>182
そのために shrink_to_fit がある。
詳細は実装依存なので何もしない関数であっても仕様に反しないけど
常識的には各実行環境で効率的に動くように実装されるので
まずは試してみても損はないと思う。
アロケータを自作してもあまり制御できないんよね。
アロケーションが必要になったらコンテナからアロケータが呼ばれるという
受動的な構造なのでコンテナによるメモリ管理戦略にそれほど関与できるわけではない。
本当にどうしても標準ライブラリの挙動の詳細が不満なら
自分で同等のものを実装する (または望ましいものをどこかから見つける) しかないよ。
185(4): (ｱｳｱｳｳｰ Sadd-g1CP) 2023/06/14(水)10:15 ID:iWYHYN4ra(1/3) AAS
>>182
new で造って delete (または delete []) で解放
186(2): (ﾜｯﾁｮｲ 8bfb-Xx8j) 2023/06/14(水)12:28 ID:XWt8afSz0(1) AAS
更にいうと、deleteはgccでは推奨されないのでptrを使うよりはstaticもしくはvirtualを使いましょうね。
187(2): (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV) 2023/06/14(水)12:29 ID:XEzvAdInM(1) AAS
>>182
>>185とほとんど同じだけどunique ptrで管理。
ヒープの確保時間が問題になるならアロケーター使ってヒープを予約する。
188(1): (ﾜｯﾁｮｲ d9f0-EP1b) 2023/06/14(水)13:12 ID:9CAXVpD30(1) AAS
>>182
vector<空にしたいオブジェの要素の型>().swap(空にしたいオブジェ)
189(2): (ｱｳｱｳｳｰ Sadd-g1CP) 2023/06/14(水)13:33 ID:iWYHYN4ra(2/3) AAS
>>188
vector<空にしたいオブジェの要素の型> hoge;
が既にあったとしたら
vector<空にしたいオブジェの要素の型>(hoge).swap(hoge);
で良いらしいけど副作用の心配無い？
190(3): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/14(水)14:03 ID:0kIiqVrM0(1/2) AAS
>>183
ありがとうございます
> getrusage
を試してみようと思います
>>185-187
STL コンテナを使うとしても自作クラスを使うとしても、オブジェクトを unique_ptr で持つことにして要らなくなったら reset() すれば確保していた分のメモリを捨てられるということでしょうか
依存関係が絡み合っていて簡単に小さいスコープに分割できないときは試してみようと思います
191(2): (ｱｳｱｳｳｰ Sadd-g1CP) 2023/06/14(水)14:16 ID:iWYHYN4ra(3/3) AAS
reset()は違うと思う
192(1): (ﾜｯﾁｮｲ 01da-EP1b) 2023/06/14(水)14:26 ID:HNZbb8Sq0(1) AAS
>>189
その場合はメモリアクセス領域が変わるのでswapする前に取得済みだったイテレータは再取得する必要あり
193: (ﾜｯﾁｮｲ e95f-2rqm) 2023/06/14(水)15:52 ID:K9MvWtl90(1/2) AAS
>186 が何を言ってるのか意味不明でこわい。
194(1): (ﾜｯﾁｮｲ e95f-2rqm) 2023/06/14(水)15:54 ID:K9MvWtl90(2/2) AAS
>>191
「reset() すれば確保していた分のメモリを捨てられる」で間違いないでしょ。
195(2): (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV) 2023/06/14(水)18:26 ID:9LyNOs9uM(1) AAS
>>190
resetする必要は無いよ。
コンテナから普通に要素を削除すれば、後はコンテナクラスがよろしくやってくれる。効率は実装次第だけど。
196(1): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/14(水)18:51 ID:0kIiqVrM0(2/2) AAS
>>195
コンテナクラスがよろしくやってくれるのに任せるのであれば、スマートポインタで持たずに単にコンテナとして持つのと変わらないように思うのですが、違うのでしょうか。
ちゃんと理解していなかったら申し訳ありません。
197(1): (ﾜｯﾁｮｲ d17c-sLM4) 2023/06/14(水)18:58 ID:vjajEcDc0(1) AAS
vectorを信頼するなら単にclear()してshrink_to_fit()すればいい
信用できないならスマポで持っといていらなくなったら手動でブチ消せばいい
それすら信用できないならイチから自分で作れ
お前がどれだけ心配消化による
198(1): (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV) 2023/06/14(水)19:18 ID:YeSwNDrrM(1) AAS
>>196
どのコンテナを使うかによる。
vectorとかdequeはまだ確保していない要素用の領域をしばしば予約するから、>>182のような状況を回避するのは面倒臭い。
listとかmapは(これも実装次第だけど)まだ確保していない要素のための領域を予約したりしないから、他のデメリットを許容するなら>>182対策の選択肢になる可能性はある。
いずれにしても、そこまで気にするならまずベンチマークを取って実態を調査すべきだし、そもそも巨大なメモリを頻繁に確保・解放するのは設計に問題があることが多いから、メモリを解放しないで済む方法を検討してみる。
199(2): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/15(木)03:20 ID:J1cG0ikp0(1/3) AAS
>>198
そもそもvectorのスマートポインタ (あるいはより一般的にサイズが動的なクラスのスマートポインタ) を作り、そのvectorやクラスのサイズを変えたときって確保されてる領域のサイズも変わるんでしたっけ？
手動で変えなきゃいけないと思っていました
(また、vectorのポインタとvectorの先頭要素のポインタは意味が違うのでよりわけが分からなくなりました)
200(1): (ﾜｯﾁｮｲ d17c-sLM4) 2023/06/15(木)06:50 ID:usfnoco+0(1/2) AAS
std::vectorはshrink_to_fit()呼ばない限り勝手にcapacity縮めたりしないはずだけど
201(1): (ﾜｯﾁｮｲ d19c-jufV) 2023/06/15(木)08:48 ID:hMmgKiSo0(1) AAS
>>199
コンテナ内のポインタの予約は避けられないよ。
ただ、ポインタのサイズを気にするようなシビアな状況なら、そもそもc++じゃなくてcで実装することを検討すべき。
202: (ﾜｯﾁｮｲ b96e-ofsu) 2023/06/15(木)09:00 ID:K4jCDX8M0(1) AAS
シビアな状況でC++が使えないやつがCならOKなはずはない
203(1): (ｱｳｱｳｳｰ Sadd-g1CP) 2023/06/15(木)10:11 ID:dLjlwX4ma(1) AAS
>>199
何が判ってないのかが判ってないパターンだな
まともな解答もらってても何が正しいのか(なぜ正しいのか)
すら判断出来なさそうなレベル
解答者に失礼
上下前次1-新書関写板覧索設栞歴
あと 799 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.011s