C#, C♯, C＃相談室 Part88

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


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

1 名前：デフォルトの名無しさん mailto:sage [2015/07/25(土) 16:14:05.15 ID:I42JqLkf.net]: ■Visual Studio 2013 Community & Express(無償の統合開発環境)等はこちら
www.visualstudio.com/downloads/

■コードを貼る場合はこちら
ideone.com/

■前スレ
C#, C♯, C＃相談室 Part87 [転載禁止](c)2ch.net
peace.2ch.net/test/read.cgi/tech/1427558696/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
641 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 20:31:02.28 ID:MIhiF6BJ.net]: おうかかってこいやチキン野郎
642 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 20:50:07.75 ID:JbH8lT1Q.net]: >>625
コンセプトとしてはその通りだけど、ID:hc4Y2Ev5が言っているのもまた然りだと思うよ。

本来は、全部GCに任せた上で、理由がある場合のみ手動でDisposeという仕様を目指しているのだと思う。
現実的にはこれはほぼ完成しており、通常の範囲で問題になることはない。(少なくとも俺は命中していない)
ただ、MSDNで
> 基本クラスが IDisposable を実装する場合は、オブジェクトは基本クラスの Dispose メソッドも呼び出す必要があります。(611)
と言っている以上、Finalizerだけでは駄目なケースがあって、それに命中する可能性も残っているのだと思う。
とはいえ、普通に実装すればFinalizeはまずDisposeをコールするだろうから、
問題が発生�
643 名前：ｷるとしたらタイミングだけのはずだけど。 確認してみたけど、C#のデストラクタは起動を予約してGCから起動するという仕様のように見える。 > http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_011/csharp_abc03.html 確かにこれだとFile等はClose/Disposeをしないといつロックを解除してくれるか分からない。 だから>>627-628の言うことはあっている。620の3つのケースもあり得ると思う。 理由は指摘の通り、C#ではデストラクタの起動順/タイミングが規定できないからだね。 []: [ここ壊れてます]
644 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 20:50:20.22 ID:1KB/gLgO.net]: >>584
特定の方法でインスタンス作った時にだけ意味があるというのは割りとある
例えば、FormをShowした時とかは自動でDisposeされるから不要
645 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 21:31:38.21 ID:hc4Y2Ev5.net]: >確かにこれだとFile等はClose/Disposeをしないといつロックを解除してくれるか分からない。
ファイルオブジェクト的な物を使う側ではなく作る側で、実際にいろいろやってみて面倒な事になってるなと思ったのは
フィールド上に確保していたバッファがデストラクタ中のクローズ処理よりも先に解放されてしまうなどですかね
アンマネージの場合はこの辺は実にすっきり記述できるんですが、マネージでは厄介です

初心者の時
~Class() { Dispose(); }
なんて事をあまり深く考えずにやってました、そして謎の異常終了を発生させてましたね
Disposeが呼び出されずにデストラクタが呼び出されたら、できることはもはや安全停止だけです
まともな終了処理は最早できません
646 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 21:35:34.12 ID:OpHxID+X.net]: C++のノリでデストラクターを間違った使い方して
GCの洗礼を受けたのはわかった
647 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 21:37:58.50 ID:aJXfAZiV.net]: もうskypeで議論して最終的に友情をめばえさせたら？
C#である必要もないし
648 名前： ◆QZaw55cn4c mailto:sage [2015/08/23(日) 21:38:38.49 ID:GHcBJPT0.net]: C++ でも delete this は普通やらない‥
649 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 21:40:51.66 ID:hc4Y2Ev5.net]: デストラクタ的な機能が欲しければC#ではDisposeしか手段が無いんです
ファイナライザは使えません、その処理はシステムに任せることはできないのです
それが分かっていないと安易にDispose不要という考えが出てしまいます
650 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:03:58.87 ID:pgaNpm//.net]: はいはいちごいねー

