C言語なら俺に聞け 153

レス数が950を超えています。1000を超えると書き込みができなくなります。
1デフォルトの名無しさん (ﾜｯﾁｮｲ 5fba-LL4R)
垢版 |
2019/08/17(土) 23:02:42.00ID:tN5mSQYg0
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
※前スレ
C言語なら俺に聞け 152
https://mevius.5ch.net/test/read.cgi/tech/1560763630/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
2020/01/01(水) 00:17:51.96ID:DMjscTxe0
>>871
そういやそうだね
ローカルに作って環境保存にmemcpyした覚えないから代入できるのか
色々忘れてるわ
2020/01/02(木) 09:27:06.04ID:9VSdJ8Nx0
ポインタを受け取る関数先頭では必ずnullチェックを行うコーティングルールが有るのですが
malloc失敗したポインタをそのまま渡した時ぐらいしか使い道が思い付きません…
2020/01/02(木) 09:28:21.50ID:mLLKwKl50
freeしたときに0入れるルールもあるんじゃないのそれ
2020/01/02(木) 09:37:24.05ID:+UNtt4nj0
>>873
杓子定規に適用したら形だけの無駄なチェック処理の典型だね。
上位レイヤとの境界のような意味のあるところだけなら現実的だけども。
2020/01/02(木) 09:53:01.45ID:qr+4fHWP0
仕様としてnullを許可する関数ではチェック不要としているのかあるいは一律に
null渡し禁止としているのかで評価は変わりそうだが。
2020/01/02(木) 10:24:26.88ID:Lvb+z/bpM
get_state()みたいな関数があって失敗時はnullを返す。それを知らずに別の関数に戻り値を直接渡してしまったとか、nullが誤って渡されるケースなんていくらでもあると思うが。

873が超天才でそんなミスは絶対ありえないとしても、他人のコードやドキュメントが間違ってる可能性もある
2020/01/02(木) 10:39:04.82ID:Dgcghn810
Player*とEnemy*を取るRPGのバトル関数で
どちらかが死んでたらplayer->attack()関数は盛大に失敗する

この時の当該playerは消滅したわけでは無いが
enemyはメモリ上から消えている

ついでにこのattack関数が実は関数ポインタに付けられたプレイヤーのスキルだった場合、
attackがカラッポだと、徒手空拳になるか防御するか何もしないか、何故か敵味方全員が即死していきなりエンディングが始まるかのどれかになる
2020/01/02(木) 11:31:53.70ID:FHRar1Ix0
安全性を取るならいついかなる時もNULLチェックは行うべき

だがそもそもパフォーマンス至上主義だから
Cという太古の言語を危険を冒してまで使っているということを考えると微妙

パフォーマンスが重要でないならCを使っていることからして論外
880デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb6-vILD)
垢版 |
2020/01/02(木) 11:38:58.14ID:ZKet2vMyM
成否を含んだtupleを渡し実行時に判別、式全体を読み飛ばす粒度の小さい隠れた分岐構文みたいなの有ればいいのにねー
成否要素だけの反転は !!tulpevalue みたいな感じで

