プログラマの雑談部屋 ★61

■ このスレッドは過去ログ倉庫に格納されています
2019/02/17(日) 14:45:52.92
※前スレ
プログラマの雑談部屋 ★60
https://medaka.2ch.net/test/read.cgi/prog/1549858447/
713仕様書無しさん
垢版 |
2019/02/23(土) 12:08:07.66
>>705
ダンプ取れよ

Using Visual Studio 2013 to Diagnose .NET Memory Issues in Production
https://devblogs.microsoft.com/devops/using-visual-studio-2013-to-diagnose-net-memory-issues-in-production/

開発環境でも良いなら単にプロファイラを使用すればいい
2019/02/23(土) 12:08:57.62
>>712
なんぼなんでもプロセス殺したらフリーされんじゃないか？
2019/02/23(土) 12:09:25.64
>>710
意味がわからん
もう頭がこんがらがってるだろキミ

非効率なGCしか知らない人がGCは効率的だと主張するわけがないだろ

キミは自分が無理筋を攻めようとして詰んでいる事にはやく気が付いたほうがいい
詰んでいるのに戦おうとするから支離滅裂な言動をせざるをえなくなってる
2019/02/23(土) 12:09:47.00
コンビニバイトとJavaプログラマーはどちらが手取りが多いですか
2019/02/23(土) 12:10:36.22
ガリガリしてないとこにＧＣ使うのは効率いいと思うけど

適材適所
718仕様書無しさん
垢版 |
2019/02/23(土) 12:10:45.69
前にも言っただろ。
このように、オブジェクト指向はわかる奴にしか
わかんねーんだから意味がないんだって。

これからは未経験者が14万円で現場に来る時代なんだから、
そんな奴らでもわかる仕組みが必要なんだよ。
2019/02/23(土) 12:11:43.68
>>714
プロセス終了でシステムリソースが安全に解放される保証は

ない
720仕様書無しさん
垢版 |
2019/02/23(土) 12:12:13.86
>>710
何もしてないのにって言う奴は信用できない
この言葉を発する奴は論理性にかけている

本当にそんな現象あったらバグだからMsに報告しる

何もしてないのに壊れたとは (ナニモシテナイナラコワレナイとは) [単語記事] - ニコニコ大百科
https://dic.nicovideo.jp/a/%E4%BD%95%E3%82%82%E3%81%97%E3%81%A6%E3%81%AA%E3%81%84%E3%81%AE%E3%81%AB%E5%A3%8A%E3%82%8C%E3%81%9
721仕様書無しさん
垢版 |
2019/02/23(土) 12:13:22.21
何もしてないのに壊れたとは (ナニモシテナイナラコワレナイとは) [単語記事] - ニコニコ大百科
https://dic.nicovideo.jp/a/%E4%BD%95%E3%82%82%E3%81%97%E3%81%A6%E3%81%AA%E3%81%84%E3%81%AE%E3%81%AB%E5%A3%8A%E3%82%8C%E3%81%9F

貼りそこねた
2019/02/23(土) 12:14:12.68
>>719
マジで？知らん
どういうケースがあるの？
2019/02/23(土) 12:14:41.67
ここまでのレスフローを見れば一目瞭然
GCを理解してない者ほどGCを嫌う
724仕様書無しさん
垢版 |
2019/02/23(土) 12:15:54.79
>>715
頭悪いなwwwwww

つまり、君がとても効率だと思っているその「GC」自体がとても非効率なもので、
しかも君はその非効率な「GC」でのメモリ解放しか知らないから、
手動でメモリフリーしてた場合にいかに効率的にメモりを扱えるかを、知らないんだよwwwwww

さすがに頭悪すぎて笑いしかこみ上げないわ
その程度の理解力で他人にマウントを取ろうとかアホすぎるwwwww
725仕様書無しさん
垢版 |
2019/02/23(土) 12:16:35.57
>>720
https://codeday.me/jp/qa/20190123/140835.html

似たようなやつ
2019/02/23(土) 12:17:18.30
>>711
ソース見せて
2019/02/23(土) 12:17:22.64
ＧＣはマニュアル車とオートマ車の違いだからー