死ね
651 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:09:13.04 ID:oScCmTRi.net]: おい待てよ
Dispose不要派は
1.ファイナライザーでやればいいんだぜ
だけじゃなくて
2.解放など軟弱もののやることだってボクの環境で問題になったことないんだもん
の方が多数派だろ
652 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:11:48.27 ID:rrCWAeC5.net]: >>641
うるせえ喋んなカス死ね
653 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:13:14.66 ID:nxY8tWuM.net]: ここまで全部俺の自演
654 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:16:59.42 ID:1KB/gLgO.net]: >>633
IDisposableを実装している場合は、明らかに不要な場合以外は使い終わった後にすぐDisposeすべき
PenもBrushも中にGDIのハンドルを抱えてるわけで、アンマネージドのシステムリソースやメモリを必要以上に使ってしまう
ファイナライザは残っていると仕様上開放が先延ばしになって長時間メモリを占拠するから、想定よりコストは高い

>てか、gcnew って delete しなくていいためのものじゃなかったんかー！
WindowsがすべてGCの管理上で動くようになればな。GC管理外のデータはプログラマが責任を持たざるをえない
655 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:21:09.75 ID:hc4Y2Ev5.net]: コストに関しては、昨今はシビアなノーパソでもない限りは自分はあんまり気にしなくなってたりしますw
ロジック的にDisposeが必要不可欠な物の方を意識したいところです
656 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:24:17.01 ID:prCrabVF.net]: そういやVS2015から、IDisposable選択して右クリック→クイックアクションで、
Disposeのひな形吐き出してくれるんだよな。便利になったものだわ
657 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:29:32.06 ID:MIhiF6BJ.net]: 最初から何度も言ってるがこれが正解な

1. Disposeしないと機能的にアウト→Disposeする
2. 機能的に問題ないがボトルネックになる→Disposeを許す
3. 機能的に問題ないうえに負荷も軽微→自動化しろ手で書くな

クライアントは殆どが3なんだわ
Disposeなんか要らないんだよ
これが今日のまとめね
658 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:33:20.72 ID:hc4Y2Ev5.net]: 3. 機能的に問題ないうえに負荷も軽微→元クラスのIDisposeを除去せよ
これが正解です
659 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:37:13.05 ID:YS/VElDC.net]: 1日かけて成果物3行って舐めてるのか貴様ら
660 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:37:24.13 ID:JbH8lT1Q.net]: >>639
仰るとおり、C++→C#へのポーティングではC#のデストラクタには期待できないから、
いちいち手動で順番も考慮してDispose()しかなさそうだ。
ただこれはだいぶ手間だから、何らかの上手い解決策が既にありそうだけどね。

仕様から言って、C#ではデストラクタの起動順を期待するコーディングをしてはいけない。
ただ、
> フィールド上に確保していたバッファがデストラクタ中のクローズ処理よりも先に解放されてしまうなどですかね (635)
これはよく分からない。(これが発生する可能性がシステム的にあることは分かる)
とはいえ、C#って多重継承できないし、アンマネージドとマネージドを混ぜてぐちゃぐちゃにしたりすることがなければ、
これって無いよね？
(逆に言えば、マネージドコードだけならこういったことは発生しない、と思っている。
そして本来はアンマネージドを大量に使うことこそが問題。ポーティングならある程度致し方ないにしても。）
661 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:37:59.91 ID:hc4Y2Ev5.net]: ここにはゲーム等、ハイパフォーマンスが必要になる人もいるでしょう
その時Disposeしなくても問題ないと開発元に確認できた、Disposeしない方が高速である事が確認された
そして、それをする事でソフトの商品価値が向上する、この条件でDisposeしないを選択するのが正しいと思う
それ以外は必ずやらなければ駄目です
662 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:38:00.89 ID:HkRU0Alf.net]: 機能的に問題ないがDispose使わないとボトルネックになるなんて
どんな状況だよ
663 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:38:38.88 ID:MIhiF6BJ.net]: >>649
行数にこだわるのは老害の証
現代のプログラマは中身を見ないと
664 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:39:55.83 ID:+kgkAxfw.net]: >>647-648
「だから何」レベルのまとめはQiitaにでも書いといて
あと死ね
665 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:41:15.09 ID:prCrabVF.net]: なんかしらんが、このレベルの話題が一番盛り上がるよな
上でも下でもこうはならん
666 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:42:20.89 ID:bbkyb+Wi.net]: 毛の壁を笑えんよこれは
667 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:45:56.71 ID:hc4Y2Ev5.net]: >>650
マークスイープでは順序を決めることができないんですよ
循環した参照がある場合どこから削除すべきかという判断材料がなくなる、ならば最初から順番は無視という判断なのだと思います
実際ガベコレ毎に順序は出鱈目です、気を付けてください
C++の場合、例えば循環参照があったらメモリーリークですが、プログラマのレベル高いから平気だよねってコンセプトではない訳です

