[過去ﾛｸﾞ] C++相談室 part164 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
159: (ｱｳｱｳｳｰ Sac5-Rr/m) 2023/06/05(月)09:40 ID:ejs/048Ga(1) AAS
1e-3
0.4E+5
どうせ . とか + とか - とか e とか E が数字の後ろに来たらエラーにする糞オレオレ関数の出来上がり
160: (ｱｳｱｳｳｰ Sac5-+LPJ) 2023/06/05(月)18:46 ID:QlKvcf+ua(1) AAS
fortran爺が1e-3を1-3と書いて送ってくるの辛い
161: (ﾜｯﾁｮｲ 0128-w4Nq) 2023/06/05(月)22:24 ID:yTJt/rkc0(4/4) AAS
charやwchar_tのうちは文字数くれたら別段間違うことは無いはず……
162: (ﾜｯﾁｮｲ 916e-UlWg) 2023/06/06(火)05:24 ID:sRXlIYgz0(1) AAS
0xe5a3ec05p-10
163: (ﾗｸｯﾍﾟﾍﾟ MMe6-aBKW) 2023/06/07(水)18:16 ID:yJ6NJbScM(1) AAS
regex 使って、全角半角タブはreplace
しつつも、正規表現で、数字だけ残して
ってしたらいいのでは
164: (ﾜｯﾁｮｲ 7d02-lxw5) 2023/06/07(水)19:51 ID:Y1IkEaDo0(1) AAS
ファイル名で並び替えるとき数字を文字列じゃなく数として判断して並び替えるの便利だよね。StrCmpLogicalWみたいなの
165: (ﾜｯﾁｮｲ eefb-dBHf) 2023/06/07(水)20:17 ID:Wtu+kJ5G0(1) AAS
digitntegerみたいな関数なかったっけ
javaと混同してるかもしれん
166: (ﾜｯﾁｮｲ eed6-hc5i) 2023/06/07(水)20:48 ID:DVJV7mYE0(1) AAS
大文字小文字とか小数とか半角全角とか漢数字とかあるから闇が深い
167: (ﾜｯﾁｮｲ e54e-sceX) 2023/06/07(水)21:25 ID:nzVrXgF60(1) AAS
アンダーバーの位置関係も結構罠だよね
文字コード的には 大文字＜アンダーバー＜小文字 だから
168: (ｵｲｺﾗﾐﾈｵ MMe9-sceX) 2023/06/07(水)23:13 ID:ZHL7BfYmM(1) AAS
言語+コンパイラの仕様が拡張してるのにライブラリは貧弱なまま
自己流に実装してしょうもないバグが紛れ込む
関係ないけどstd::stodはC言語版と微妙に仕様が違うのだろうけどそんなの調べてない
169: (ﾜｯﾁｮｲ 469a-D/IE) 2023/06/08(木)00:14 ID:mm4FKY9+0(1) AAS
例えばstodが解釈できる数値表現を正規表現でも解釈したいと思ったらどうしたら
170: (ｱｳｱｳｳｰ Sac5-tVFH) 2023/06/08(木)11:09 ID:rxjbLVG0a(1) AAS
仕様の不備は運用でカバー
171(1): (ﾜｯﾁｮｲ b901-1DxI) 2023/06/09(金)00:34 ID:Y9bb1A2p0(1/2) AAS
std::sort (std::execution::par, v.begin(), v.end());
上記で並列ソートできるとのことですが何並列なんでしょうか?
もし環境に合わせて良きに計らってくれるのなら
その良き並列数を取得する関数などありますか?
172: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e53e-N/Lw) 2023/06/09(金)01:32 ID:vjFKJkM00(1) AAS
>>171
詳細は言語仕様では規定されていない。
リソースが不足していれば並列化されないこともあり得る。
並列化は大抵の場合に OS のサポートが必要だし
どういうサポートがあるかわからんので言語として明瞭な規定を決められない。
並列化される保証はないのにデータ競合が発生しないように実装するのは
プログラマの責任なので若干の理不尽さを感じなくもないが
省1
173(1): (ﾜｯﾁｮｲ 6293-1rII) 2023/06/09(金)07:16 ID:bBOCrSG+0(1) AAS
週末のレイトレーシングで1-17あたりをマルチスレッドにしてみたんだけど、ubuntu上でg++やインテルコンパイラだとスレッド数を増やすと逆におそくなるんです。windows上でvisualstudioでコンパイルすると、望み通りスレッド数を増やすほど速くなりました。何でなんでしょう？
174: (ﾜｯﾁｮｲ eef2-2RXP) 2023/06/09(金)08:07 ID:e2G6/2re0(1) AAS
>>173
>週末のレイトレーシングで1-17
全く意味がわからないんだが？
>何でなんでしょう？
お前のコーティングのせいじゃないか？
175: (ﾜｯﾁｮｲ 916e-aXLw) 2023/06/09(金)08:18 ID:m5f79nsG0(1/2) AAS
gccはね・・・どうも平行／並列処理には本気じゃないところがある
たとえばstd::execution::parなんか真面目にやらんかこらって言いたくなる
176: (ﾜｯﾁｮｲ 916e-aXLw) 2023/06/09(金)08:19 ID:m5f79nsG0(2/2) AAS
無料なので強く出られないけどね
177: (ﾜｯﾁｮｲ b901-1DxI) 2023/06/09(金)11:49 ID:Y9bb1A2p0(2/2) AAS
皆さんレスを有り難うござます
うちはstd::execution::parで効果絶大です
$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
178: (ﾜｯﾁｮｲ b901-mwg1) 2023/06/09(金)22:45 ID:uysUozYZ0(1) AAS
なるほどなあ
179: (ﾜｯﾁｮｲ 13ad-2rqm) 2023/06/10(土)02:07 ID:oiDhCbH60(1) AAS
EASTLが久しぶりにバージョンアップしたね
180: (ﾜｯﾁｮｲ c901-7YjN) 2023/06/10(土)07:02 ID:kaZ6v5kb0(1) AAS
ほう！いいね
181: (ﾜｯﾁｮｲ b16b-q0yD) 2023/06/14(水)07:54 ID:/jeWb7sY0(1/2) AAS
time コマンドで調べたメモリの使用量 (max resident set size) が理論値よりも多くて、原因を特定するためにコード内の各箇所でその時点でのメモリ使用量を出力できたら良いなと思います。
実行環境は Linux なのですが、どのようにするべきでしょうか？
182(8): (ﾜｯﾁｮｲ b16b-q0yD) 2023/06/14(水)08:43 ID:/jeWb7sY0(2/2) AAS
あとメモリに関連した質問で、例えばめちゃデカい std::vector を要素数 1 に resize しても capacity はめちゃデカいままですよね？
STL コンテナ以外にも、大きいメモリが割り当てられてるオブジェクトを使用後に破棄したいというケースがよくあります。
最も簡単なやり方は関数とか局所的なスコープとして切り出すことかと思いますが、他に、オブジェクトに割り当てられているメモリを手動で解放する方法があったら教えてください。
183(2): (ｽﾌﾟｯｯ Sd33-5Oyn) 2023/06/14(水)08:49 ID:Xd2fVcpxd(1) AAS
/proc/self/stat というファイルを覗きに行くか、
getrusage というシステムコールで取得することになるかな
184(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c13e-2rqm) 2023/06/14(水)09:19 ID:O3itrano0(1) AAS
>>182
そのために shrink_to_fit がある。
詳細は実装依存なので何もしない関数であっても仕様に反しないけど
常識的には各実行環境で効率的に動くように実装されるので
まずは試してみても損はないと思う。
アロケータを自作してもあまり制御できないんよね。
アロケーションが必要になったらコンテナからアロケータが呼ばれるという
省3
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
何が判ってないのかが判ってないパターンだな
まともな解答もらってても何が正しいのか(なぜ正しいのか)
すら判断出来なさそうなレベル
解答者に失礼
204(1): (ﾜｲｰﾜ2 FF63-pDI4) 2023/06/15(木)10:56 ID:kyFBXozFF(1) AAS
他所スレで同じ様な流れが
>742
質問の仕方が悪いだけwww
欲しい情報を引き出すには一定以上の質問能力が必要
>743
質問の仕方が重要なのはその通りだけど
ここで問題にしてるのは自分が詳しくない領域では質問の仕方が悪かったかどうかも分からないってことでしょうよ
省3
205(1): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/15(木)12:02 ID:J1cG0ikp0(2/3) AAS
>>201
いや、ポインタのサイズなんて全く気にしてない。
質問は、メモリの解放をコンテナに任せるならわざわざスマポで持つ意味ないよね？ ってこと。
で、コンテナに任せるというのは元の質問(>>182)への回答に全くなってないよね？ ってこと。
(その理由は>>184,200様の書いてくださってる通り)
つーかお前が何も分かってないのは>>195でreset()しなくて良いとかほざいてる時点でお察し。
>>203-204
省5
206(1): (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV) 2023/06/15(木)12:29 ID:QcI//Xn+M(1) AAS
>>205
コンテナのsmart ptrの扱いは調べた？
コンテナの要素とポインタの参照先の違いについて根本的な誤解がありそう。
vectorはまだ構築していないインスタンス用のメモリ領域を予約するけど、smart ptrはそんなことしないよ。
vector<smart ptr>もsmart ptr の予約はするけど、smart ptrの参照先インスタンスの予約はしない。
207(1): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/15(木)13:15 ID:J1cG0ikp0(3/3) AAS
>>206
だから、結局任意のコンテナ、クラスに対してスコープ内でメモリを解放する方法は？
new で生ポを持って delete するか、スマポを持って reset するかだろ？
> vectorはまだ構築していないインスタンス用のメモリ領域を予約するけど、smart ptrはそんなことしないよ。
そりゃそう。
ゆえに、メモリを間違いなくリリースしたいなら reset すればよいのですねと>>190で述べている。
それで終わりなのにお前と来たら reset は不要だの元のコンテナの挙動に任せるだの、論旨を全く理解してないとんでもレスばっかり。
省3
208: (ﾜｯﾁｮｲ 8bfb-Xx8j) 2023/06/15(木)14:56 ID:M9bt3STi0(1) AAS
186でも言ってるがstaticもしくはvirtualでデストラクタ使えよ
それがシンプルで高速で1行も無駄のない設計な
209: (ﾜｯﾁｮｲ 01c9-6bUV) 2023/06/15(木)15:01 ID:B8g22vaD0(1) AAS
182の
>最も簡単なやり方は関数とか局所的なスコープとして切り出すことかと思いますが
がコンストラクタで確保してデストラクタで消す話というのはわかってる上で
>他に、オブジェクトに割り当てられているメモリを手動で解放する方法があったら教えてください。
なんじゃないの？
そんなものは無いっていう答えもあるにはあるけどサ
210: (ﾜｯﾁｮｲ 13f0-8sUu) 2023/06/15(木)18:41 ID:QIwD56Ju0(1) AAS
最近IPP触り始めたんですが全部飽和演算で面食らってます
Modulo関数は無いんですか？
211(2): (ﾜｯﾁｮｲ fb8c-jufV) 2023/06/15(木)21:00 ID:W1C5TI4i0(1) AAS
>>207
ああ、ごめん。めっちゃデカイインスタンスのvectorじゃなくて、めっちゃデカイvectorね。
それなら実装依存だけど>184か、>192とか参照無効化の制限とかコピーコストとかあるけど>189。189はsmart ptrにしとけば実用上問題ないかね。vectorのイテレーターは保存するものじゃないし。
212(1): (ﾜｯﾁｮｲ c14e-8sUu) 2023/06/15(木)21:28 ID:3cvhbwG+0(1) AAS
実際の所、vectorならclear()→shrink_to_fit()でメモリが開放されないこってありうるの？
213: (ﾜｯﾁｮｲ d17c-sLM4) 2023/06/15(木)22:10 ID:usfnoco+0(2/2) AAS
規格上はshrink_to_fit()にメモリ解放する義務はないし、実装定義で何やっても自由（capacityを増やすような真似だけは禁止）
shrink_to_fit()がなんにもしない実装でも一応規格準拠になる
そんな糞みたいな実装が実在するかは知らない
214: (US 0H0b-q0yD) 2023/06/16(金)02:13 ID:PZdB0bgSH(1) AAS
>>211
はい結局一人だけ違う話してた
ハァァ～～～～～（クソデカため息）
215(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ c13e-2rqm) 2023/06/16(金)11:31 ID:QEmhRLek0(1) AAS
>>212
基本的には効率的に実装されるものだと信じて良いと思うが
どういう実装が効率的であるかは実行環境の事情による。
たとえばメモリ管理がページ単位というのは普通のことだし
その場合にページ単位より細かく確保したり解放したりしても非効率になる。
常に何もしないというような実装はあまりないと思うけど
解放するほうが非効率だと考えられる状況では
省2
216(1): (ﾜｯﾁｮｲ 01c9-6bUV) 2023/06/16(金)12:08 ID:nWXjt7Za0(1) AAS
capacityと OS側からみた空きメモリはまた別かもしれんわけで
アロケーターがOSからじかに要求してる場合もあれば
OSへの要求回数を減らして内部でプールしてやりくりしてるのもあるし
制御したいレイヤーによっては全部自前でやるしかない という落ちにも
217: (ﾜｯﾁｮｲ c14e-8sUu) 2023/06/16(金)12:26 ID:B2wRJ7jC0(1) AAS
>>215
まぁ、細かい単位のメモリだったら、実際に開放されているかどうかなんて、ほとんど動作に影響しないとも言えるしね
（未初期化変数の不具合が発覚しづらい、くらいか）
とりあえずshrink_to_fitを呼んでおいて、細かいことは気にしないのが一番かもしれないw
218: (ﾜｯﾁｮｲ 934f-q0yD) 2023/06/16(金)12:46 ID:H6XPX5qB0(1) AAS
「STLコンテナ以外にも」という文言が読めてない文盲さんたちがvectorの話ばっかしててワロ
219: (ﾜｯﾁｮｲ d969-2rqm) 2023/06/16(金)15:41 ID:KX+TErXo0(1) AAS
「STLコンテナ以外にも」はSTLコンテナも含むということ
STLコンテナの話をしても何もおかしくない
220: (ｱｳｱｳｳｰ Sadd-g1CP) 2023/06/16(金)15:43 ID:ly+Q1cW8a(1) AAS
いつものことだが
ほんの最初の数レスで終わってるのに
どうでも良い脱線ほど盛り上がってgdgdレスでスレが延びる
221: (ｱｳｱｳｳｰ Sadd-Xx8j) 2023/06/16(金)15:46 ID:/DJegtL/a(1) AAS
ほんそれ
回答終了してんのにちんこかゆい
222: (ｽﾌｯ Sd33-pDI4) 2023/06/16(金)15:49 ID:YNpYq5+wd(1) AAS
>>182 良く読むと
>STL コンテナ以外にも、大きいメモリが割り当てられてるオブジェクトを使用後に破棄したいというケースがよくあります。
>最も簡単なやり方は関数とか局所的なスコープとして切り出すことかと思いますが
いやいやそもそも「関数とか局所的なスコープ(つまりautoだろ？stackだろ？)で大きいメモリ確保しようなんて思うな」って話なんだよな
223(2): (ﾜｯﾁｮｲ e95f-2rqm) 2023/06/16(金)16:09 ID:qgM8i0iT0(1) AAS
ローカルなvectorを置けばヒープ確保されるので「つまりautoだろ？stackだろ？」は
また何か誤解してる人が来たなとしか。
224(1): (ﾜｯﾁｮｲ 219b-q0yD) 2023/06/16(金)16:49 ID:ybGonaVE0(1) AAS
reset要らないとか言ってる奴らは結局何なん
225(1): (ﾃﾃﾝﾃﾝﾃﾝ MMeb-jufV) 2023/06/16(金)19:32 ID:yx9ngvFiM(1) AAS
>>224
結論は>211にまとめといた。
resetは要らん。
226(1): (ﾜｯﾁｮｲ 92dc-gfWY) 2023/06/17(土)08:56 ID:3MnK6eEg0(1) AAS
>>223
「STLコンテナ以外にも」という文言が読めてない文盲さんたちがvectorの話ばっかしててωωω
227(1): (ﾃﾃﾝﾃﾝﾃﾝ MM96-Axrn) 2023/06/17(土)10:36 ID:koF9X0k9M(1) AAS
>>226
「大きいメモリが割り当てられてるオブジェクトを使用後に破棄したい」なら
>185か>187。
>187はunique ptrの置き場所と解放タイミングによって解放の仕方が違って、自動変数にして関数やスコープから抜けるタイミングで解放するなら手動操作不要、vectorなどのヒープに置くとかスコープの終わり前に解放したいとかならreset()とかvectorの要素削除とかで手動解放。
いずれにしても、自動変数に巨大インスタンスを考え無しに置くのは悪手で、そのオブジェクトがスタックに巨大データを置かない(ヒープ等に置く)ことを確認してからにしたほうがいい。
228: (ﾜｯﾁｮｲ 6128-l8k0) 2023/06/17(土)15:30 ID:S+64vkUJ0(1/4) AAS
>>216
vectorのcapacityはそのvectorが氏ぬかcapacity縮小アクションが生じない限りvector固有に占有されるから
capacity（のうちsize()を超える分）と OS側からみた空きメモリはまた別でｹﾃｰｲ……
一方malloc()がOSからｹﾞｯﾄしたメモリをOSに返さずにいるのはOS側からみた空きメモリではないにしろ
同一プロセス内の他のオブジェクトの構築に使えるのだから空きメモリのうち
これすらもOSに返したいということならこの流れの中で現状答えがでていないｷﾓﾇ
229: (ﾜｯﾁｮｲ 6128-l8k0) 2023/06/17(土)15:31 ID:S+64vkUJ0(2/4) AAS
まあしいて言えばプロセスを一旦exitして再立ち上げ？
230: (ﾜｯﾁｮｲ 6128-l8k0) 2023/06/17(土)15:45 ID:S+64vkUJ0(3/4) AAS
普通に作ったら（コードで明示的に直接OSのAPIでメモリを分捕って解放とかしない限りは
プロセスのprivate bytesはプロセスが氏ぬまで増えることはあっても減ることは無いという印象、
231(2): (ﾜｯﾁｮｲ 7d9b-trtU) 2023/06/17(土)16:27 ID:5e+acAEX0(1) AAS
>>225
スマンまじで理解できないのだけど、なぜvectorに限った話をしてるの？
232: (ﾃﾃﾝﾃﾝﾃﾝ MM96-Axrn) 2023/06/17(土)19:22 ID:mYwWSuEFM(1) AAS
>>231
巨大インスタンスは>227
233: (ﾜｯﾁｮｲ d9ab-trtU) 2023/06/17(土)19:29 ID:HtrmHz3i0(1) AAS
回答者のレベル低いな～～～
こんだけダラダラ続けて、結局質問者>>182が>>190で早々に結論づけてることをリピートしてるだけｗ
234: (ﾜｯﾁｮｲ 69f0-J7ro) 2023/06/17(土)19:54 ID:9hSxsWrs0(1) AAS
アロケータ気に入らないなら自作くらいしろよポンコツ
なにもかもSTLに頼りやがってそれでPGやってるつもりになるなよ
235: (ﾜｯﾁｮｲ 6128-l8k0) 2023/06/17(土)20:19 ID:S+64vkUJ0(4/4) AAS
人類には早すぎた話題また……
236: (ｵｲｺﾗﾐﾈｵ MM91-L1I+) 2023/06/17(土)23:14 ID:H9lc23A5M(1) AAS
次世代の人は便利に使いこなしてるかより簡素になった仕組みを使うのだろう
237(1): (ﾜｯﾁｮｲ 655f-rdTE) 2023/06/18(日)03:00 ID:GIMFAM+a0(1) AAS
>>231
コンテナの種類を問わない一般的な方法なんてものはないからじゃないですかね
238(1): (ﾜｯﾁｮｲ 8101-1tDD) 2023/06/18(日)21:04 ID:VwYqKwPk0(1/4) AAS
以下のコードでaccumulateのとこでコンパイルエラーが起こります
何故か分かります?
#include <iostream>
#include <array>
#include <deque>
#include <exception>
#include <numeric>
省19
239(1): (ﾜｯﾁｮｲ 515f-C6j3) 2023/06/18(日)21:45 ID:UCXMUPHB0(1) AAS
>>238 エラーメッセージ見ればたぶん分かる。
上下前次1-新書関写板覧索設栞歴
あと 763 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s