[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/12 01:51 / Filesize : 317 KB / Number-of Response : 1019
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C言語なら俺に聞け 147



1 名前:デフォルトの名無しさん [2018/08/16(木) 23:36:02.22 ID:fOCSKLtw.net]
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
codepad.org/

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

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

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

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/


C言語なら俺に聞け 146
https://mevius.5ch.net/test/read.cgi/tech/1525031257/

730 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 12:45:48.51 ID:vNhhiwgZ.net]
え、
>>711ってarcとか使わないで円を書くって言ってるの?

731 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 12:54:42.87 ID:usOBe9qe.net]
アスペっすわ

732 名前:デフォルトの名無しさん [2018/09/05(水) 12:59:20.81 ID:TsbO/g0i.net]
三角関数の説明に三角形だけの図を描いてこれ割るこれとか言って済まそうってのは手抜きな感じがする。やはり円も描かねば。

ま、しかし、sin. cos 使って円が書けるのがわかったのは良いが、当時のマイコンは貧弱で浮動小数点演算なんかやらせてたら遅くて仕方がなかった。
しかしBASICでグラフィックに円を描かせると妙に速い。正数計算して描いてるからだが、どうするとそんなことができるのかを延々と探り続けてようやっとわかったのが高校生になってからだったかな。
今はもうほとんど覚えてないが二乗して足してってオーバーしたら引いてみたいな計算したと思った。

733 名前:デフォルトの名無しさん [2018/09/05(水) 13:00:45.01 ID:TsbO/g0i.net]
>>717>>720
まあ40年ぐらい昔の話だからね。

734 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:01:32.32 ID:9Ih296dz.net]
>>722
で?

735 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:07:48.81 ID:D3bYtmsn.net]
ポインタ限定でそんなに語ることがあるのか

736 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:15:30.75 ID:Lw38WY1e.net]
>>722
それってブレゼンハムやミッチェナーのDDAアルゴリズムを利用した直線や円周の高速描画だろ
懐かしいな

737 名前:デフォルトの名無しさん [2018/09/05(水) 13:22:45.26 ID:TsbO/g0i.net]
>>726
何て言うのかは知らなかった。何かのプログラム解析してわかったんだったかな。その辺は忘れた。
直線も足してってオーバーしたら引くみたいなやり方だよね。今ではハードウェアで組み込まれてるんだろうな。

738 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:24:01.11 ID:ElSUubWJ.net]
>>725
ポインタが指す先が const の場合とかポインタそのものが const の場合とかさらに volatile が組合わさったりさらにそういうののポインタだったり配列だったり関数ポインタまで入り



739 名前:込んだりした場合に、
正確に型宣言したり読んだりするには結構修行が必要だからいろいろややこしいことが書いてあるんじゃないか
[]
[ここ壊れてます]

740 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:27:13.74 ID:TND9Xsam.net]
>>722
>当時のマイコンは貧弱で浮動小数点演算なんかやらせてたら遅くて仕方がなかった。

この辺は工夫次第
8bitPCが全盛だった頃、動く3Dオブジェクトを表示するのに機械語で演算処理組んでいた
全部整数化し、SIN関数値は全部テーブルで持たせていたな
試して見れば分かるが実際に必要なテーブル範囲は90度もいらない

741 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:37:21.57 ID:7JsiFjUt.net]
敵の弾が自分めがけて飛んでくる
ってたったそれだけでも中学の頃は大変だったな・・・
なつかしい

742 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:47:10.12 ID:ElSUubWJ.net]
>>730
大変だった

743 名前:
どんな式を立てたかは忘れたが、角度によって弾の速さが変わっちゃったりして試行錯誤してたな
[]
[ここ壊れてます]

744 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 13:51:42.60 ID:mkiFi/5o.net]
1フレームごとに最短距離で追尾してくる最も厄介なミサイルが実は一番簡単

745 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 14:58:15.54 ID:jTYdKpzW.net]
もうすでにC言語なんか関係なく回顧厨になっとるな。
俺も乗っかろう。
昔はBASIC標準のライン描画やらペイントルーチンが遅いので、いかに高速なアルゴリズムを作るかパソコン雑誌の特集になってたりしたな。
超高速中間色対応ペイントルーチン!みたいな。
ある意味、良い時代だった。

746 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 16:27:30.41 ID:GAiajT5F.net]
中間色とか20年以上聞いてない

747 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 19:06:16.01 ID:83kKikU4.net]
中間管理色

748 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 20:11:02.62 ID:oFUMlVxX.net]
タイルパターン



