アカウント名:
パスワード:
サーバを業務開始前に再起動する運用のところもあるらしい
某メガバンクが合併前のただの1銀行だったとき、そこの勘定系システムでは週1のシステム再起動が運用に加えられたという事もありましたねぇ。ライブラリがリソース解放しないせいでメモリ枯渇するって理由だったかな。
メモリリークに関しては、C++で開発すれば勝手にメモリ開放してくれると思ってるプログラマがいるくらいだからなあ
A「mallocで確保したメモリ開放している場所がないのですが、どのタイミングで開放したらいいのですか？」 B「拡張子みてくださいC++ですよ」A「？？？・・・」B「C++では、ですね。勝手にメモリ管理しくれるんでfreeは不要なんですよ」A「え？」B「そんなことも知らないんですか？」
※ソースはコメント以外はC++風なとこは、ほぼありませんでした。※ちなみにVC++に勝手にメモリ開放機能ありますか？あったのならごめん
deleteしたはずなのにメモリ解放されずにメモリ不足で止まったことがあった僕の経験から、VC++でのデバッグ中はむしろメモリを開放せずに、何かの時のためにとっておく機能があると思います。
#最終的にメモリは同じ物をなるべく使いまわす設計にしました。
C++のBoostライブラリには参照を管理して開放もしてくれるsmart_ptrがあるけど、C++の言語仕様そのものにはGCはないです。
> B「C++では、ですね。勝手にメモリ管理しくれるんでfreeは不要なんですよ」そのような機能を備えたフレームワークしか使ったことがない人に一票.
ちょっと気になったのが、[メモリ開放]共有メモリ等のイメージかな.社内方言でしょうか、解放の方が一般的では.
どっちもどっちと.
最近某所でメモリーの開放は（プロセス終了による）OSに任せるべきでfree()を使うのは無駄かつ余計なバグ（不正なパラメータでfree()を呼び出す）を作る危険のある行為だ！と主張している方がおられましたもちろん「C言語」レベルの話しです
リソースに対してプログラムが十分に短命ならそれもあり。けど、free() に不正なパラメータを渡すことを心配するような程度のポインタ管理ならfree() しなくてもそのプログラムはバグってる。もっともらしい言い訳を考えてる間にはセオリー通り free() しとけと言いたい。
某場所で「メモリー開放は（プロセス終了に伴う）OS機能にまかせてfree()を使うべきではない！free()の呼び出しは無駄であり（不正なポインタを指定など）余計なバグを産む有害なコードである」と声高に主張しておられる方がいましたもちろんC言語の話しです
javaから転向してきたプログラマにそんな奴がいたなnewと mallocを混在してつかっていた。ライブラリの親クラスで deleteしているので、通常は子側での解放不要なのだが、自前の mallocの後始末がおかしかった。
#freeが開放ってopenと紛らわしくないですか
このあいだ某所で「メモリーの開放はプロセス終了に伴うOS機能に任せるべき！free()の呼び出しはコードの無駄なだけでなく（誤ったポインタを指定するなどの）バグを作り込む危険性を増す不味い方法だ！」と主張してらっしゃる方がおりましたもちろんC言語での話です
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
メモリリーク？ (スコア:0)
サーバを業務開始前に再起動する運用のところもあるらしい
Re: (スコア:0)
某メガバンクが合併前のただの1銀行だったとき、そこの勘定系システムでは週1のシステム再起動が運用に加えられたという事もありましたねぇ。
ライブラリがリソース解放しないせいでメモリ枯渇するって理由だったかな。
Re: (スコア:0)
メモリリークに関しては、C++で開発すれば勝手にメモリ開放してくれると思ってるプログラマがいるくらいだからなあ
A「mallocで確保したメモリ開放している場所がないのですが、どのタイミングで開放したらいいのですか？」
B「拡張子みてくださいC++ですよ」
A「？？？・・・」
B「C++では、ですね。勝手にメモリ管理しくれるんでfreeは不要なんですよ」
A「え？」
B「そんなことも知らないんですか？」
※ソースはコメント以外はC++風なとこは、ほぼありませんでした。
※ちなみにVC++に勝手にメモリ開放機能ありますか？あったのならごめん
Re:メモリリーク？ (スコア:1)
deleteしたはずなのにメモリ解放されずにメモリ不足で止まったことがあった僕の経験から、
VC++でのデバッグ中はむしろメモリを開放せずに、何かの時のためにとっておく機能があると思います。
#最終的にメモリは同じ物をなるべく使いまわす設計にしました。
Re: (スコア:0)
C++のBoostライブラリには参照を管理して開放もしてくれるsmart_ptrがあるけど、C++の言語仕様そのものにはGCはないです。
Re: (スコア:0)
> B「C++では、ですね。勝手にメモリ管理しくれるんでfreeは不要なんですよ」
そのような機能を備えたフレームワークしか使ったことがない人に一票.
ちょっと気になったのが、
[メモリ開放]
共有メモリ等のイメージかな.
社内方言でしょうか、解放の方が一般的では.
どっちもどっちと.
Re: (スコア:0)
最近某所でメモリーの開放は（プロセス終了による）OSに任せるべきで
free()を使うのは無駄かつ余計なバグ（不正なパラメータでfree()を呼び出す）を作る危険のある行為だ！
と主張している方がおられました
もちろん「C言語」レベルの話しです
Re: (スコア:0)
リソースに対してプログラムが十分に短命ならそれもあり。
けど、free() に不正なパラメータを渡すことを心配するような程度のポインタ管理なら
free() しなくてもそのプログラムはバグってる。
もっともらしい言い訳を考えてる間にはセオリー通り free() しとけと言いたい。
Re: (スコア:0)
某場所で「メモリー開放は（プロセス終了に伴う）OS機能にまかせてfree()を使うべきではない！free()の呼び出しは無駄であり（不正なポインタを指定など）余計なバグを産む有害なコードである」と声高に主張しておられる方がいました
もちろんC言語の話しです
Re: (スコア:0)
javaから転向してきたプログラマにそんな奴がいたな
newと mallocを混在してつかっていた。
ライブラリの親クラスで deleteしているので、
通常は子側での解放不要なのだが、自前の mallocの後始末がおかしかった。
#freeが開放ってopenと紛らわしくないですか
Re: (スコア:0)
このあいだ某所で「メモリーの開放はプロセス終了に伴うOS機能に任せるべき！free()の呼び出しはコードの無駄なだけでなく（誤ったポインタを指定するなどの）バグを作り込む危険性を増す不味い方法だ！」と主張してらっしゃる方がおりました
もちろんC言語での話です