それにしてもC++の芋ずる式デストラクタは気持ちいいです・・・
668 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:53:59.24 ID:MIhiF6BJ.net]: >>650
マネージドだけでも普通に発生する
バッファが回収可能になるのと所有者インスタンスがFRQにぶち込まれるタイミングはほぼ同時
どっちが先に処理されるかは誰にもわからない
669 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:58:36.70 ID:MIhiF6BJ.net]: というのは嘘だ
670 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 22:59:24.15 ID:rRq+bYgY.net]: >>659
そうかい
では死ね
671 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:01:02.88 ID:MIhiF6BJ.net]: >>660
しゃぶれよ
672 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:02:56.73 ID:5fcokCbE.net]: バカには難しかったかな
クラスAのオブジェクトaはクラスBのオブジェクトbを参照しているとする
A a = new A();
a = null;
ここでaとbが同時に解放対象になって、aとbの解放順序が非決定的
673 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:04:45.05 ID:9aqT3FI6.net]: 何でそんなサンプルコードが必要だと思ったの？
674 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:06:20.29 ID:JbH8lT1Q.net]: >>657
見た目はマークスイープだけど、中身は参照カウント方式だったはず。(だからそれなりに順を追ってGCされる）
というのを中の人が書いたドキュメントがあったはずだが、検索しても今はでてこない。
ブクマによると多分以下なのだが、アーカイブになっていてどれなのか分かりませんorz

Microsoft .NET Framework の自動メモリ管理 Part I
msdn.microsoft.com/ja-jp/library/bb985010.aspx
675 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:07:02.82 ID:hc4Y2Ev5.net]: C++の人は、ここをミスしやすいと思うし、見ている印象結構C++からやってきた人多そうだから
悪くないサンプルだと思うのですが・・・
676 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 23:10:23.32 ID:MIhiF6BJ.net]: >>662
と思うじゃん？
677 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:08:47.57 ID:genYk8wg.net]: さてまとめるか。
「不必要にDisposeを量産するバカが多いため
usingを怠る悪習が蔓延した」
678 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:31:00.45 ID:e5Jihg5N.net]: IDisposeを持つオブジェクトを握るオブジェクトはIDisposeを持つしかない
不用意でなくても普通に増えるしかないよ
IDisposeを持つ物は Stream や Task があるがどれも基本的なクラスばかりで避けては通れない
679 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:35:53.34 ID:4CFfNfbx.net]: >>662
さすがにそのケースでのリークはないよね？

Array等の中身として参照を持っているだけなら、
そもそもデストラクタがどちらから呼ばれても問題ない。

継承関係なら自動でやってくれるはず。
自作クラスで継承以外で引っ張ってきている場合、必要ならデストラクタにその順通り書けばよく、
デストラクタがいつ呼ばれるかは問題ではない。
(自作クラスの一つのデストラクタだけで済むように構成する。
ただしリソース解放が必要ならDisposeを実装しないとタイミングが読めない。)

菱形継承で先に基底クラスが解放されたりするのは問題になるけど、C#にこれはない。