749 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 20:19:51.65 ID:dRudxIH1.net]
ランダムディザ

750 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 20:20:14.55 ID:TND9Xsam.net]
液晶上にある発光体の色は3種類
マゼマゼする原理は同じ

751 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 21:50:01.40 ID:PklssQfn.net]
>>734
CoolType/CelarTypeがそれに近いけどな

752 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 21:50:31.53 ID:YeNc+rPy.net]
R成分100%にB成分100%をビット演算で重ねる、みたいな話か。

753 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 22:58:16.11 ID:Lw38WY1e.net]
重ねるというよりも隣接するドットを違う色で決まったパターンで表示することで
擬似的に色調表現するテクニック
基本的に8色しか使えなかった頃に多色表現するために開発された手法
複数ドットでひとつの点を表現するためにいかに自然に見せるかといかに高速化するかが
プログラム的に腕の見せ所だった

754 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 23:26:42.92 ID:ElSUubWJ.net]
cleartype はそういうのじゃなく、三原色の並びを利用して擬似的に横方向の解像度を上げる方法でしょ。
1画素内に三原色が RGB と並んでた場合、それを2画素並べると以下のように画素の分解能を超えた位置に白点を表示できる。

RGB___ 白黒 … 座標 0 に白点
_GBR__ シアン赤 … 座標 1/3 に白点
__BRG_ 青黄 … 座標 2/3 に白点
___RGB 黒白 … 座標 1 に白点

755 名前:デフォルトの名無しさん mailto:sage [2018/09/05(水) 23:39:34.25 ID:PklssQfn.net]
>>742
知ってるぞ。
ClearTypeはsubpixel技術で、中間色はsubcolor技術だ。
まあ2)GrayScaleAAの方が近いといえばそうだが。
> 2) Grayscale anti-aliasing
> https://en.wikipedia.org/wiki/ClearType

756 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 00:30:08.44 ID:RM3Caylz.net]
文字表示から離れればという気もするが

757 名前:740 mailto:sage [2018/09/06(木) 05:55:34.60 ID:UQb09hzL.net]
すまん、投稿が受け入れられたタイミングがマズくて
>>739 に対する反応みたいに並んでしもうた。
>>740>>739 の「マゼマゼする原理は同じ」に乗っかったネタ文だ。

R成分100%とB成分100%をマゼマゼして、HTMLの16進表記で#FF00FFの色を作ったら、
「そりゃ“マゼンタ”だよ、バカだねぇお前さんは」という想定(しかし破綻)。

758 名前:740 == 745 mailto:sage [2018/09/06(木) 06:16:09.23 ID:UQb09hzL.net]
もちろん「マゼマゼ」は >>738 だよ、引用アンカーを間違えるとは。
マゼマゼでダメダメ。再び「バカだねぇお前さんは」



759 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:31:52.28 ID:/8o/0CpY.net]
>>745
ん?俺は別に煽られたとは捉えてないし問題ないぞ。
そもそも話が通じないのは「抽象思考」が出来てないからだ。

三角関数で → 円も描ける、であって、(演繹)
円を描く為には → 三角関数、ではない。(暗記)

とはいえ適用する場合は大体お約束的だし、
大学入試なんて解けるように作ってあるのだから、「暗記」タイプでも努力すれば数学の点も上げられる。
しかしそれでは駄目なんだよ。意味がない。
そして小学生に三角関数を教えても「暗記」にしかならないから、その時点で教えるのはやはり間違っている。
> これ割るこれがsin (>>711)
これも、結局の所これ以外にどう表現しろと?という話だからね。

これが嫌だったのなら教育関係に就職して改革すべきだが、
実際ゆとり教育を先導した戦犯役人はこのタイプだった(はずな)ので救えない。
理解出来なかった奴が「俺が理解出来なかったから」という理由で主導するからおかしな事になる。
今現在の「プログラミング教育導入」もこれに近く、
そもそもプログラミングできない/やったこと無い奴らが主導してるから暴走してる。

三角関数なんて、円以外で適用される場合の方が多い。
それを過度に円に結びつけるのは数学としては間違っている。
単振動なんて、本来は円運動とは関係ないだろ。あれはma=kxの解がsinxだって話であって。
内積が|a||b|cosθになるのだって、円なんて全く関係ないし。
三角関数は、「偶々そういう関数を定義したら、何か知らんけど色々使える」であって、その見方だと
> これ割るこれがsin
になってしまう。これ以外に表現しようがない。
逆に、「宇宙の全ては円で出来ている」(なぜなら三角関数が適用出来る場合が多いから)
という捉え方も出来なくはないが、こっちの方がカルトだろ。
おそらく、数学の発達過程で他にも色々関数が定義されて、でも使えない物は淘汰されて、
結果的に今の三角関数だけが残ったのだと思うぜ。