分けて考えよー
2019/02/23(土) 12:18:32.24
>>722
そうだなとりあえずMSDNを何ページか読んでごらん
「この関数で確保したリソースはどんな場合でもプロセス終了時に自動かつ安全に解放される」と仕様で明記された物なんて見当たらないだろ？
729仕様書無しさん
垢版 |
2019/02/23(土) 12:18:50.81
>>726
業務だからみせられねえよwwwww
そもそも自宅にはvsすらインストールしてない
730仕様書無しさん
垢版 |
2019/02/23(土) 12:19:27.32
ウンコぶりぶり。
2019/02/23(土) 12:21:46.80
>>728
あごめんwindowsか
安全かは別でブッチギリでも開放されれば良い

winだとしても死んだプロセスが(他のプロセスが足引っ掛けてない限り)
開放されない具体例があれば・・・
2019/02/23(土) 12:21:48.82
>>724
もう諦めろって

非効率なGCしか知らなかったら
手動のメモリ管理のほうがGCよりも効率的だと考えるようになるだろ

キミの主張は本当におかしいぞ大丈夫か？
2019/02/23(土) 12:22:59.60
連投ごめんにょ
死んだプロセスが握ってたリソース開放しないってＯＳのＧＣ的なアレのバグじゃん？ｗ
734仕様書無しさん
垢版 |
2019/02/23(土) 12:24:33.51
>>720
あとこれの下の方とかみときな、
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12190857167

using、disposeしてても結局GCの実行タイミングで解放されるから
明示的にGCを呼ばないとGCが実行されなきゃ解放されない
2019/02/23(土) 12:25:50.89
Javaエンジニアで手取り14万円と生活保護はどちらがホワイトですか
2019/02/23(土) 12:26:47.92
>>731
windowsだけの話じゃない
他のOSでもいいからシステムコールの仕様を読んでごらん
737仕様書無しさん
垢版 |
2019/02/23(土) 12:30:56.93
>>732
だからおまえは勘違いしてるんだよ

GCは「効率的」なのではなく「利便性」がいいんだよ。

一番効率がいいのは、メモリを取得したいタイミングで取得して使い終えたら即解放だろ
でもGCだと即解放ではなく定期的にたまったメモリ解放している
これは明らかに非効率的だが、その分メモリ解放の手順を省くことができる、だから利便性は向上する

利便性と効率的を履き違えるなよ
利便性に頼るのはいいが、器械的判断な分、どうしても想定外の動きになってくるから、最低限本来の動き把握しておけよな、って話
そしてその本来の動きを把握するのはオブジェクト指向から入る奴には難しいって話だ
738仕様書無しさん
垢版 |
2019/02/23(土) 12:32:12.82
>>698
＞　そうそう
＞　GCは悪、マニュアルでメモリ管理しなきゃダメとか言っちゃう残念な子とかね
＞　決めつけは、経験が浅い若者に多いネ

GCが悪とは全く書いてなくて、単なる選択の問題としか書いてないのに、
どうすれば、そういう馬鹿ま妄想が湧くのか？

おまえ相当な馬鹿だな。
プログラマじゃなくて単なる中卒の馬鹿コーダーだな（笑）
739仕様書無しさん
垢版 |
2019/02/23(土) 12:35:02.98
お前らみんな、マシン語からやり直せよ。
740仕様書無しさん
垢版 |
2019/02/23(土) 12:35:17.42
最近多いんだよな、
プログラム側の機能に丸投げすれば何でもやってくれるからと勉強しない若い奴
2019/02/23(土) 12:46:16.81
>>737
即解放が効率的とか笑わせんなよ
メモリ管理は確保より解放のほうが比重がデカイんだよ
解放が頻繁に実行されるってことはそれだけパフォーマンスが悪くなるってことだ
だから即座に解放せずに暇な時やユーザーが見てなさそうなとこで纏めて解放するのが効率的なんだよ