だから問題になるのは、一度しか呼ばれないアンマネージド側で
マネージドのデストラクタが呼び出し済みなのを期待している時で、多分これだけだよね？
マネージド側は放置しててもなんだかんだでいつかはGCされるはず。
それが嫌ならDisposeしろって事で。
だから、アンマネージドを先に全部解放するようにすれば、問題は発生しないと見た。
680 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:36:24.75 ID:4CFfNfbx.net]: なお、MSDNのデストラクターにまんま書いてある。
> デストラクターがいつ呼び出されるかはガベージコレクターによって決定されるため、プログラマは制御できません。
> 一般に C# では、ガベージコレクションを使用しない言語で開発する場合ほど、メモリ管理を必要としません。
> .NET Framework のガベージコレクターが、オブジェクトに対するメモリの割り当てと解放を暗黙的に管理します。
> ただし、ウィンドウ、ファイル、ネットワーク接続などのアンマネージリソースをアプリケーションでカプセル化するときは、
> デストラクターを使ってこれらのリソースを解放する必要があります。
> アプリケーションで貴重な外部リソースを使用している場合は、
> ガベージコレクターがオブジェクトを解放する前にリソースを明示的に解放する手段を用意することをお勧めします。
> この処理を行うには、オブジェクトに対して必要なクリーンアップを実行する Dispose メソッドを IDisposable インターフェイスから実装します。
> これによって、アプリケーションのパフォーマンスを大幅に向上させることができます。
> このようにリソースを明示的に制御する場合でも、
> デストラクターは、Dispose メソッドの呼び出しが失敗したときにリソースをクリーンアップするための安全装置になります。
> https://msdn.microsoft.com/ja-jp/library/66x5fx1b.aspx
681 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:42:37.88 ID:e5Jihg5N.net]: C#の場合デストラクタでやっていいことは、static関数の呼び出しくらいだろうな
class型フィールドの内容に触ることはできない、触ってよいのは int や enum といった値のフィールドだけ
それ以外の操作をしたければDisposeを使うしかない
順序良く呼び出されたとしてもこれでは何もできない
682 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 00:51:10.64 ID:OjRQ25eS.net]: ID:4CFfNfbx
この人は何言ってるかわからなくて、頭くらくらしますよね
そもそも話が通じてないし
683 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 01:04:15.56 ID:e5Jihg5N.net]: C++からのポーティングが引き返せないところまで来ているのかもw
笑っちゃいけないか、ご愁傷様かな(ナムナム
684 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 07:38:39.63 ID:FEQDPFGC.net]: なんか、マネージド/アンマネージドコードとマネージド/アンマネージドリソースがごっちゃになってる人がいるように見えるのは気のせいだろうか。
685 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 07:41:36.51 ID:xNseMvgF.net]: 蒸し返すなゴミクズ
686 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 09:19:55.49 ID:h+mHYijt.net]: まだ続けるの？
687 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 09:50:06.14 ID:xNseMvgF.net]: もうウンザリ
688 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 10:58:39.56 ID:/7MwCGkP.net]: 嫌なら見るな
689 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 11:48:38.94 ID:Q0ZjIosN.net]: いや、低レベルな話がしたいならふらっと行けよ
だからテメエは無脳なんだ
690 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 12:27:15.22 ID:e5Jihg5N.net]: 一番低レベルなヤツ -> 679
691 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 13:03:00.83 ID:kR1o4QUh.net]: ここが隔離スレだ
692 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 15:21:00.93 ID:/7MwCGkP.net]: なんでいつも単発IDなんですかね
693 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 15:48:52.90 ID:CmRZDEoS.net]: 単発が嫌なら見るなよ
694 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 15:52:52.92 ID:mvfSohk+.net]: >>682
IDがきちんと出るようにするだけの技術力がないから…
695 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 20:40:58.44 ID:UIihvy++.net]: C#って内部実装変えただけでも依存するアセンブリビルドしなきゃなの？
696 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 20:45:58.83 ID:xp4qRvA3.net]: 必要なし
697 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 21:02:14.07 ID:aDhIIP+g.net]: ザマリン標準化まだ時間かかりそうですか
698 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 21:25:54.27 ID:vU2SL/AS.net]: Xamarinは目先の金儲けしか頭にないから期待しても無駄
699 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 21:46:54.78 ID:8rH+FULH.net]: >自作クラスで継承以外で引っ張ってきている場合、必要ならデストラクタにその順通り書けばよく、