760 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:33:21.82 ID:/8o/0CpY.net]
中間色/CoolType./AAも、俺にとっては「隣接するピクセルを用いて中間値を表現すること」で同じだ。
お前らはそれを
・フォントの場合
・色/ピクセルの場合
と別々に覚えてるから別物に見える。それはお前らの脳内が「暗記」ベースだからだよ。

暗記ベースでプログラミングの上達を目指すのは「デザインパターン」だ。
しかしこれも必要以上に細分化し、しかもJava文法が足りない点を必死で補っていたりで、
はっきり言ってポシャったろ。あれでは無理があるのさ。
勿論、「暗記」しかできない奴はいまだにそれにすがり続けているようだが。

ただ、実際の所、プログラミングは当然実装出来ると分かっている範囲で為されることが圧倒的に多いので、
「暗記」ベースの手法でもほぼ全ケースで何かしらの適用が出来、対応出来る。
だからそんなに問題にはならず、ある意味Javaプログラマが一定レベルまで順当に成長するのはこれがある。
ただ、「暗記」ベースだと、知らない事は発想出来ない。別物扱いだから。
中間色を「抽象思考」で捉えているのなら、
方向を変えて適用した結果がCoolTypeでありAAでしかなく、これらは自然に連結する。
この点がずいぶん違う。

761 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:34:16.38 ID:/8o/0CpY.net]
この点に於いて、「暗記」ベースの奴は文法リッチな言語、JavaやC++の方がいい。
というかな、プログラミングが上達する奴と全く上達しない奴が居て、
別段人間的に問題がある(全く努力をしてない)訳ではないのが不思議だったのだが、
今のところの俺の結論はこれだ。
「暗記」ベースの奴はCやJavaScript等の文法がスカスカな言語では上達しにくい。(上達出来ない)

文法リッチな言語だと、「この文法はこのときに使う」というやり方で、
「プログラミングパターン」を「暗記」で積み上げることが出来る。
(これは本来「デザインパターン」と呼ばれるべき物だが、
この用語は継承をこねくり回したゴミの呼称となってしまっているので、敢えて別に命名する)
だから、文法を一通り押さえれば、知識としてのプログラミングパターンを一定量積み上げることが出来、
結果、一定までは確実に上達するというわけだ。
Javaはこの手法で平均レベルのプログラマを大量確保出来ている。

ただし逆に、文法等の暗記事項に計上されてないと、彼等は上達出来ないので、過度に暗記にすがる。
これが今の「デザインパターン」の状態だ。必要以上に細分化し、また、無駄に増やし続けている。
彼等にとっては新規パターンの登録と暗記がすなわち上達であり、それ以外に方法がないからだ。
したがって、今後ともこの暴走は続く。

C++erで言えば、彼等は shared_ptr/unique_ptr/weak_ptr の使い方にはご執心だが、そこまでしか見えていない。
次に導入されようとしている observer_ptr については必要性も使い方も分かっておらず、理解も出来ない。
なぜなら、「暗記」出来るのはそれらが定義されて以降であり、
「暗記」では現在未定義の物を演繹的に作り出すことが出来ないからだ。
良くも悪くも、C++が文法リッチになる過程で、CerとC++erが自然発生的に分かれてきたのはこの辺だと思う。
Linusから見ると、C++の文法もデザインパターンと同様のゴミの山に見えているはず。
(JavaScriptなんて、たったあれだけの文法で、C++で表現出来る範囲を越えるのだから笑える)

762 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:35:06.90 ID:/8o/0CpY.net]
Cの場合には文法がスカスカだから、
ポインタで → 何でも出来る、とならないと上達しにくい。(演繹)
この場合は → shared_ptr、では無理だ。暴走出来ない。(暗記)
だから「暗記」ベースな奴は文法リッチな言語を選んだ方がいい。
(ただしポインタがあまりに汎用性がありすぎて最適化等に問題があり、
結果、他言語では色々制限を付けられてきたのはご存じの通り)

逆に「たったこれだけの文法で全て表現出来るなんてステキ」と思える奴は
CやJavaScript等の文法スカスカ言語の方が向いてる。
JavaScriptがゴミゴミ言われながらもここまで残っているのもこの点が大きい。
あれは使える奴が使ったら凄く使える言語だ。
ただ、今のJavaScriptプログラマの大半がゴミなのも事実だが。