さっきから何度も言ってるが
まずは基本的なことを抑えてから話してくれ
それともうとっくに詰んでるのに戦おうとしないでくれ
2019/02/23(土) 12:47:31.11
>>738
実際にそういう子がこのスレにいるんだよ
どもレスとは言わないけど自覚はあるんじゃないかな
743仕様書無しさん
垢版 |
2019/02/23(土) 13:14:33.44
大手SIerには技術者のレベルで中小、ベンチャーなんか比にならない程のずば抜けた人間がいる
現場には出てこないが、MITの院で学んだような人間が社内で技術研究を続けている
派遣の人間なんかでは顔も見た事がないだろうが
744仕様書無しさん
垢版 |
2019/02/23(土) 13:18:19.06
顔も見ることもねー天才のことなど知ったこっちゃねーやな。
勝手に高い給料貰ってランボルギーニにでも乗ってろよ。
2019/02/23(土) 13:20:35.90
>>743
社内標準とか社内フレームワークって彼らが作ってんの？
2019/02/23(土) 13:27:17.09
>>745
下っ端正社員が作ってる
エリート組は売り上げには全く関係してない
2019/02/23(土) 13:29:10.18
NTT研究所とGoogleの研究者はどちらが優秀ですか
2019/02/23(土) 13:31:33.58
>>746
なるほど
道理で出来が悪いわけだ
749仕様書無しさん
垢版 |
2019/02/23(土) 13:31:55.08
今はもう人売りでしか稼げない時代だからねぇ。
技術研究なんてのは昭和の時点でほぼ・・・
2019/02/23(土) 13:34:22.11
NECや日立の研究者って東大やアメリカの大学に出入りしてて会社にいないでしょ
751仕様書無しさん
垢版 |
2019/02/23(土) 13:35:07.52
>>725
言語特有の問題とライブラリ特有の問題をごっちゃにする男の人って・・・
>>734
知恵袋の回答を鵜呑みにする男の人って・・・

https://softwareengineering.stackexchange.com/questions/304941/clarification-on-dispose-method

DisposeとusingはGCの管轄外のリソースの解放を行うための仕組み
どう実装するかはあなた次第
752仕様書無しさん
垢版 |
2019/02/23(土) 13:38:19.86
>>749
NTTデータ先端技術は、
地方から馬鹿なド素人を人売りしてるけど、
NTT,ドコモ、NTTデータなどのNTTグループに人を売りまくって
むちゃくちゃ稼いでるらしいね
やはり人売りが最も儲かる
2019/02/23(土) 13:41:10.21
>>750
＞NECや日立の研究者って東大やアメリカの大学に出入りしてて会社にいないでしょ

中学生にアンケートとって将来の夢でIT技術者になりたいというのが一番だったらしいが、それってこういう人のイメージなんだろうな
ITの研究者なんて東大入るより難しいわ
そんなの連中は全体の0.001パーセント

IT技術者の半分は現場のIT建築家、残る半分は非正規底辺のIT土方
このスレはIT土方の巣窟
754仕様書無しさん
垢版 |
2019/02/23(土) 13:49:29.50
Disposeをどう実装するかはライブラリ次第なので

1. Disposeの実装にバグがあって解放されない
2. そのリソースが内部では参照カウントで管理されていて、Disposeしても参照カウントが減るだけ。参照を握っている他のリソースも解放しないと解放されない

と言うこともある。
>>725は2.のパターン。関連するリソースを全部Dispopeしないといけないってのはわかりにくいので、そもそもそんな実装にするのが問題な気はするが。

弱参照のようにして、「このリソースさえ解放すれば紐づくリソースは全て解放される」ってした方が分かりやすいかもしれない。

https://stackoverflow.com/questions/12532729/sqlite-keeps-the-database-locked-even-after-the-connection-is-closed
2019/02/23(土) 14:02:26.35
Javaがーっていつからこのスレにいるのか知らんけど
多分最初はまともだったのに反論されて壊れちゃったんだろうな
2019/02/23(土) 14:20:05.52
最初から壊れてたよ
757仕様書無しさん
垢版 |
2019/02/23(土) 14:22:08.87
プログラマーの資質があって
営業もできるぐらい社交性ある奴は
１００パーセント出世してることに気づいた
758仕様書無しさん
垢版 |
2019/02/23(土) 14:36:07.77
>>741
アホまるだしwwwww
頻繁に使うバッファなら解放せずに保持しつつけるし
一回だけ使ったら不要になるようなのは即解放、残してる方がパフォーマンス悪いぞ