これ正しいの？
700 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 22:31:14.60 ID:vU2SL/AS.net]: そのファイナライザ内だけで完結するんならそりゃそうだろ
・
701 名前：AとBが両方ともアンマネージリソースを抱えている ・AがBを参照している ・ネイティブライブラリの仕様でBはAより先に解放しなければならないと決まっている こういう状況では当然単純にAとBのファイナライザに頼るわけにはいかない Bにはファイナライザを実装しないでAのファイナライザ内でBのリソースを解放し、 その後にAのリソースを解放するといった工夫が必要になる []: [ここ壊れてます]
702 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 23:17:12.96 ID:4CFfNfbx.net]: >>674
すまん、その通りだ。C#ではアンマネージドコードは禁止とは知らなかった。
解放しているのはunsafeで生ポインタだけか。
インラインアセンブラが出来るというのを見た覚えがあるのだが、気のせいだったようだ。
デストラクタも継承/オーバーロード禁止だから、>>671の言うとおり、staticにしか使えない。

C++からポーティングするなら、
デストラクタ内のは全部Disposeに移動し、そこで手動で親を呼んでおけばいい気がする。
これだとクラス内だけで留まる。
リソース解放タイミングを規定したいのなら手動でDisposeを呼ぶか、usingだね。
ただ、呼ばなくてもセグフォにはならないはず。

MSDNには
> C++ 経験者が C# で開発する場合
> デストラクタ : C# は、アンマネージリソースを確定的に解放する場合の構文が異なります。
> デストラクタ
> using ステートメント (C# リファレンス)
> https://msdn.microsoft.com/ja-jp/library/yyaad03b(v=VS.90).aspx
だけだから、推奨はusingのようだ。

マネージドコードだけしか使えないのなら、本質的なリークはどうやっても発生しないように思える。
一時的なリソース枯渇はあり得るけど、例えばGDIなら描画しまくるアプリ(ゲーム等）でなければあまり気にしなくてもいいのでは。
703 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 23:21:14.35 ID:agiYVVps.net]: >リークはどうやっても発生しないように思える

こういう馬鹿がプログラミングの真似事をするとロクなことがない
704 名前：デフォルトの名無しさん mailto:sag [2015/08/24(月) 23:23:09.51 ID:163KCsEM.net]: 簡潔に一度だけ言うね
ID:4CFfNfbxはあと三年ROMってから
それからカキコしようね
705 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 23:26:49.44 ID:OjRQ25eS.net]: これさー
メモリ以外のリソース、たとえばウィンドウハンドルやGDIオブジェクトetcがさー
枯渇とまでいかなくても、使いすぎと感知したタイミングでGCが発動する仕組みが.Net側にあれば、
usingとか、ファイルなんかの特殊な事例以外では、要らなくなるのでは？
GC発動のトリガーがメモリだけに依存しているから、いろいろ心配になるわけで
706 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 23:27:45.15 ID:vU2SL/AS.net]: ファイナライザ内で別のオブジェクトにアクセスするのは基本的には問題ないぞ
その別のオブジェクトがファイナライザを持ってる場合には
既にファイナライザが呼び出されて無効になっている可能性があるからダメというだけ
ファイナライザを持ってるオブジェクトから参照で辿れるオブジェクトはどのみち全部一度復活して
GCを妨害してしまうから、アクセスすることが特にGCの妨げになるということもない
一番悪いのは「ファイナライザを実装すること」自体な
707 名前：デフォルトの名無しさん mailto:sage [2015/08/24(月) 23:57:38.17 ID:e5Jihg5N.net]: ファイナライザに実装すべきなのは、安全装置だけだろう
例えばアンマネージドのハンドルを握っている場合
ハンドルはIntPtrだから、別のクラスに入れるといったことをせず直接フィールドに配置しているなら
アクセス可能だから、ここでリ参照カウンタをダウンすれば一応解放は可能
fopenみたいなものを相互運用している場合もハンドルとstatic関数をdllから呼び出せるなら
バッファのフラッシュは諦めるとしてもファイルを閉じることくらいはできる
いずれも最終手段レベルだね
708 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 00:04:34.64 ID:uHUYRmLo.net]: >>691
リーク問題については、あまり期待しないほうが良い
Excelの相互運用なんかをすると、当マイクロソフト製なのに結構厄介だし、洩れまくるし
自作でやってもなかなか糞な事になる
709 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 00:42:16.41 ID:FzRJlm7d.net]: すいません言い直します。