c言語の仕事じゃないだろうしそもそもtupleなんて持ってないし
うんこマが技巧駆使してわけわからんコード書くツールになるだけかもしれんし弊害いろいろ思いつくけど
2020/01/02(木) 11:39:55.37ID:+UNtt4nj0
>>878
召喚された悪魔が鼻から出てきて世界滅亡エンドも追加しといて。
2020/01/02(木) 12:33:18.19ID:LqVuN/CI0
>>879
Assertマクロとかでいいだろ
テストとかで引っ掛けるという実利に加えて「nullなんて渡すんじゃねーよボケ」と言うのを表明する意味もあるし
2020/01/02(木) 12:38:16.19ID:wpzQe/fn0
nullに意味を持たせないプログラムなら、
null checkしないと落ちる環境ならする意味ないんじゃね
884デフォルトの名無しさん (ｱｳｳｨﾌ FFa5-p4uH)
垢版 |
2020/01/02(木) 14:45:20.78ID:fRqsjLPxF
Release build だと assert 消えるって知らない人意外と多いんですね
2020/01/02(木) 15:06:10.66ID:+UNtt4nj0
>>884
消えるって知ってるからassertにしろっていう意見なんだろう
886デフォルトの名無しさん (ｱｳｳｨﾌ FFa5-p4uH)
垢版 |
2020/01/02(木) 15:47:44.05ID:NYIo0K4bF
その意見を完全にスルーしてコメントしてる人がいるよね
2020/01/02(木) 16:46:49.09ID:YqaismelM
>>886
誰のことを言ってるの？
2020/01/02(木) 19:01:18.56ID:/MiE1Mk20
ぬるぽ
2020/01/02(木) 19:06:06.49ID:LbxbUX1g0
がっ！
2020/01/02(木) 19:09:50.49ID:ZQF68/R30
酷い自演を見た
2020/01/02(木) 19:13:07.31ID:LbxbUX1g0
ジ・エンド！
2020/01/02(木) 19:21:03.30ID:koJayFbu0
assertを本番環境に持ち込むべきと
主張する痛いやつが昔いたが
奴は今どうしてるかな
2020/01/02(木) 19:35:59.09ID:VmmTWzwp0
C++11 の static_assert は便利なんですけれどもね…これ、C に入らないかな…
assert も static_assert と同じ用途・考え方で使うべきものかと思いますね
2020/01/02(木) 20:05:40.84ID:koJayFbu0
Cにもstatic_assertか
考えたこともなかったが
確かにあったらよさそうだな

もういじるなってのが
俺の基本だが
追加に賛成できる珍しい例だ
2020/01/02(木) 20:45:56.41ID:LqVuN/CI0
>>892
> assertを本番環境に持ち込むべきと
> 主張する痛いやつが昔いたが
> 奴は今どうしてるかな
本番用はいちいちassert外してるのか？w
2020/01/02(木) 20:51:06.32ID:hML6I4krM
おいおいおい
2020/01/02(木) 20:59:07.77ID:tgRnMcUUM
>>895
assert は Debug ビルドのときだけチェックを行う実装になってるのが普通
2020/01/02(木) 21:59:00.14ID:LqVuN/CI0
>>897
だから>>892が意味不明なんだけどw
2020/01/02(木) 22:07:28.72ID:tgRnMcUUM
>>898
リリースビルドで有効な assert を用意するだけだろ
何が不思議なの？
2020/01/02(木) 22:08:11.77ID:SH5dgl7q0
本番環境に持ち込むべき
影響出ないんだから
こういうことでは
901デフォルトの名無しさん (ﾌﾞｰｲﾓ MM6d-vILD)
垢版 |
2020/01/02(木) 22:22:27.18ID:oLW+m36dM
深いところで拾ったエラーを浅層に戻して対応する必要がなく「ダメよ」と述べ落ち許されるプログラムならば
assert残すのも有りよね
実際#ifdef DEBUGで包んでるだけだし
imagemagickなんかも引数チェックを通った後の個々パラメータ内で不整合出たらassertでメッセージ流して落ちるし
2020/01/02(木) 22:27:00.54ID:VmmTWzwp0
>>900
assert が発動してアプリが止まるのは終わり方として最悪だとおもいますよ
もし assert が発動する可能性があるんだったら assert ではなくて、きちんとしたエラー処理を記述するべきなのでは？

assert って辞書をみると「断言」「主張」「出しゃばり」くらいの強い意味ですね
私は assert はコメントの一種一様態として使います＝>>893
2020/01/02(木) 22:29:39.05ID:LqVuN/CI0
>>899
えっ？
>>892が正しいという主張？
まあ>>901みたいな考え方もあるだろうけどさ
2020/01/02(木) 22:30:49.81ID:+UNtt4nj0
>>901
assertに引っ掛かったときの挙動は置いとくとしても、assertの処理内容や頻度によっては実行時コストが問題になる可能性も無くはないから、単純にやってよしとはならないと思うぞ。
905デフォルトの名無しさん (ﾌﾞｰｲﾓ MM6d-vILD)
垢版 |
2020/01/02(木) 23:00:40.06ID:oLW+m36dM
効率厨はログ出力を見れるGNUemacsのeshell辺りででもwindowsプログラム立ち上げてみ？
プロプラ、オープンソースに関係なく大半のリリースビルドが膨大な出力を出しっパになってる現状に絶望するだろうから
2020/01/02(木) 23:03:44.94ID:SH5dgl7q0
>>905
その環境で動かすと、プリプロセッサ段階で消去されているはずのデバッグ文実行結果が見れる様になるんですか？
2020/01/03(金) 01:04:07.68ID:kXvb5Zcs0
>>905
処理内容や頻度によって実行時コストが問題になる可能性があると言っただけで効率厨扱いとはw
既存プログラムでログを大量に出しているからと反論しているが、だからそれがどうしたというのだ？ ログを出しても性能的に問題ない範囲、頻度、量で出しているだけだろう。
2020/01/03(金) 03:24:18.79ID:RUwUdhzc0
>>907
assertion は「コメントの一種」という私の立場では、重い assertion の罪は軽い、許容できると感じています
2020/01/03(金) 08:42:01.33ID:3k7MKqlh0
組み込みだとタイミング込みで評価するから
ビルドを切り替えられないんだよね