おまえが言う解放の方の比重が重いってのは何を根拠に言ってるかわからんけど、
カーネルレベルではmallocに対してfreeが1セットそれぞれメモリのポインタを構造体チェーンに繋げなおすだけの作業なんですけど
759仕様書無しさん
垢版 |
2019/02/23(土) 14:39:33.20
C#にはファイナライズという機能があるが
これはDisposeし忘れたり、アプリ終了時にリソースを解放するための仕組み
手動で解放するのは常に可能

GCしないと解放されないとか言ってた奴は
手動で関係するリソースを全部Dispose（またはusingを使う）しなかっただけの恥ずかしい奴と言う事が確定した

https://blogs.msdn.microsoft.com/tom/2008/04/25/understanding-when-to-use-a-finalizer-in-your-net-class/
760仕様書無しさん
垢版 |
2019/02/23(土) 14:46:04.20
>>758
>一回だけ使ったら不要になるようなのは即解放、残してる方がパフォーマンス悪いぞ
釣り針でかいわ〜
2019/02/23(土) 14:48:21.26
確保と開放繰り返してたらパフォーマンス悪そう
762仕様書無しさん
垢版 |
2019/02/23(土) 14:49:54.99
>>751
その貼ってあるURLは何が言いたいの？
外人の書き込みを読んでる俺凄いアピール？

その外人らはただ単にsqliteコネクトはdisposeしなければ自動GCされないから、using内でやれば自動的にdisposeしてくれると言ってるだけだけ、

さっきから討論してるのは、disposeしても明示GCしなけば解放されないことがあるという、その外人の書き込みよりも後の処理の話をしてるんだけど
君アホすぎない？
763仕様書無しさん
垢版 |
2019/02/23(土) 14:50:35.30
>>702は早く間違いを認めて謝って
2019/02/23(土) 14:50:48.31
IT土方でかつ薬飲んで発狂して一人で暴れてるんだからそりゃ無職にもなるわな
765仕様書無しさん
垢版 |
2019/02/23(土) 14:52:27.73
>>759
さっきからusingもdisposeもしてるのに明示GCしないと解放されないって言ってるので
おまえが流れ読まずに発言してるバカってことが判明した
766仕様書無しさん
垢版 |
2019/02/23(土) 14:53:11.92
>>762
お前がDispose忘れただけだろって言う話
そのリソースを参照してるリソースを全部Disposeしてないから
メモリリークした

それが手動GCした事でFinalizeされて解放されたのを
手動GCしないと解放されないと勘違い
滅茶苦茶恥ずかしい奴だ
2019/02/23(土) 14:53:46.60
>>758
繋げ直すだけ(笑)
物理法則がシンプルなパラレルワールドに在住のようで羨ましい限りです
2019/02/23(土) 14:54:10.72
>>764
絶対に一人で会話してるよなw
この人は脳内で架空の友達作って会話してるわ
池沼ってヤベーよw
769仕様書無しさん
垢版 |
2019/02/23(土) 14:55:03.74
>>760
>>761
確保と解放を繰り返すってそういう発想自体バカだろ
確保したメモリはループで使い回すんならそもそも解放しない
解放する場合はその後一切使われなくなるとき
newに頼ってるとおまえみたいに基本すらできない
770仕様書無しさん
垢版 |
2019/02/23(土) 14:55:46.38
>>766
usingの処理を理解してない発言だな
771仕様書無しさん
垢版 |
2019/02/23(土) 14:56:48.16
>>767
そりゃおまえはGCでしかメモリ解放をしらないもんな
GCてメモリ解放してたらそりゃ無駄な処理が走って重くなるわなwwww
772仕様書無しさん
垢版 |
2019/02/23(土) 14:59:53.39
>>766
usingを抜けた後もdisposeが必要だと思ってる？
773仕様書無しさん
垢版 |
2019/02/23(土) 15:02:59.98
>>770
>>772
usingがDispose呼ぶだけなのは知ってる
問題はそのライブラリのDisposeの実装だろ

https://stackoverflow.com/a/12679840/2129038
774仕様書無しさん
垢版 |
2019/02/23(土) 15:12:12.07
>>773
つまりはクソってことだろ
そこまで意識してコード書いてる奴なんてこのスレに一割もいない
通常のあり方であればusingを抜ければ自動でGCされなきゃ仕様としておかしい
だからGCは不完全、メモリリークの温床
775仕様書無しさん
垢版 |
2019/02/23(土) 15:12:43.78
昔のバージョンのSystem.Data.SQLiteではコネクション以外にも二種類のリソースをDisposeする必要があった