・C#では、正しく構成されたクラスを使用している限り、本質的なリークは発生しない。
(明示的にDisposeしなくてもいつか回収される《=Finalize時にDisposeが呼ばれる》）

じゃないかな？
もちろん.NET謹製のはリークしない。
自作クラスでアンマネージリソースを使う場合、MSDNによると、
・Disposeを実装し、SafeHandleでアンマネージリソースをラップする。←こっちがオススメ
・Finalizeを実装する。
のどちらかをやっておけばいいはず。
> https://msdn.microsoft.com/ja-jp/library/498928w2(v=vs.110).aspx

だからリークしてるのであれば、自作クラスの構成がまずいのだと思うのだが。
もちろんクラスの構成はC++流(デストラクタ)ではなくC#流(上記)にしないといけない。
710 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 00:50:30.42 ID:wg5Da8me.net]: ListAとListBの中身を1つずつ比較して、ListBの内1つがListAに無かったらそのオブジェクトを追加し
同じものがあれば追加しないと言う機能を作りたいのですが、foreachだと例外が出て、
for文だと無限ループになってしまいどうやっても上手く実装できませんでした。
一体どうすればListの中身を1つずつ比較して問題なく追加する事が出来るのか教えていただけないでしょうか
711 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 00:57:16.45 ID:bwlYR2I5.net]: 問題が起こる、最小のコードをアップしなさい
712 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 01:11:01.00 ID:wg5Da8me.net]: 色々書き換え続けて最終的にコンパイルすら通らなくなったんですが多分こんな感じです。
if (ListA.Count == 0) foreach (var li in ListA.a) ListB.Add(li);

else for(int i=0; i < ListB.Count; i++){
　 for (int x = 0; x < ListA.Count; x++){
if (ListA.a[x] != ListB.a[i]) ListB.Add(ListA.a[x]);

}}
713 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 02:03:56.13 ID:bwlYR2I5.net]: for( a: A )
for( b: B )
{
714 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 02:07:01.06 ID:bwlYR2I5.net]: 擬似コードですが、これでどうでしょう
for( a: A )
{
　　bool found = false;
　　for( b: B )
　　{
　　　　if( a == b ){ found = true; break; }
　　}
　　if( !found ){ B.push_back( a ); }
}
715 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 02:56:24.98 ID:wg5Da8me.net]: よく考えてみたら1つずつ比較してる最中、違った瞬間に追加するってコードになってました。
それで調べたら配列の中を比較するIndexofという機能をついさっき知って実装したところ、上手く動きました。
716 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 04:17:23.94 ID:ljTVrax0.net]: ListB = ListB.Union(ListA).ToList();
717 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 07:28:11.84 ID:uHUYRmLo.net]: >>698
shared_ptr weak_ptr の使い分けのように仕組みを意識して使わないと
システム任せだと無理があるんだよ、SafeHandleを使えば万事解決という訳にはいかない
そろそろ諦めなはれ、アンマネージと相互運用したければ覚悟決めるしかねーですw
718 名前：デフォルトの名無しさん [2015/08/25(火) 10:56:12.32 ID:y1FTBoUo.net]: アンマネージドとかどういう場面で使うんですか？
C言語とかの領域ですよね？
本見てもどういう場面で使うのか乗ってないんですが
719 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 11:03:08.95 ID:aUx99M6r.net]: アンセーフ？
720 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 11:33:21.01 ID:Wpti2W5K.net]: SafeHandleってサーバーで複数のドメインが1プロセスに同居するような特殊なシステムでない限り何の意味もないんだけどな
使いたがる連中のなかでそれを正しく理解してるのは少ない
721 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 11:43:43.66 ID:lyj94kL0.net]: まあ、C#は元々トロイからね、別に頑張って速くしたりするのは無駄だよね？(´･ω･｀)
722 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 12:20:15.95 ID:ya7qPQ7D.net]: トロイ？ゆうちゃん？
723 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 12:57:13.30 ID:UmUy/CWK.net]: >>707
普段コンビニとか外食でメシを食ってるひとが
まな板と包丁買ってきて自分で魚をさばくような話