assertはログだけ出すようにしてるが
ウォッチドッグを効かすってのもありかな

起こり得ないところで使うってのはその通り
2020/01/03(金) 14:46:00.81ID:SORF6jE90
ロケット打ち上げ２秒後でassert出ても意味が無いな
そのまま大爆発だ

衝突する0.5秒前でassert出ても意味が無い
時速90kmでそのまま衝突だ
2020/01/04(土) 21:11:48.66ID:rVQt0/h/0
uint64_t を配列の添え字に使えるかどうかって何か規格はありますか？
手元の環境は unsigned int のようなんですが、gcc/ming32-x64
2020/01/04(土) 22:03:02.52ID:hAlxX0tq0
uint64_tどころかポインタも使えるぞ
2020/01/04(土) 22:09:03.08ID:49Uce+wI0
>>911 何を見て「unsigned int のよう」と言っているの？
2020/01/04(土) 22:28:50.08ID:HbavYk5j0
>>911
ISO/IEC 9899:2011 (E)

6.5.2.1 Array subscripting
1 One of the expressions shall have type "pointer to complete object type", the other
expression shall have integer type, and the result has type "type".

7.19 Common definitions <stddef.h>
size_t
which is the unsigned integer type of the result of the sizeof operator;

どこにもunsigned intに限定するとは書いてねえぞ
unsigned integerと書いてあるのが
おまえはunsigned intに見えるのか？
2020/01/04(土) 23:21:44.72ID:rVQt0/h/0
>>912-914
コメントありがとうございます
uint64_t と int をいいかげんにチャンポンに使っていたための祟りに襲われてしまっているところでして…
a[i] = *(a + i)
を考えれば、i が int = int32_t, であろうと uint64_t であろうと、うまくやってくれると予想できますね
2020/01/05(日) 12:03:03.18ID:buL7vvPT0
そこは
[a]i = *(a+i)
だろ
2020/01/05(日) 12:18:38.35ID:JLxpDEWT0
>>916
それを言うならi[a]だ
ドヤるなら動作確認くらいしてからにしろ
そもそも後置演算子の[]が[a]iなわけねえだろ
2020/01/05(日) 12:50:09.43ID:+e7zv/8B0
STLの配列の添え字は、std::size_tと同じ範囲が使えるように思う。
このstd::size_tには長さの制約は多分ない。
常識的に考えて、32ビットのプログラムで64ビットの配列を使うことはあまり現実的ではない。
なので、std::size_tの長さはNビットプログラムにフィットするようにコンパイル時にスイッチされる。はず。
2020/01/05(日) 12:58:44.11ID:JLxpDEWT0
思うんじゃなく確認しろ、多分とか寝言ぬかしてねえで

N4713

26.2.1 General container requirements
Table 83 ? Container requirements
X::size_type
size_type can represent any non-negative value of difference_type