Update 2012-11-27 19:37 UTC: this is further confirmed by this ticket for System.Data.SQLite, in which a developer explains that "all SQLiteCommand and SQLiteDataReader objects associated with the connection [should be] properly disposed".

コネクションをDisposeしたのにコネクションがクローズしない、コネクションプールも使ってないのにとか言ってる奴は
コネクションに関連付けられたSQLiteCommandとSQLiteDataReaderをDisposeしていなかっただけだった

しかしながら、この設計がそもそも分かりにくいので、
後のバージョンでは色々な種類のリソースをDisposeしまくらなくて良いように修正された模様
776仕様書無しさん
垢版 |
2019/02/23(土) 15:19:24.04
>>774
Disposeのし忘れの問題は
C言語でmalloc, freeしてたり
参照カウント使ってた頃の問題と本質的に同じじゃん。

freeを忘れたり、参照カウント減らすの忘れるとリークする

C#はファイナライズがあるので、最悪の場合でもいつまでもリークするのを防げるってだけ（関連付けられたC#のオブジェクトが到達不能になってれば）
777仕様書無しさん
垢版 |
2019/02/23(土) 15:23:54.21
C#でまともにDispose（using）出来ない奴が
言語組み込みGCのないC言語やC++で作っても
更にメモリリークが酷くなるだけだろう
778仕様書無しさん
垢版 |
2019/02/23(土) 15:27:07.77
だから前に言っただろ。
returnは最後にひとつだけにしろって。

for文のループ内でreturnなんてやってる時点でもう・・・
2019/02/23(土) 15:32:13.04
>>776
だけ、とか言ってるけどそれって天と地ほど差があるんだが
780仕様書無しさん
垢版 |
2019/02/23(土) 15:36:22.67
>>779
ファイナライズがある分だけC#の方がマシだよな

いつファイナライズされるかは分からないので
忘れずに解放した方が良いのはどちらも同じ
781仕様書無しさん
垢版 |
2019/02/23(土) 15:43:01.44
>>776
disposeのし忘れではない

構造的には
usingでsqliteコネクション、データを取得してusing抜けて配列をリターンする
そのリターンされたリソースを使い続けるので解放はしない。

その状態で再度usingでsqliteコネクション、updateで既にテーブルがロックされていて失敗になる
782仕様書無しさん
垢版 |
2019/02/23(土) 15:47:08.32
コードも出さずに質問する奴はStackoverflowでも嫌われるぞ！
2019/02/23(土) 15:51:58.26
>>781
それをDisposeし忘れっていうんだよ
784仕様書無しさん
垢版 |
2019/02/23(土) 15:55:35.37
>>781
ちゃんとusing使ったか？？
https://qiita.com/koshian2/items/63938474001c510d0b15
2019/02/23(土) 15:57:52.00
生メモリ使う人って原発は厳重に管理してるから事故を起こさないって主張してた人と同じなんだよ
事故が起こっても被害を最小化する仕組みを作ることが大事なんだ
それがわかってない新人くんにはまだシステム開発は任せられない
786仕様書無しさん
垢版 |
2019/02/23(土) 15:58:40.21
>>784
これ見るとSQLiteを直に使う場合はコネクションだけじゃなくて
やはり全種類のリソースで解放が必要なように見える
787仕様書無しさん
垢版 |
2019/02/23(土) 16:12:51.92
>>778

Cとかなら、そういう寝言言うのもまあ許せるかな。
2019/02/23(土) 16:24:27.46
returnは最後に一つだけw
789仕様書無しさん
垢版 |
2019/02/23(土) 16:28:55.63
おまいら土曜日までマジになるなよ
疲れるだけだろ？
もうちっと心をゆったりするために
5chなんて見てないで外へ出て散歩でもすべし！