君はずっとグルメガイドを見てればいい
724 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 13:09:56.76 ID:uHUYRmLo.net]: Dispose不要なんて自分ルールを広めようとしてもそうはいかないから
早めにルールに従ってDisposeをキチット実行するよう修正しましょう
そうしないと後の修正で口から泡を吹く羽目になりますよって話ですw
725 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 13:33:31.83 ID:yb6n8Wdy.net]: 死ね単芝
726 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 21:54:59.46 ID:evM6WMfUm]: >>710
要所要所をアンセーフにするとかngen使うとかすれば、かなり高速化出来る場合もある。
GCの問題があるから、本当に高速なリアルタイム処理は苦手だけど。
727 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 18:38:02.96 ID:cRNFEmJ6.net]: 頭の中がVB6で止まっているのでしょう
728 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 18:40:19.98 ID:cRNFEmJ6.net]: VB6に対して失礼でした
729 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 21:16:04.98 ID:11iB37Vu.net]: >>698
FromHandleとか逆にハンドルを取得する系はIntPtrしか受け付けてくれないから、不要になった時にうまく解放しないといけないのが割と面倒
理解不足も含めて、メモリリークさせてるサンプルはよく見かける

あとは、メインフォームとか静的なイベントに参照にぎられてるとかもちゃんと意識しないと危険
730 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:00:39.66 ID:FzRJlm7d.net]: >>706,717
個人的にはDisposeを使う方がお行儀がいいのは認める。
ただ、C#の思想としては、「タイミングは規定できないが、解放はシステム側で保証するから、
面倒なことを考えずに具だけに集中しろ」ということなのだと思う。
だから、クラスをきっちり書けば出来そうな気もするし、それに向けて整備していっているはず。

とはいえ、俺はGUI（描画）に使っている程度で、そんなに本格的に使っていない。
だから命中していないだけで、言われているケースがありそうだというのはなんとなく感じる。
731 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:03:49.42 ID:bwlYR2I5.net]: >解放はシステム側で保証するから

メモリに関してだけはそのとおりですね
732 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:07:38.08 ID:FzRJlm7d.net]: >>707
アンセーフはこれ。見にくくなるが速くなる。
www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_021/csharp_abc05.html

アンマネージドはVC++の機能で、SSEとかを使いたいときに使う。
733 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:13:15.62 ID:Y9IbSqw2.net]: >>720
バカはリソース解放の必要性が理解できないので説明するだけ無駄
734 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:17:53.09 ID:JrnVqkd7.net]: >アンマネージドはVC++の機能で、SSEとかを使いたいときに使う。

はぁ……
何言ってんのこいつ
C++から来てなんでも知ってるつもりのバカヤロウじゃん
735 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:41:07.48 ID:bwlYR2I5.net]: たぶん句読点の位置がおかしい
アンマネージドは、VC++でSEEとか使いたいときに、使う
が正解なのかしら
知らんが
736 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 22:41:34.05 ID:bwlYR2I5.net]: SEE　→　SSE
ごめんね
737 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 23:06:00.33 ID:Wpti2W5K.net]: >>721
これはアンマネージコードではなくアンセーフコード
アンセーフコードもマネージコードには違いない
ちなみにこのリンク先の例はunsafeだから速いのではなく、GetPixel/SetPixelのAPIがクソ遅いだけ
.NET2.0以降ならLockBitsがあるから一旦配列に丸ごとコピーして処理後に書き戻せばunsafeなんか使わなくても十分に速い
738 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 23:08:27.34 ID:rPHzO56e.net]: C++君って先月くらいからいるけど、いつ死ぬの？
739 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 23:29:15.56 ID:uHUYRmLo.net]: >>727 が死ねばいいんだよ、お前が一番屑だから
というかC++の上がり人はどう考えても一人じゃないだろ
見た感じ多くはゲーム系の人かな
740 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 23:35:33.69 ID:uHUYRmLo.net]: GetPixel/SetPixelが遅いというよりも、プロセス間通信が仕組み的に粒度が小さい処理に向いてないという感じかな
741 名前：デフォルトの名無しさん mailto:sage [2015/08/25(火) 23:42:25.80 ID:87HoKT0r.net]: >>721
これはひでえな
LockBits使えば十分だろ

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

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