26.3.8.1 Class template deque overview
// element access
reference operator[](size_type n);
const_reference operator[](size_type n) const;
920デフォルトの名無しさん (ﾗｸｯﾍﾟ MM61-Gr30)
垢版 |
2020/01/05(日) 13:25:51.85ID:qO+R3XJXM
教官湧いててワロタ
921デフォルトの名無しさん (ﾜｯﾁｮｲ 9901-8/Ff)
垢版 |
2020/01/05(日) 13:55:25.64ID:+b/hvkzN0
教官使い倒そうぜ。
タダだし。
2020/01/05(日) 15:43:26.81ID:Apdi0tl00
具体的な規格の文面を引用して示してくれるのは有難いことでしょ。
手元にPDFとかで持ってても場所を見つけるのが苦労で諦めることが多いし。

size_type can represent any non-negative value of difference_type
の部分を見ると size_t の大きさは difference_type の大きさに依存する、
少なくとも difference_type の正の範囲より広い、で合ってるかな。
ならば difference_type の範囲はどうなってるの？ って具合に
疑問の先が移動するね。答えに近づいたけれど到達はしてない感じ。
923デフォルトの名無しさん (ｱｳｱｳｴｰ Sa4a-p4uH)
垢版 |
2020/01/05(日) 20:35:48.07ID:eK7nc1Ssa
添え字は size_t が良き
2020/01/06(月) 01:11:40.15ID:eLfBkWc60
俺は符号付のほうが好きだな
符号なしって扱いがめんどくさい
2020/01/06(月) 02:32:02.65ID:4dvQB2Dx0
メモリアドレスに符号はない
2020/01/06(月) 02:58:19.15ID:5D5lgCny0
だがptrdiff_tは符号付きだ

絶対アドレスに符号はなくても
オフセットには符号がある

配列の添え字はオフセットなわけだが
それでもsize_tであるべきか？
2020/01/06(月) 03:02:12.43ID:YD66nlsEx
BSTRのように、ときどき境界より前を参照したいことはあるかな
2020/01/06(月) 03:05:00.95ID:5D5lgCny0
free()とかマイナスオフセットなしでどうやって実装するんだよ、とかね
2020/01/06(月) 10:54:17.16ID:zGikmXAV0
マジ？
2020/01/06(月) 13:04:19.40ID:UJayP8xu0
いつになるか激的アーキテクチャの進化でも迎えない限り
64bitでmsbまで使い切る正数アドレスなんて無いから
相対はヌルチェック＋自動整数変換に頼っときゃいいんじゃね
fseek/off_tはなんかもやもや放置気味？誰が完全な解決をもたらすのか
931デフォルトの名無しさん (ﾜｲｰﾜ2 FF8a-p4uH)
垢版 |
2020/01/06(月) 19:21:49.21ID:OSGVopulF
変なセグメント跨がないだけまだマシ
2020/01/06(月) 20:57:41.21ID:eLfBkWc60
俺はCからプログラミング言語は学んだが、Cから入って正解だったな
あの苦難の道を思えばどれも大したことはない
C++とRustを除けば
933デフォルトの名無しさん (ﾜｯﾁｮｲ 42ad-cEPd)
垢版 |
2020/01/07(火) 00:34:22.49ID:MpiZXKP+0
>>925
しかし俺の心の中にあるのだ。
2020/01/07(火) 10:47:03.55ID:YpzCpCxL0
君はディラックの海に飲み込まれている
2020/01/07(火) 16:39:38.02ID:Hzpz4xj50
なんだっけそれ
どっかで聞いたことあるんだが思い出せない
2020/01/07(火) 16:45:14.58ID:3/Noa7Ai0
>>935
熱素やエーテルみたいな架空の物質モデル論のひとつ
2020/01/08(水) 23:52:10.09ID:2EljHN2O0
>>936
アニメで引用されてた気がする
エヴァだっけ？ディラックの海ってリツコが言ってたような
2020/01/10(金) 20:53:06.96ID:z03T2m7q0
2019年に成長したプログラミング言語ランキング、第1位は？　2020/01/10 09:18　後藤大地
https://news.mynavi.jp/article/20200110-952052/

TIOBE Softwareがこのほど、2019年に最もインデックス値を伸ばしたC言語が2019年のプログラミング
言語・オブ・ザ・イヤーに輝いたと伝えた。第2位はC#で、これにPythonとSwiftが続いている。

C言語のインデックス値が伸びた理由として、IoTおよび小型のインテリジェントデバイスにおいて需要が
高いためだという。C言語は短時間で習得が可能な上、すべてのプロセッサにおいてCコンパイラを利用
できる。TIOBE Softwareは、こうした状況がC言語のインデックス値上昇を招いたのではないかと分析
している。