まあ、そういう俺は散歩の途中で
5chしてるわけだがwww
2019/02/23(土) 16:30:15.80
マニュアルメモリ管理をすると急に最後以外のreturn禁止とか言い出す
なにかよくわからないがマニュアルメモリ管理には人を惑わす魔術的な何かがあるのだろう
2019/02/23(土) 16:32:13.26
>>789
特に理由はないんだが一時期5ch断ちしてたんだが心身ともに健康で毎日が楽しかったよ
でも戻ってきちゃうんだなぁ
792仕様書無しさん
垢版 |
2019/02/23(土) 16:36:28.85
>>790
最後リターンは俺じゃねえぞ
793仕様書無しさん
垢版 |
2019/02/23(土) 16:49:31.87
メモリーリークの話と後、演算子の優先順位の話にも同じことを感じるんだが、
必要なことを全部暗記して、その都度その都度プログラマが細心の注意を払ってコーディングすることで品質を確保しようって奴が驚くほど多いな

とてもじゃないが付き合いきれん
2019/02/23(土) 16:54:17.14
ちょっとは覚えてくれんと
言語が保証してくれる信頼性を無視すんなし

String宣言で必ずnew String()ってやってるやつおい
2019/02/23(土) 16:55:45.56
言語の文法覚えるのと社内規約覚えるんじゃ
絶対文法の保証覚えたほうが得だろ！？
2019/02/23(土) 17:06:18.90
>>794
それぐらいコンパイラがどうにかしてくれないのか
2019/02/23(土) 17:15:43.82
>>793
車に乗るなら最低限、免許を取るだけの知識と技能は必要でだろう。人間のミスによる事故を防ぐ技術はどんどん開発する必要があるし現に進歩しているが、限界はある。車が必要な仕事に従事するなら、当然最低限求められるラインはある。
バカでも無能でも事故を起こさないようにゴーカートしか使えません、というならゴーカートで事足りる仕事だけやってろよ。
798仕様書無しさん
垢版 |
2019/02/23(土) 17:17:22.14
言語の文法を覚えるのは悪いことじゃないけど
文法を暗記してなきゃ品質が下がるような開発スタイルはおかしいだろって話
799仕様書無しさん
垢版 |
2019/02/23(土) 17:23:48.65
>>797
そんなのケースバイケースでバランスの問題だら
高すぎれば誰も車が運転できなくなるし、低すぎれば事故が多発する
この種の問題で最低と最高のケースしか考えないのは思考停止の典型
2019/02/23(土) 17:26:07.80
２ｃｈでそれをいうと議論が停止して結果的にみんな思考停止という矛盾
2019/02/23(土) 17:30:07.30
>>729
再現もできないのね
802仕様書無しさん
垢版 |
2019/02/23(土) 17:31:16.48
まあでも今時仕事の話でソース見せては無理な相談
803仕様書無しさん
垢版 |
2019/02/23(土) 17:58:00.21
>>791
俺これから5ch断ちするわ
じゃ、さいなら！
2019/02/23(土) 18:03:19.49
>>803
おう
また明日な
805仕様書無しさん
垢版 |
2019/02/23(土) 18:04:26.02
一個言語覚えたら後はそれの応用だろ
最初の言語覚える時間を１０としたら
次の覚えるにかかる時間なんて１ぐらいだろ
2019/02/23(土) 18:04:36.19
おまえが戻ってくるの待ってるから
2019/02/23(土) 18:19:05.07
普通に制約に反したコードがぶっ混んでいて笑った
そりゃ動いていればさえいれば問題ないだろうけどさ
2019/02/23(土) 18:20:28.84
似たような言語ばっかやってるとそう思うんだろうけど、パラダイムが違うと全然コストが違うぞ
Java書けるようになった人がC#学ぶ時間とHaskell学ぶ時間が同じとはならないでしょ
809仕様書無しさん
垢版 |
2019/02/23(土) 18:34:56.00
Java からC#はある意味悪夢だわ
同じようでいて微妙に違うというか
悪い意味でなんでもできるようにしすぎ
2019/02/23(土) 18:35:49.91
Ｃ＃すげー楽じゃん
2019/02/23(土) 18:37:50.65
C#覚えちゃうと快適すぎてJavaには戻れんわ
Javaは悪名高いVB.NETよりめんどくさい
2019/02/23(土) 18:40:58.60
>>807
オマエハ日本語ニ違反シテルゾ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況