Cの授業が全く無駄だ、という話も出所はここだ。
プログラミングなんて、結局、「代入、条件分岐、関数呼び出し、ループ」でしかなく、
ループですら代入と条件分岐で実装出来るのだから冗長だ。
一応チューリング完全であるbrainfuckは関数呼び出しすらないので、これも冗長とも言える。
そしてCの授業で行われるのはまさに「代入、条件分岐、関数呼び出し、ループ」だけであり、
これでどうやって初音ミクが歌って踊るのだ?と初心者には思えるだろう。
最終的にはGPUを介してVRAM上に代入(ラスタライズ)しているだけだとしても、
それが初心者に見えるはずもない。
(もっとも、今の3Dベースの2D《テクスチャとして貼ってるだけ》だと
ラスタライズ結果をVRAMに戻しているかも怪しいが)

ただ、MITがSICPを止めたのと同様、今時初心者がCをやる必要はない。
DrawLineで線が描ける、HTML出力したら絵が出る、で済む連中がCやるのが間違ってる。
逆に、デバイスドライバ等を書いたり、
計算機自体の専門家(HighPerformanceComputing)等を目指すならCは必修になる。

763 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:42:07.42 ID:MYy5/YOc.net]
量子化誤差の拡散!

764 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 09:50:36.43 ID:2H4On29+.net]
コードもだらだら書いてるんだろうなぁ

765 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 10:01:03.49 ID:BRF//rri.net]
メモリーリークについて質問です
プログラム終了時に残ってしまったものに関してはOSが解放してくれるから対処しなくていいと聞きました
今までデバッグしてメモリーリークが出ると無くなるまで結構あれこれやってたんですが全部無駄だったんでしょうか

766 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 10:10:29.24 ID:2H4On29+.net]
>>753
終了時には解放してもらえるけど、メモリリークしたままだと動き続けられないじゃん。
たまに再起動してもらうの?

767 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 10:21:17.68 ID:BRF//rri.net]
あーいや想定してるのはちょっとした処理を行って出力して落ちるだけのプログラムなんです
ループの中で何回もmallocしてメモリを食いつぶすとかそんなことも無くて、ただ終了時まで動的確保した変数が解放されてないみたいな
そういう状況でお願いします

768 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 10:37:52.78 ID:2H4On29+.net]
>>755
そういう限定的な条件では解放は省略するって方針もあるかもね。
終了パターンがいろいろあると解放するだけでも一苦労だったりするし。

ただせっかく作ったそのコードは制約が多く他には転用しづらかったりと資産としての価値は低いと思う。
そもそもデバッグでメモリリークを発見とか言ってるとなると、メモリの管理はしっかりしてて解放を省略していることも設計に入ってる、という状況ではないんじゃないの?
それはメモリを管理できてないってことじゃないのかな。
そんな場当たり的なことやってると大きなコード書けないよ。
メモリリークを潰させるのは、メモリを解放すること自体が目的というよりメモリを管理させる教育的な目的じゃないかね。



769 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 11:35:05.98 ID:BRF//rri.net]
いや教育というか、上司が作ったAPIを利用して機能作れって指示が出ててですね
そのAPIが上で説明したように変数解放しないままプログラム終了してたって状況です
んでこれいいんですかこうすれば治りますがみたいなこと言ったらいいんだ勝手に解放されるかと

ともあれそういう方針が有りだということは分かりました。どうもです

770 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 11:39:51.63 ID:2H4On29+.net]
上司を教育してやりたいなw

771 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 11:42:26.02 ID:b42HI45e.net]
ここに呼んできて

772 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 11:55:09.68 ID:MYy5/YOc.net]
>>753
プロセス終了するなら、無駄です。

773 名前:デフォルトの名無しさん [2018/09/06(木) 12:07:29.83 ID:NrF/VtsZ.net]
そのAPIを流用するのは難しいな。
しないつもりなのかも知れないが。

まあしかしできればメモリリークしない方が良いな。
そのままだと常駐するプログラムのループの中で使えないし。

774 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 12:44:35.90 ID:5MBNHP4w.net]
>>757
上司の指示ならそのままにしとけばいい
メモリーリークしてもプロセス終了で解放されるから問題なし
って言う奴は一定数いて説得しても改心しないから放置しとくしかない
後々何かで事故った時のためにドキュメントに書いとけ