発表された2019年におけるインデックス増加率と順位は次のとおり。[順位]プログラミング言語(増加率)
[1]C(+2.4%)、[2]C#(+2.1%)、[3]Python(+1.4%)、[4]Swift(+0.6%)、

2019年のプログラミング言語・オブ・ザ・イヤーは、2018年に引き続きPythonが受賞するだろうと考え
られていた。これは、Pythonが2018年に入ってから長期にわたって増加傾向を維持しているためだ。
しかし、2019年はC言語の増加率がPythonを超えて1位となった。C言語は2016年に一気にインデッ
クス値を下落させており、2017年後半から逆に増加に転じている。ずでに減少以前の水準まで戻って
きており、今後も同様のペースで増加を続けるかどうかはわからない。

仮に、今後も同様のペースでC言語の増加傾向が続いた場合、JavaとC言語のポジションが逆転して
C言語が首位になる月が出てくる可能性もある。しかし、過去の動向として、JavaとC言語は推移が同調
する傾向が強く、Javaが第1位でCが第2位という順位のまま推移する可能性もある。(中略)

TIOBE Programming Community Index (PCI)は、複数の検索エンジンの検索結果から、対象となる
プログラミング言語がどれだけ話題になっているかをインデックス化したもの。2020年1月におけるイン
デックスは次のとおり。

