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/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
細切れにならないように自分ででかく確保して
その中をさらに自分で管理すると良い
2020/01/13(月) 19:01:20.39ID:JUx858UH0
>>971
もっと効率よくやるならその方法がやっぱいいですね。ありがとうございます。
2020/01/13(月) 22:56:26.88ID:ke+wtNqb0
そこまで大きいデータならオンメモリで処理する手段は捨てるなあ
間違えて数GBのISOファイル読み込んじゃってPC固まったとかそういう挙動は許されざるよ
2020/01/13(月) 23:07:18.29ID:Yl8Am7cI0
無理に32ビットでやらなくても良いのではないか？
2020/01/14(火) 11:56:44.05ID:AM8t1N0H0
要するにブロックを詰めるパズルゲームだろ
2020/01/14(火) 16:16:37.73ID:MAaOflfD0
メモリをポインタではなくハンドルで管理すれば
メモリコンパクションができる

ただし、そんなことをしなくても実容量を超えるメモリが提供できるようにするために仮想記憶があるんだが
2020/01/14(火) 16:30:41.75ID:RxBpnTJ90
実容量を超えるメモリーを使いたいだけならオーバーレイとかセグメント方式のメモリー管理機構とか色々あるが
2020/01/14(火) 17:25:51.38ID:Ae/uveiQ0
>>976-977
32bitプログラムだとメモリ空間が最大でも4GBしか扱えないので
それ以上は無理ではないでしょうか？扱える方法何かあるでしょうか？
979デフォルトの名無しさん (ﾜｯﾁｮｲ df35-e1y7)
垢版 |
2020/01/14(火) 17:28:42.27ID:Cb2SImdL0
あるけど
2020/01/14(火) 17:37:38.20ID:JKuyIKmvd
メインメモリとは別の記憶媒体に退避しておけば、実質使える？かな？
2020/01/14(火) 17:46:20.96ID:SgRnb4BR0
>>978
その理屈だと、４GBを超えるファイルは扱えなくことになる
2020/01/14(火) 18:01:20.77ID:vjAz2zAO0
32bit Windows の普通のプロセスのアドレス空間は2GB

OSやAPIを改造してFARポインタを扱えるようにするか
ロックアンロック方式のメモリ管理を自力で実装するか

そんなことをするよりは
素直にアプリのメモリ確保の方法を変えるのが早い
もちろん64bit化出来るならそれが一番
2020/01/14(火) 18:05:55.14ID:RxBpnTJ90
>>978
オーバーレイは同じメモリー空間のデータ/プログラムを入れ替えて実行する機能
メモリー空間の話であればバンク切替とかもあるし
2020/01/14(火) 18:13:13.94ID:Ae/uveiQ0
>>982
どうしても使ってる一部のライブラリが32bitで64bit化するのが無理でした。
>>983
そちらを調べてみようと思います。
2020/01/14(火) 18:15:32.64ID:Ae/uveiQ0
>>980-981
そうやっても必要な時にメインメモリに読み込んで使う必要がないですかね？
しかも上手くやりくりして読み込んでもそこで断片化の問題もありますし。
その場合プールを自分で管理するしかなさそうな気がします。途中でその話をしてましたが。
2020/01/14(火) 18:31:15.17ID:jSZPoIDP0
32bitOSで4GB以上のオブジェクトをメモリに読み込んでどうにかしろ、と言われたら。
最初に検討するのはファイルマッピングだろうなあ。それ以外だとやる気がおきない。
APIを叩く必要があるので、WindowsならCreateFileMappingとかMapViewOfFileとか。
2020/01/14(火) 18:32:25.86ID:Ae/uveiQ0
>>986
ありがとうございます。調べてみますね。
2020/01/14(火) 18:32:29.78ID:RxBpnTJ90
>>984
> そちらを調べてみようと思います。
いやいや、オーバーレイとかバンク切替とかは半分ネタだから今更そんなもん調べなくていいよw

>>985
> しかも上手くやりくりして読み込んでもそこで断片化の問題もありますし。
アホほどでかいサイズでなきゃそれほど問題にならないよ

> その場合プールを自分で管理するしかなさそうな気がします。途中でその話をしてましたが。
どうしてもでかい領域を確保/解放する必要あるならそれしかないように思う
2020/01/14(火) 18:39:12.20ID:JKuyIKmvd
どうしてそんなデカいデータが必要なんだろう。遺伝子情報でも操作してんのかな？
2020/01/14(火) 18:41:07.63ID:Ae/uveiQ0
>>988
>いやいや、オーバーレイとかバンク切替とかは半分ネタだから〜
ネタでしたかｗ 了解しました。

>アホほどでかいサイズでなきゃそれほど問題にならないよ
細かいのと途中で500MBくらいを二つとかがあるので時々断片化のせいでmallocが失敗するんですよねえ…

>どうしてもでかい領域を確保/解放する必要あるならそれしかないように思う
とりあえず作業領域様に500MBの領域を確保して再利用すると他の部分でmalloc失敗はなかったですね。
仰るように小さい領域はかなり確保しても問題にならないですね。大きな領域用にメモリスペースを予め確保しておく方法がよいかもしれないと思いました。
2020/01/14(火) 18:45:58.67ID:SgRnb4BR0
>>990
メモリーマップドは、かなり癖があるから注意して使った方がいいよ
ロジックなどの作りは簡単になるけど、
下手をすると処理が一日で終わらないなんて平気で起きる
2020/01/14(火) 18:48:32.63ID:iQtyfXTR0
もう64bitが当たり前になってかなり経つ昨今、そんな案件ごろごろある
映像をリアルタイムでごにょごにょとか言われたら簡単にギガ単位のメモリ使う
稀有な例では無いけど32bit環境でやれって言われたらヤダナとは思う
2020/01/14(火) 18:55:05.49ID:Ae/uveiQ0
>>991
そうなんですね。了解しました。

>>989 >>992
詳細はあまり言えないのですがメモリ中に
動画データを一部展開しなければいけなくて
メモリ不足や断片化の問題で困ってました。
しかも周辺で使ってるライブラリが32bitで64bit化が難しくて。
2020/01/14(火) 19:02:49.75ID:JKuyIKmvd
そろそろ次スレ
2020/01/14(火) 19:20:01.41ID:2s3ZuCDc0
8k240Hz動画だと1秒キャッシュするだけでメモリ消費24GBか
まあ今時わざわざCを使うなんて極限環境だけだからそういうこともあるよね
レス数が950を超えています。1000を超えると書き込みができなくなります。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況