775 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 13:36:44.44 ID:N1zpzsdE.net]
たいていドキュメントは失われるので俺ならソースコメントに書いておくな。
「2018/09/06 メモリ解放してないので注意(先輩の指示で改修見送り)」

776 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 14:37:14.38 ID:3QzfQDga.net]
そりゃ、そういう状況では解放処理は抽象的な書き方にすべきなんですよ。
freeがなければ安心できないのって病気に近いよ。

777 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 19:28:33.32 ID:5MBNHP4w.net]
どういう状況か知らんけど
> こうすれば治りますがみたいなこと
言ってるにも関わらず対応しないのは宗教に近いよ

778 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 19:34:20.37 ID:hjZ1m3yx.net]
>>755
mayersだったかdinkumの人だったか忘れたけど、これはリソースリークじゃないって力説してて、
自分も同じセリフを言ってみたくてmain関数で確保したものを開放せずにいたら、
あとからそのmainだった関数に再入しないといけない要件が増えて涙した。
(小物ツールだったのに…)

というわけでfreeしようぜ



779 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 19:56:53.52 ID:/8o/0CpY.net]
>>757
> ちょっとした処理を行って出力して落ちるだけのプログラム
> 上司が作ったAPIを利用して機能作れって指示
× API
○ ツール

上司が作ったちょっとした「ツール」を使って(データの一部を切り出してきて)パイプ等で受ける場合、
そのツールがプロセス終了時に解放してないと文句を言うのは煙たがられる。
それは「意識高い系」すぎるし、そもそも君の担当範囲に何も悪影響はない。
そんなことはいいからお前の担当部分のバグを直せ、と思われているはず。

一応言っておくとfreeもタダではないので速度は落ちる。
必ずその後にプロセスが終了すると分かり切っているのなら放置もありだし、そっちの方が速い。
大方、精々1000行以下の上から下までつるっと動くだけのプログラムで、
最初に1回ワーク領域としてmallocして終わり、のパターンだろ。
割とどうでもいいね。実行形式のみでの配布なら問題になることはない。
(俺ならfreeしておくが。理由は>>766と同じで、流用するときにバグるから)

なお「API」では通常、別プロセスを起動して呼び出すことはない。(俺の知る限り)
本来「ツール」と表現すべき所を意図的に「API」と言うなら、相当な悪意だと受け取られる。
ただ単に間違ったのなら、お前は上司に対していちいち文句を言わず、
指示されたようにやるべきレベルだ。わきまえた方がいい。

ソースコードにコメント、は止めた方がいい。そこは上司への不満を書く場所ではない。
直すなら「潜在バグ」として正式登録、その必要がないと判断するなら放置したほうがいい。
数年後、君によって後輩が助かれば君は讃えられるだろうし、
そうでなければ君は痛かった奴だなと思われる、ただそれだけの話だ。
コメントだけ残して修正してませんでした、ってのはマジで痛いだけだから止めとけ。
誰も助からないし、生産性がない。
(バグを踏んだ後輩から見れば責任逃れせずにちゃんと直しておいてくれ、としか見えない)
そもそもそのツールがバグってたのなら作った上司の責任だし、
上司がそれを面倒がるのなら、そのソースの管理責任を君が受け取って自由に出来るはず。

780 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 19:59:05.01 ID:xdo6cDUj.net]
そんなに速度のことが気になるなら、グローバルでドカッと変数確保すりゃ良いだろう

781 名前: mailto:sage [2018/09/06(木) 20:06:34.02 ID:N2ZzCqNY.net]
>>755
きちんと malloc() した領域を free() できているように、それを重点的に書き直していくだけでも、プログラムの構造がわかりやすくなり、バグも少なくなるとおもいます

782 名前: mailto:sage [2018/09/06(木) 20:08:11.19 ID:N2ZzCqNY.net]
>>768
そうそう、malloc() したポインタを線形リストに登録しておいて、最後にまとめて free() するとか…

783 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:09:17.57 ID:L7E4s+iy.net]
>>768
さすがにそれはセンスがないのでは
ドカッと一発mallocならまだしも

784 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:12:16.01 ID:xdo6cDUj.net]
ツールに使う程度の小規模なプログラムなら、
グローバルで取ろうと気にしなくて良いと思うけどな

785 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:16:36.65 ID:/8o/0CpY.net]
>>768
さすがにプロセス起動/終了の方がfreeより100倍以上重いはずなので、
ここでfreeを速度の為にケチる、というのはナンセンス。
ただ、free一個分速いのは事実だし、Cは精神論的に速度を希求するからねえ。