1月TIOBE Programming Community Index / 円グラフ
https://news.mynavi.jp/article/20200110-952052/images/002.jpg
2020/01/10(金) 23:49:08.97ID:dnkcugEB0
＞C言語は短時間で習得が可能
お、おう
2020/01/10(金) 23:54:40.89ID:g1glT3r10
Cの文法や標準ライブラリがコンパクトだし覚えるべき概念も少ないのは間違いない
2020/01/11(土) 00:21:52.03ID:tkcR1Lp+0
覚えることは少ない(簡単ではないけど)
2020/01/11(土) 00:57:34.91ID:NtF2wljx0
オブジェクト指向とポインタならポインタの方がラク
それにメモリに沿ってるので分かり易い
2020/01/11(土) 03:00:34.20ID:3RtWHygz0
ポインタとオブジェクト指向は別物だからな
そもそも比べるのがおかしい
2020/01/11(土) 07:57:38.18ID:qIT1Gaoe0
考えようによっては、ポインタとメモリの関係を理解してしまえば、
Cほど単純な言語とその標準ライブラリも他にないからなぁ
2020/01/11(土) 09:58:53.91ID:AmOO0hUd0
まあ組込みだとCでいいと思うけどテンプレとかも使いたいからオラはベターCだな
946デフォルトの名無しさん (ﾜｯﾁｮｲ ff8c-GYCx)
垢版 |
2020/01/11(土) 10:17:43.71ID:MvVD+3kL0
APIでいろいろある。
2020/01/11(土) 11:30:24.41ID:Rj+B3SHF0
ま、抽象度が低いと覚えることは少ないんだよ。
論理回路は覚えることが超少ない。
948デフォルトの名無しさん (ﾜｯﾁｮｲ 7fad-W3qw)
垢版 |
2020/01/11(土) 16:02:03.38ID:j7/IvFvR0
Kotlin もよろしく
949デフォルトの名無しさん (ﾜｯﾁｮｲ df35-e1y7)
垢版 |
2020/01/11(土) 16:06:43.26ID:tdQ2h9sk0
覚えることが少ないというか物理的で直感的だからわかりやすい
クラスとか言われても初心者には「？」だし
2020/01/11(土) 16:32:40.71ID:Mi8oZktw0
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
951デフォルトの名無しさん (ﾜｲｰﾜ2 FF7f-Eg5K)
垢版 |
2020/01/11(土) 17:09:55.20ID:l/QLWHKHF
const 禁止のことを言ってるなら同意
2020/01/11(土) 17:46:53.86ID:AmOO0hUd0
>>950
とりあえずお前はCに留まってろ
話はそれだけだ
2020/01/11(土) 17:53:57.75ID:DoM09T/H0
有名なリーナスのコピペだろ
954デフォルトの名無しさん (ﾜｯﾁｮｲ ff8c-GYCx)
垢版 |
2020/01/11(土) 22:53:33.52ID:AUXeR2Nj0
初心者がC++を使うのはクラスが便利とかではなくて便利そうなライブラリを引っ張てこれるからだろう。
2020/01/11(土) 22:55:44.33ID:maKKMM+r0
便利そうなライブラリを引っ張ってこれる時点でプログラミング初心者ではないし
そもそもC++から始めるプログラミング初心者とか存在すんのか？
2020/01/11(土) 23:26:05.56ID:PA1VQQuv0
>>947
NANDだけだな
957デフォルトの名無しさん (ﾜｯﾁｮｲ df01-ErPi)
垢版 |
2020/01/11(土) 23:31:10.93ID:r5wulSj/0
単純に便利だからじゃないの。
2020/01/12(日) 01:47:15.90ID:yxPPqVVq0
>>956
そうなんだ
2020/01/12(日) 01:51:46.75ID:HwD03+Q90
笑って良いか？ｗ
2020/01/12(日) 02:18:33.81ID:1G/fBof90
いいとも！
2020/01/12(日) 03:10:59.78ID:Svv4a/Ag0
gccコンパイルしたんだが今どきのgccってC++で書かれてるんだな
恥ずかしながらつい最近まで知らんかった
962デフォルトの名無しさん (ﾜｯﾁｮｲ ff8c-GYCx)
垢版 |
2020/01/12(日) 07:25:04.57ID:t6zFaymS0
>>947
でも日本は失敗したんだよね。
963デフォルトの名無しさん (ﾜｯﾁｮｲ 5f02-tgR8)
垢版 |
2020/01/13(月) 14:02:27.58ID:JUx858UH0
質問です。32bitで確保できるメモリの上限近く(windowsなので1.5GBとか)を
色々なデータで確保した後、いっきに半分以上解放し、またいっきに色々なデータで
上限近く確保しようとするとmalloc()が失敗します(NULLを返す)。
プロセスのメモリを見ても500MBくらいまで落ちてから再確保しているようですがダメです。
これは内部で何が起こっているのでしょうか？断片化とかでしょうか？？
2020/01/13(月) 14:50:30.36ID:JUx858UH0
追加ですが殆どのデータを解放して使用量50MBくらいにしてから
しばらく待ってから再確保すると上手く行くようです。ただ500〜1000MBくらい残してから
また上限近くまで確保しようとすると失敗します。何故でしょうか？
2020/01/13(月) 15:39:54.87ID:xgMgrp400
よくわからんけど、ヒープメモリの仕組みを調べるといいかも。
966デフォルトの名無しさん (ﾜｯﾁｮｲ df01-ErPi)
垢版 |
2020/01/13(月) 15:42:12.61ID:WUoSHY6Y0
アリ人間は何故なまえを変えたのか。
2020/01/13(月) 15:47:05.97ID:5GjUS2iX0
フラグメント
断片化

アドレス空間2GBの壁
諦めなさい
2020/01/13(月) 15:54:23.75ID:5GjUS2iX0
極端な例

256MBのメモリを8個確保 (2GB分) したあと
1, 3, 5, 7個目を解放

この状態だと
1GB空きがあるのに
連続で空いてるのは256MB
だから512MBの確保に失敗する
969デフォルトの名無しさん (ｱｳｳｨﾌ FFa3-tgR8)
垢版 |
2020/01/13(月) 16:31:54.68ID:axFuJyFlF
断片化だろ
しばらく待つことに何の意味も無い
2020/01/13(月) 16:37:34.93ID:JUx858UH0
>>967-969
やっぱり断片化ですか… 一旦使用量50MBまで減らしたら
断片化がかなり無くなったので確保が上手く行ったという事になりますかね。
更にうまくメモリ管理するか64bit化も考えようと思います。ありがとうございました。
971デフォルトの名無しさん (ｱｳｳｨﾌ FFa3-tgR8)
垢版 |
2020/01/13(月) 17:38:12.46ID:axFuJyFlF
細切れにならないように自分ででかく確保して
その中をさらに自分で管理すると良い
レス数が950を超えています。1000を超えると書き込みができなくなります。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況