多分、最初はグローバルで固定長バッファだったが、
もっと大きなサイズも必要になって、面倒だったからど頭でmallocに変更、だと思うよ。
割とありがちなパターンだし、この場合はfreeしない文化のような気もする。

786 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:32:13.62 ID:5MBNHP4w.net]
最近はあまりないけど実メモリーがカツカツの状態だとfree()する為にディスクからページを読み込む処理が大量に発生してなかなかアプリケーションが終了しないと言う事があったりする

787 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:36:44.52 ID:w4APQ8t2.net]
exitって重いの?
まあfreeするもんだと決め打ちはしたらあかんよ

788 名前:デフォルトの名無しさん [2018/09/06(木) 20:38:25.83 ID:64ZwjQvb.net]
freeしてないコードを池沼が書いて

freeしてないコードを
実績があるコードといって池沼が確かめもせずそのままコピペして流用する

よくあること



789 名前:デフォルトの名無しさん [2018/09/06(木) 20:40:44.45 ID:64ZwjQvb.net]
つまり池沼の代重ねで
どんどんメモリリークが酷くなっていく

790 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:49:38.63 ID:u/2SwpDg.net]
dtr は作るけど、コメントに「プロセス終了時にしか実行しないのでfreeしてない」と書いて放置してるわ

791 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 20:57:43.99 ID:/8o/0CpY.net]
>>774
ああ、なるほど。
そういえばスワップがある時にFireFoxを落とすだけでもずいぶんかかっていたのを思い出した。
なるほどそこでスラッシングしてたのか。

792 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:05:57.78 ID:2H4On29+.net]
>>779
うちの FireFox も終了時にモタモタしてるから、そうなるのが分かってる時はタスクマネージャーで殺したりするw

つかアプリは終了時に保存するもの保存したらリソースそのままで exit しちゃう方がいい気がしてきたわ。

793 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:22:48.78 ID:lfEPMv1j.net]
freeでスワップからページ読み込みするってマジ?
freeだけならdirtyページドロップするだけだと思ってたわ

794 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:38:33.95 ID:iyjSCMca.net]
freeがいちいちSVCなんかするわけねえだろ
それと、おまえスワップとページを混同してるな

795 名前:デフォルトの名無しさん [2018/09/06(木) 21:42:11.21 ID:RfogV38/.net]
>>781
ポインタ書き換えたりするから一度ディスクからメモリに戻さざるを得ないのでは?
ものすごく大きい領域を一括で確保した場合は全部戻す必要ないけど細切れに沢山確保してあるのをバラバラにfreeしたらなりそうだよね。

796 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:46:37.65 ID:7YUMDOtR.net]
>>781
free()すると管理領域を書き換えるためにページインが必要になる

797 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:52:07.32 ID:SMB/Y5b1.net]
ランタイムの実装とOSにどう伝えてるかの間のことを考え出すと激しく禿る思考停止
unix/linux な人はどう実装してるか確認してるの?

798 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 21:54:14.48 ID:N6MGums/.net]
>>782
そうなの?
例えばWindowsだとfreeは内部でHeapFreeをコールしてるのかと思ってた。
HeapFreeって恐らくSVC伴うよね?



799 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:11:21.70 ID:xdo6cDUj.net]
皆さん、実メモリってどの位積んでいるの?

800 名前: mailto:sage [2018/09/06(木) 23:42:12.50 ID:N2ZzCqNY.net]
>>787
DDR3 16G です、もっとほしい…

801 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:43:10.77 ID:f49/P0Og.net]
8G
しかしこのPCは5年以上前に買ったやつ。

802 名前:デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:53:41.06 ID:iNL3W5R4.net]
>>781
単純に free だけの話じゃなく、自分が作り上げたオブジェクトツリーを辿りながら free していく過程でその(結局解放する)オブジェクトをページインすることになる。
C でオブジェクトとか言うことの是非は置いといて。

803 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 00:04:11.13 ID:oKo9UKIA.net]
>>787
Windows7 で 3GB。
Linux な家サーバだと 1GB。
Cプログラミングスタイルも細かくブロック分けてスタック節約するようなセコセコ型が基本。

804 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 06:00:25.35 ID:Pk3Mmzkj.net]
個人で使うための大したことないツールだったか、
この件の実験用に作ったプログラムだったか忘れたけど…。

そこそこ沢山のデータを、ひとつ読み取ってはmallocで確保した領域に保存、
ハッシュテーブル(値が重複する要素はリンクド・リストでつなぐ)にブチ込んで
個々のデータはプログラム終了まで破棄しない、て条件。

終了前に真面目にfreeして回るのと、そのままexitしてOSに片付けてもらうのと、
比較してみたらfreeのループ処理が意外に重かったんで、
解放処理の関数を残したまま呼び出し部だけ注釈にして、
// 解放すべきだと思いつつも無駄に重いんでOSに上手いことやってもらう
みたいな自分用のメモを残したわ。我ながらどっちつかずの折衷案。

805 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 07:56:45.53 ID:ZG8Bsw3G.net]
>787
Win7以降で最低4G、可能なら8G。3Dゲームやるなら16G以上。
XP時代は2Gか3Gだった。

806 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 07:57:24.56 ID:1SEeRaQU.net]
>>787
今使ってるマイコンのRAMは64バイト

807 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:06:16.22 ID:1SEeRaQU.net]
メモリを確保しっぱなしでわざわざ明示的に解放コードを書かないことはある
C++じゃなくてCだと特に

組み込みだとそもそも終了処理なんて物が無かったりする

808 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:35:25.77 ID:Ge6Y8svS.net]
>>792
(俺はそういう状況に遭遇したことがないが、)やるなら、
freeを生かしたまま残し、その直前でexit、
exitに「// free が遅いからここで強制終了」とコメントかな。

そもそもCはやたらfreeするようには出来てない。それはK&Rのfree実装をみても明らかだ。
C++や他GC言語のようにインスタンスを個別にmalloc/freeした方が
プログラミング的に美しく、自由度があるのも確かだが、
古来C流なら
> 個々のデータはプログラム終了まで破棄しない、て条件。
が分かっている時点で纏めてmallocし、内部的に切り出して使う、とかじゃないかな?
大きなテキストを1発mallocで確保し、内部的に改行コードで区切って使うみたいに。
初期データはインミュータブル扱い、追加/変更はインスタンス毎個別に確保、だ。

ただこれだと結局コードは増えてしまうし、個別freeすべきかのフラグを導入するか、
解放関数でインミュータブル領域かどうかを判定する必要がある。
そういうのが面倒だと最初から全部C++流にインスタンス毎個別に確保になり、
その分動作が遅くなるが、コード自体は綺麗に(統一的に)保たれる。
結局、コードを取るか、手間かけてその分高速化するか、でしかない。
気にならない程度なら、俺はC++流の個別確保の方がコードが綺麗だからいいと思うが。
(つまり今の君の実装)
気になるのなら、選択の余地無く高速化するしかないし。



809 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:38:20.43 ID:oKo9UKIA.net]
>>795
むしろ C++ の方が気安く new するから、そっちの方が放置したくならないかね。
根っこのオブジェクトを delete すれば後のはデストラクタがやってくれるとかで面倒さは少ないのかもしれないが。

何にしても、許されるのはきちんと解放できるけどあえてしない、ってのだけだな。
なんだかよく分かんないし面倒からOSに尻拭いしてもらうなんてのはダメだ。
fork で起こした子プロセスがメモリを free せず終了しても問題無いが、それをスレッドにしましょうなんてなった瞬間に破綻する。

810 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 09:28:39.55 ID:8HJNQC7B.net]
商業プログラムだとラッパだらけで直接free呼ばんし。
freeなしという選択肢は常に確保しとけばよい。

811 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 11:25:43.88 ID:/+XJI6DP.net]
>>786
え、WindowsにSystem z版てあるんだっけ?

812 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:12:28.24 ID:veel+fh4.net]
>>799
え?System z限定の話だったの?

813 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:18:34.93 ID:/+XJI6DP.net]
>>800
だってSVCって。。。

814 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:28:11.67 ID:veel+fh4.net]
>>801
スーパーバイザコールを拡大解釈して、いわゆる特権モードを伴うシステムコールとして書いてたわ。
誤解があったらすまん。

815 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:36:08.16 ID:H0y7xQ1z.net]
>>781
mmap経由ならOSによってはそうかもな

816 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 12:51:04.62 ID:/+XJI6DP.net]
>>802
おk
じゃあ、その前提で話を戻そう
freeはISO/IEC9899では宣言と引数の意味のみが規定され実装は未規定だ
782でああ言ったのは、freeする度毎にタイムスライスを放棄するような実装は
まずなかろうということだ

817 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 14:34:23.02 ID:lg5TGvmQ.net]
>>804
まず、786で書いたようにあくまで「思ってた」だけで確固たる根拠はないことを前提に。

freeするならどこからか借りていたメモリ領域を返却するわけで、仮想メモリ返却にはMMUを使ったページ管理が必要だよね?
仮想メモリページ管理はメモリマネージャー的なカーネルモードドライバが必要なはずで、つまり解放時にはシステムコールを伴う。

ただ、HeapFree時に直接カーネルモードで解放が実行されずメモリマネージャがガーベジコレクション的に後々回収するなら、あなたの言うとおりfree時にユーザーモードで閉じて処理されるかも。

このへん、Linuxとかどういう実装になってるんだろうね?

818 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 14:55:15.04 ID:Yr/2DouQ.net]
画期的なメモリ確保方式とか出来ないかな
例えばさ、名前付きタグを付けてメモリ確保し、
名前指定で一気に解放できるようにするとか



819 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 15:22:58.08 ID:OFkeqRjw.net]
Rust?

820 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 15:56:06.95 ID:/+XJI6DP.net]
>>805
freeがメモリを返却する相手が何者なのかは未規定だぞ
いちいちOSへ直に返しているとおまえさんの言うとおりだが
スタティックリンクライブラリがOSから大口で借りたメモリを切り売りする
スタイルならシステムコールの回数をガクンと減らせる
よくある実装は1MiBあたりを境に小容量は切り売りで大容量は直にという形

821 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 16:07:14.96 ID:lg5TGvmQ.net]
>>808
いや、俺はANSI Cとかの規定の話してるんじゃなくて、SVCって単語からこの議論がスタートしてるのでモダンなOS上の一般的な実装の話をしてると思ってたんだけど、違ったのか。

確かにアプリ起動時にある程度のヒープを最初から用意ってのはありそう。

822 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 16:15:46.30 ID:lg5TGvmQ.net]
>>806
ソフトで実現で良いなら、簡単に実現できそうね。
てかsmbか何かでそういう実装見たことあるような?

823 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 17:07:55.49 ID:+cI6iexZ.net]
>>805
Linux+glibcの環境なら、mallocは昔ながらのbrkシステムコールの方法と
mmapシステムコールの方法が状況に応じて使われる
freeしたときmmapをmunmapしてOSに返されることもある
はず。…たしか

824 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 18:11:36.24 ID:lg5TGvmQ.net]
>>811
なるほど、勉強になります。
やっぱりOSのメモリ管理をちゃんと理解しようとしたら参考になるので最低限glibcとmmapを読まないといけないね。

825 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:33:47.92 ID:lg5TGvmQ.net]
ちらっとmmapとglibc斜め読み

826 名前:してみた。
こんな世界があるんだとソフトエンジニア7年目にして新しい視点が開眼しそう。
色々気付きをくれた方々、ありがとうございました。
[]
[ここ壊れてます]

827 名前:デフォルトの名無しさん mailto:sage [2018/09/07(金) 23:08:07.85 ID:Ge6Y8svS.net]
>>806
ゆとりりゅうのすごいめもりかくほ、まで読んだ。

マジレスすると、
> 名前付きタグ
このコストが分からない馬鹿はCを学ぶ意味はあるだろう。
スクリプト言語しか使ったことのない奴に多いが。(例:ハッシュはタダだと思ってる)


>>805
> 仮想メモリ返却にはMMUを使ったページ管理が必要だよね?
お前は中途半端に勉強してるな。まあ悪いことではないが。
ページの単位は今も昔も4KBだ。その方法ではインスタンス毎の確保は出来ないと分かるだろ。

>>812-813
読むのは勝手だが、あまり関係ないところに深入りしても意味はないぞ。
7年目なら業務関連は一通り出来るようになっており、知識を横に広げているのかもしれないが、
OS関連の知識があってもな。

時間が有り余っていて手当たり次第に知識を吸収するのも一つの手だが、
もし大きい(10,000行以上)のを書いたことがないのなら、
まずは規模の限界(複雑さの限界)に挑戦する方がいいと思うが。

828 名前: mailto:sage [2018/09/07(金) 23:21:41.29 ID:WaHB6+zk.net]
>>814
>もし大きい(10,000行以上)のを書いたことがないのなら、まずは規模の限界(複雑さの限界)に挑戦する方がいいと思うが。
そうですね…
1万行ですか…
せいぜい 1000 行程度までしかやったことがありません、モチベーションが続かない・燃料切れ、という感じです



829 名前:デフォルトの名無しさん mailto:sage [2018/09/08(土) 00:12:07.00 ID:kEO ]
[ここ壊れてます]

830 名前:PIOXH.net mailto: 行数が多ければいいというものでもないと思うが・・・ []
[ここ壊れてます]






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<317KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef