2ちゃんねる スマホ用 ■掲示板に戻る■ 全部 1- 最新50    

■ このスレッドは過去ログ倉庫に格納されています

C#, C♯, C#相談室 Part93

1 :デフォルトの名無しさん(ワッチョイ 1e06-m8Mb):2017/04/22(土) 08:52:00.93 ID:iVvswOrb0.net
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

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

■前スレ
C#, C♯, C#相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2 :デフォルトの名無しさん (ワッチョイ de35-HDOw):2017/04/22(土) 10:57:42.55 ID:g8ZT1khs0.net
■過去スレ
C#, C♯, C#相談室 Part89
http://peace.2ch.net/test/read.cgi/tech/1443271409/
C#, C♯, C#相談室 Part90
http://echo.2ch.net/test/read.cgi/tech/1455160063/
C#, C♯, C#相談室 Part91
http://echo.2ch.net/test/read.cgi/tech/1467142749/
C#, C♯, C#相談室 Part91 (実質Part92)
http://echo.2ch.net/test/read.cgi/tech/1467211515/
C#, C♯, C#相談室 Part92 (実質Part93)
http://echo.2ch.net/test/read.cgi/tech/1485589613/

>>1
ここは、実質Part94

3 :デフォルトの名無しさん (ワッチョイ 1e06-m8Mb):2017/04/22(土) 13:39:44.03 ID:iVvswOrb0.net
■関連スレ
初心者の質問向けはこちら
ふらっと C#,C♯,C#(初心者用) Part127
http://echo.2ch.net/test/read.cgi/tech/1489498042/

>>2
補足thx。見逃していた

4 :デフォルトの名無しさん (ワッチョイ 7ff7-/JtG):2017/04/22(土) 14:55:56.60 ID:c4VI05+R0.net
おつかれ
キチガイの人(山口人生)は、複数回線もっていそうだからどこまで効果するかは分からんけれど
何もしないよりマシだね、今後もワッチョイ有りで行こう。
死ねばいいのに・・・・

5 :デフォルトの名無しさん (アウアウイー Sa63-wX6N):2017/04/22(土) 15:23:39.94 ID:FEVU7Q4Da.net
誰だよ山口人生ってww

6 :デフォルトの名無しさん (エムゾネ FFaa-TkTn):2017/04/22(土) 15:39:01.94 ID:S+KK7a41F.net
正しいスレ番と設定で立てました

C#, C♯, C#相談室 Part94
http://echo.2ch.net/test/read.cgi/tech/1492843013/

7 :デフォルトの名無しさん (ワッチョイ 7ff7-/JtG):2017/04/22(土) 16:06:32.09 ID:c4VI05+R0.net
>>5
ググッてみてば分かるw
東大出でイリノイ大学で不完全性定理で有名なゲーデルの弟子として著名な
竹内外史先生の弟子になってPh.Dを取るも、神奈川大学で万年講師、研究室の壁を蹴って騒音出していたらクビになってしまったヤツwww
経歴だけ見るとスーパーエリートwwww
学歴荒らしがあるところに山口人生あり、酷い学歴厨の60台後半じぃさん
実家はお金持ち、もう親は鬼籍かな?ビル持っていて資産が一億切っているとか、絶対ヤバそうw
P=NPを主張しているが誰にも相手にされず、学会では芸人扱いw

8 :デフォルトの名無しさん (アウアウイー Sa63-wX6N):2017/04/22(土) 17:40:53.42 ID:L9cy9Aq3a.net
統失くんいらっしゃい、ってかw

9 :デフォルトの名無しさん (ワッチョイ 7ff7-/JtG):2017/04/22(土) 17:57:12.00 ID:c4VI05+R0.net
敬意が足らないですね、糖質超教授と読んであげましょうwww
いらっしゃらなくていいです、迷惑なので死んでください

10 :デフォルトの名無しさん (ワッチョイ bb4c-VP69):2017/04/22(土) 19:18:48.92 ID:7MQLYtSw0.net
本当のその山口ってのなのか?

11 :デフォルトの名無しさん (ワッチョイ 7ff7-/JtG):2017/04/22(土) 19:41:05.45 ID:c4VI05+R0.net
張り付き方が異常、現役じゃ不可能
発言が山口人生と似ているし話が高齢者臭い、中年ですらない
Delphiを使っていて最近C#に移ってきている
ここまでのマジキチには普通日常で出会うことは無い、希少種

そんなヤツがこの日本に何人もいてたまるかwwww

12 :デフォルトの名無しさん (ワッチョイ bb4c-VP69):2017/04/22(土) 20:05:29.05 ID:7MQLYtSw0.net
このスレ、自分以外は全部同じ人が書き込んでたりしてw

ちょっとしたホラーだな

13 :デフォルトの名無しさん (ドコグロ MM33-MUXz):2017/04/22(土) 20:49:00.38 ID:IUEn1/EeM.net
なんかワッチョイ付いてると気に入らないみたいよ
俺は付いてるほうが好きだからこっちのスレのがいいな

14 :デフォルトの名無しさん :2017/05/03(水) 17:15:57.72 ID:crwmH6BQM.net
こっち使おうぜ

15 :デフォルトの名無しさん :2017/05/05(金) 16:32:19.84 ID:bVbNjYk40.net
今日発見した衝撃の事実
なぜWindowsUpdateの時ファイルがぶっ壊れるのかというのがずっと謎だった
Application.ThreadExit イベントで書き出しスレッドの終了処理していたのだが
手動のシャットダウンだと問題なく呼ばれるのに、リブートするとThreadExitが呼ばれない
それどころか、フォアグラウンドで作成していたスレッドが強制終了させられている上
System.Threading.ThreadAbortExceptionmもSystem.Threading.ThreadInterruptedExceptionも送出されないまま
突然中断で終了しやがってた・・・
ひでぇ終了の仕方だ・・・
なんでリブートに限りこんなシーケンスで強制終了しやがるんだ、この糞が・・・

16 :デフォルトの名無しさん :2017/05/05(金) 16:49:33.38 ID:tHPUBlll0.net
セキュリティ的にアプデは大事だからね
多少強引な手段で終了してもいいよね仕方ないね

17 :デフォルトの名無しさん :2017/05/05(金) 17:01:44.90 ID:3XrDrf840.net
シャットダウンと再起動で違うのか

18 :デフォルトの名無しさん :2017/05/05(金) 17:10:34.10 ID:pBlqXMv00.net
もっと詳しく知りたい。

SessionEndingイベントとかで捕まれないんか?
それ

19 :デフォルトの名無しさん :2017/05/05(金) 17:16:16.69 ID:bVbNjYk40.net
>>16
セキュリティは最終的には自分のファイルが壊れないことを目的にやるわけだが
そのセキュリティ対策が破壊してくれるのであれば、本末転倒なのでそんな対策は不必要って思うわけだよ。

20 :デフォルトの名無しさん :2017/05/05(金) 17:17:13.60 ID:bVbNjYk40.net
>>18
SessionEndingイベントが来たときはもう殺された後だねw
ここでは対策出来ない。

21 :デフォルトの名無しさん :2017/05/05(金) 18:09:02.57 ID:pBlqXMv00.net
>>20
おおう、そうなんか。

22 :デフォルトの名無しさん :2017/05/05(金) 18:13:33.93 ID:A3oUashQa.net
>>15
Windows Updateだろうが何だろうがリブート開始時に
ユーザーに確認なくプロセスの強制終了なんてそもそもされないと思うよw

何か勘違いしてない?

23 :デフォルトの名無しさん :2017/05/05(金) 18:24:50.53 ID:A3oUashQa.net
ちょっと調べた感じ
http://news.mynavi.jp/column/windows/270/
にあるような感じでレジストリいじっちゃったんだろうねw

24 :デフォルトの名無しさん :2017/05/05(金) 18:43:02.46 ID:PzvORh1V0.net
>>22
EWX_FORCEとかEWX_FORCEIFHUNGを指定してるんでしょ
https://msdn.microsoft.com/ja-jp/library/cc429713.aspx
セキュリティアップデートは確実にリブートする必要あるから多少の犠牲はやむを得ない
って思ってるんじゃね?

25 :デフォルトの名無しさん :2017/05/05(金) 19:11:23.54 ID:FiATWWo80.net
客側でこれを指定されたらたまらないなー

26 :デフォルトの名無しさん :2017/05/05(金) 19:58:14.99 ID:ueXs9gXt0.net
ExitWindowExの英文説明では、DWORD dwReservedのとこがdwReasonになってんね。

このへんかな

27 ::2017/05/05(金) 20:10:07.89 ID:05XvGSted.net
プロセスの終了確認はあるだろうか、その結果タイムアウトした時のスレッドの落とし方はものすごい強引だった気がする。
昔shutdown -s -t 01で落として確認した事ある。

28 :デフォルトの名無しさん :2017/05/05(金) 20:14:25.56 ID:3cKL/0El0.net
OSの仕様なのか.NET独特の挙動なのか>>23みたいな話なのかはっきりしないな
.NET独特の挙動だったら業務でアプリ作っている人は死活問題じゃね

29 :デフォルトの名無しさん :2017/05/05(金) 20:27:56.88 ID:PzvORh1V0.net
>>26
日本語版のドキュメントが更新されてないだけみたい
WindowsXPからdwReasonになってる

30 :デフォルトの名無しさん :2017/05/05(金) 20:30:18.07 ID:A3oUashQa.net
いやいやデフォではプロセス強制終了なんてないよ絶対w

Winduws Updateはデフォでは自動になってるんだから、Windows Updateが走るたびに
そんな無茶苦茶やってたら世界中で大騒ぎになってるってw

XPの時代はそんな経験したような記憶もあるけど
少なくともVista以降はないと思うよ

31 :デフォルトの名無しさん :2017/05/05(金) 20:34:57.11 ID:3cKL/0El0.net
俺は趣味でやっているだけだしアップデートも任意のタイミングでしかやらないからどうでもいいが
VSの有料ライセンス買っている人がいて心配だったら直にMSに聞いた方がいいな

32 ::2017/05/05(金) 20:48:13.06 ID:05XvGSted.net
>>28
業務アプリが走るような環境は、社内でKB単位で配布して、ログイン前に当たるようにしてると思う。
>>30
本人はプロセスじゃなくてスレッドを問題視してるのでは?

33 :デフォルトの名無しさん :2017/05/05(金) 22:27:29.53 ID:ueXs9gXt0.net
>>30
言いたい事はわかるw

まーもちつけ

34 :デフォルトの名無しさん :2017/05/06(土) 07:24:56.49 ID:KTPtsEWO0.net
>>30
10以前はWindowsUpdateをするタイミングをこちらの問題の無いタイミングで出来たから
そもそも問題自体が存在しなかったという事実。

35 :デフォルトの名無しさん :2017/05/06(土) 07:54:55.96 ID:rojhZA3i0.net
適度にトラブル起こしてあげないと窓際族の情シスの仕事がなくなっちゃうからね

36 :デフォルトの名無しさん :2017/05/06(土) 08:25:02.90 ID:2V5tVO5D0.net
>>27
これは良いこと聞いた。
うちも似たような仕組み作ってるグループあるから、ExitWindowsExも利用して調査してみるよう伝えてみるわ

37 ::2017/05/06(土) 08:57:56.21 ID:BE072L/9d.net
>>36
UIスレッドでメッセージボックス出しとくと、プロセスを落とす正規ルートからはずれて再現できるとか、なんか色々こねくり回したよ。
今だと仮想マシンあるから、マシンが上がってくるの待つ辛さ無いかもね。

38 :デフォルトの名無しさん :2017/05/25(木) 06:03:37.70 ID:OZ9w4Yf70.net
ロック処理についてちょっと相談です

●二つ以上のオブジェクトを同時にロックしたい
片側づつ順を追ってロックしていくのはダメ、デッドロックするので。
ロック出来ない状態である限り、ロックは限りなくしないようにしたい。
ロックに失敗までのタイムアウト処理もしたい。

●例えばこれだと、デッドロックを引き起こすので良くない
lock(obj1) lock(obj2) 処理;

●そこで、言語に以下のような構文があれば理想的なのだが
ないので、それらしいヘルパを作りたい、できれば効率的な物。
lock(obj1,obj2, ... ,timeout=1000) {
 ロック成功の場合の処理
}
timeout {
 タイムアウトした場合の処理
}

39 :デフォルトの名無しさん :2017/05/25(木) 06:03:54.24 ID:OZ9w4Yf70.net
●とりあえず簡単に考えた、しかし無駄が多そうに見える、もっと良いものが欲しい。
DateTime begin = DateTime.Now;
再試行:
bool l1 = Monitor.TryEnter(obj1, 0);
bool l2 = Monitor.TryEnter(obj2, 0);
if (l1 && l2) {
 goto ロック成功;
} else {
 if(l1) Monitor.Exit(obj1); // チェックと共にロックしてしまうので、このコードも残念賞
 if(l2) Monitor.Exit(obj2); // 同上
 if ((DateTime.Now - begin).TotalMilliseconds > 1000) {
  goto タイムアウト;
 } else {
  System.Threading.Thread.Sleep(10); // この待ち方も酷い
  goto 再試行;
 }
}
タイムアウト:
{
 タイムアウト処理
}
ロック成功:

40 :デフォルトの名無しさん :2017/05/25(木) 07:25:50.25 ID:zdaQwC0X0.net
ていうか普通にロック専用のオブジェクト作ってそれをロックすりゃいいんじゃねーの

41 :デフォルトの名無しさん :2017/05/25(木) 07:32:55.17 ID:OZ9w4Yf70.net
>>40
それだとロック粒度が大きくなりすぎて逆にデッドロックの可能性を拡大してしまいますね。

42 :デフォルトの名無しさん :2017/05/25(木) 07:34:38.83 ID:ZdIAUNK00.net
セマフォ使ったらどう?
資源数もタイムアウトもあるし

43 :デフォルトの名無しさん :2017/05/25(木) 07:36:13.98 ID:OZ9w4Yf70.net
>>42
セマフォは重いんですよねぇ
それをやるくらいなら>>39の例の方が効率的ですね。

44 :デフォルトの名無しさん :2017/05/25(木) 07:50:05.84 ID:OZ9w4Yf70.net
>http://article.higlabo.com/ja/thread_locking.html
lock(Monitor.Enter/Monitor.Exit) 同じプロセス 20ns
Mutex 違うプロセスも可能 1000ns
SemaphoreSlim 同じプロセス 200ns
Semaphore 違うプロセスも可能 1000ns
ReaderWriterLockSlim 同じプロセス 40ns
ReaderWriterLock 同じプロセス 100ns

Semaphoreは高機能すぎて、あまり軽々しくは使えない。
そのわりにはlockと違ってスレッドチェックがないので自家中毒を起こしたりするので、別途そのための対処が必要になったりする。
lock 20nsはやはり捨てがたいものです。

45 :デフォルトの名無しさん :2017/05/25(木) 08:14:43.50 ID:CNpknsWj0.net
見も蓋もないが、設計が間違ってる気がする。

46 :デフォルトの名無しさん :2017/05/25(木) 08:20:40.14 ID:OZ9w4Yf70.net
>>45
そんな事は無いと思うんだけどな、セマフォに標準で実装されているように
これはマルチスレッドデザインパターンとしては基本になるかと。
というか教科書にある典型ですし。
ところが、Monitorにはなかったので、おや何故ない?となっている所。
せっかく高性能なのに有効活用できないのは勿体ないと。

47 :デフォルトの名無しさん :2017/05/25(木) 08:30:18.43 ID:a8axhl9cd.net
>>46
そもそもなぜロックが必要なの?

48 :デフォルトの名無しさん :2017/05/25(木) 08:34:06.74 ID:OZ9w4Yf70.net
>>47
分からないならレスしないでもらえますか?
流されては叶いません。

49 :デフォルトの名無しさん :2017/05/25(木) 08:52:37.16 ID:CNpknsWj0.net
>>39
みたいなことをするぐらいならSpinLockを使った自前実装で処理したほうが良いかもしれない。

もしくは
>>lock(obj1) lock(obj2) 処理;
これでもデッドロックしないように、Lockする順番を厳格にしてコーディングするとか

というか、言葉遣いに気を付けたほうが良いと思うよ。

50 :デフォルトの名無しさん :2017/05/25(木) 08:54:51.29 ID:foQMlEN20.net
そんなにパフォーマンスが大事ならオプティミスティックロックも検討したら?
どうせ滅多に競合なんかしないでしょ

51 :デフォルトの名無しさん :2017/05/25(木) 09:01:40.08 ID:a8axhl9cd.net
>>48
そもそもロックが必要という判断に至った理由が明らかでない
ロックがベストな選択肢である保証はどこにもない

52 :デフォルトの名無しさん :2017/05/25(木) 09:04:40.54 ID:OZ9w4Yf70.net
>>49
ここにいる知らなくてもレスしないと死ぬ病気にかかっている奴はどうしょうもない。初心者の上にキチガイなら死ねって感じですが。
とりあえず、スピンロックは使いたくないですね、あれはCPUタイムをすり潰しながら高速動作を確保しようとするものだから
それの主用途は、激重計算タスクを並列処理するための物であって、目的とちょっと違いますね。
あと、排他処理をちゃんと勉強すると、順序等を考えていても意味が無くて
ロックする瞬間に作業に必要になるリソースをすべて確保して、必ず抜けられるという事の方がデッドロックに対する対処としては有用です。
でも、上に書かれているように一つのオブジェクトで粒度を上げてしまったら本末転倒になります。

53 :デフォルトの名無しさん :2017/05/25(木) 09:05:42.97 ID:OZ9w4Yf70.net
>>51
ちゃんとわかっている人を待っているんだから黙ってろ

54 :デフォルトの名無しさん :2017/05/25(木) 09:12:36.71 ID:foQMlEN20.net
アイデアを募るならもっと広い視野で考えたほうがいいってことでしょ
矮小な問題に限定されすぎていて、マイクロベンチマークレベルの不毛な議論にしかならない
状況によっては工夫すればロックフリーな実装もできるかもしれないよ

55 :デフォルトの名無しさん :2017/05/25(木) 09:21:45.74 ID:CcaoVCJwa.net
うわあ。これは無視すべき奴だw

56 :デフォルトの名無しさん :2017/05/25(木) 09:24:19.81 ID:CNpknsWj0.net
>>52
https://www.jpcert.or.jp/java-rules/lck07-j.html
ソースはそれっぽいものを適当に引っ張ってきた
ロックする順序は意味あると思うんだけど、、、

デッドロックが怖いってことだと思うんだけどさ
親から子へ順番守ってロックすればデッドロックしないじゃん?

57 :デフォルトの名無しさん :2017/05/25(木) 09:24:47.08 ID:OZ9w4Yf70.net
>>55
世の中上には上の奴がいるんだよ、俺なんかよりはるかに知識を持っている奴はいくらでも。
お前より俺の方が知識あるが、そんな俺よりもはるかに凄いやつは山のようにいるんだ。
そろそろ、中二病みたいな全能感は捨てな

58 :デフォルトの名無しさん :2017/05/25(木) 09:32:43.15 ID:OZ9w4Yf70.net
>>56
親子関係があれば、親についている操作ようのメソッドにロック処理をいれれば問題ないですね。
でも、今回のは完全に独立しているオブジェクト間です。
ちょっと難しいですね。
実際問題としては、順序を使う側にすべて守らせるというのは、理屈では語れても実践的ではないかもしれません。
やはり、ロック時間を短くする事が肝要であり、その為には粒度を小さくするのが基本となるかと。
汎用的なやり方としては、この方法がもっとも優れていると思います。
なので、この方法をより高パフォーマンスで実現できるヘルパーを実装して纏めて利用したい訳です。
だから、別の方法は考えていないです。Monitorを使った高速排他処理が今回の最終目標です。

59 :デフォルトの名無しさん :2017/05/25(木) 11:13:36.68 ID:5itOJ4P90.net
楽観的ロックのタイムアウトで、ロールバックするのが確実

人間には絶対にミス・バグがあるから、
デッドロックを100%、起こさないようにする事は、絶対に出来ないから

60 :デフォルトの名無しさん :2017/05/25(木) 11:20:25.49 ID:ts6Ek6dYM.net
これ触っちゃいけないやつじゃん・・・

61 :デフォルトの名無しさん :2017/05/25(木) 11:39:35.31 ID:OZ9w4Yf70.net
>>59-60
だから、もう来るなって、お前には何も聞きたいことは無いし、そんな話は聞かされたところで新たな何かには全くつながらない。
C#スレには、初心者用じゃないもう一本の匿名ゴミすれあるだろ、そっちいけよ。
分かっている人が来たときにコメントがゴミだらけになる。

62 :デフォルトの名無しさん :2017/05/25(木) 12:20:12.43 ID:XlAyjrlQa.net
たぶん質問者の方が俺よりずっと詳しそうだから釈迦に説法だと思うけど、

>●例えばこれだと、デッドロックを引き起こすので良くない
>lock(obj1) lock(obj2) 処理;

これがデッドロックしうるのはこのスレッドがobj1だけをロックした状態で
別のスレッドがobj2をロックして、そのスレッドがobj1を待機してる場合だよね?

この場合このスレッドがobj1をアンロックしない限りobj2もアンロックされないからデッドロック

だから、ネストの内側のock(obj2) だけをタイムアウト付きのMonitor.TryEnterに置き換えれば
効率的かどうかはどうかはともかく、要件は満たせるんじゃいないの?
知らんけど

63 :デフォルトの名無しさん :2017/05/25(木) 12:28:42.96 ID:OZ9w4Yf70.net
>>62
まさにその通りです、それが直下に書いた雑な例です。
このヘルパーを作りたいという訳です、見るからに美しくないので詳しい人の登場をお待ちしているという所です。
必要な全ロック取得に失敗したら即座に全て解放して、乱数時間まって次を伺う。
これはよくある教科書通りです。

64 :デフォルトの名無しさん :2017/05/25(木) 13:09:08.98 ID:a8axhl9cd.net
>>62
キチガイに触るなよ

65 :デフォルトの名無しさん :2017/05/25(木) 13:35:53.97 ID:Gj1BXJi/M.net
基地外大暴れワロタ

66 :デフォルトの名無しさん :2017/05/25(木) 13:51:23.71 ID:CNpknsWj0.net
http://ideone.com/GHvgKN
勢いで書いた。

67 :デフォルトの名無しさん :2017/05/25(木) 13:59:41.85 ID:OZ9w4Yf70.net
>>66
いいっすね、いいっすね
Thread.Sleep(100); ← ここがもうちょっとマシな待ち方になるといいんですがw
自分はインターフェイスは、IDispose使ってロック範囲を lock で書いたような雰囲気にしてます。
タイマーは、初ロック失敗の後にスタートさせて、ロック成功(大半のケース)でロスが少ないようにしてます。
なかなか素敵な感じになってくれませんw

68 :デフォルトの名無しさん (ワッチョイ 1f1b-6//c):2017/07/11(火) 08:22:12.16 ID:MCsEtOKi0.net
↓のテンプレートとジェネリックの違い、にある
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics
トップ項目にある
・C# ジェネリック クラスでは、ユーザー定義演算子は呼び出すことができますが、算術演算子を呼び出すことはできません。
"算術演算子を呼び出すことはできません"ってどーいう意味っすか?
算術演算子って+-*/のこと?

69 :デフォルトの名無しさん (アウアウイー Sacb-G8QH):2017/07/11(火) 09:57:14.72 ID:t4lUkhAUa.net
遠まわしに制約について言ってるのかな。

算術演算子が使える型のみ受け入れるような制約はできないから
自動的に算術演算子は使えないことになるわけだけど...

70 :デフォルトの名無しさん (ワッチョイ 5eea-bL4e):2017/07/16(日) 01:54:50.85 ID:mMdQfX5s0.net
楽しそうだな。w

71 :デフォルトの名無しさん (ワッチョイ 6a90-qWRz):2017/07/29(土) 20:36:18.47 ID:Gw88XuqA0.net
ジェネリックに算術演算子を使うなら、そんなに速度が要求されないんなら
(dynamic)にキャストしてからなら演算子が使える
まあこれキャッシュ付きのリフレクションだから速度は期待しないでよー

72 :デフォルトの名無しさん :2017/08/21(月) 18:56:43.94 ID:LgNyTwHt0.net
C++ではテンプレートに焦点をあてた書籍はいくつかあるけど
C#でジェネリックに絞ったオススメ書物ってのはありますか?
C++のテンプレートテクニックのどれが使えないか?ってのは知りたい。

73 :デフォルトの名無しさん :2017/08/21(月) 19:55:10.65 ID:KmAQXiSua.net
C#のジェネリックって1時間で読める記事で網羅されるぐらいの内容しかないっすよ

74 :デフォルトの名無しさん :2017/08/21(月) 20:02:09.15 ID:vP5jpteT0.net
テンプレートテクニックとか全部忘れてOK

75 :デフォルトの名無しさん :2017/08/21(月) 21:10:14.69 ID:qdRqCzb30.net
プレートテクトニクス

76 :デフォルトの名無しさん :2017/08/27(日) 02:29:03.34 ID:/hywh0UG0.net
式テンプレートジェネリックでどー書くんだよ

77 :デフォルトの名無しさん :2017/10/09(月) 21:40:27.74 ID:dzl0TrLma.net
すみません。ちょっと急いでいます。

C#でクラスを宣言する際に、
class {...} とpublic class {...}
このふたつの違いが判りません。
教えてください。

78 :デフォルトの名無しさん :2017/10/09(月) 21:54:29.58 ID:rAF1hT8M0.net
お願いします。同じものですか?

79 :デフォルトの名無しさん :2017/10/09(月) 21:56:31.06 ID:28tAbNEV0.net
アクセス修飾子を省略したクラスは internal になる
public とか internal とかの意味については↓

アクセス修飾子 (C# プログラミング ガイド) | Microsoft Docs
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/classes-and-structs/access-modifiers

80 :デフォルトの名無しさん :2017/10/09(月) 21:56:50.83 ID:u67WqECL0.net
>>77
外部から見えるか見えないか

81 :デフォルトの名無しさん :2017/10/09(月) 22:03:58.01 ID:rAF1hT8M0.net
ありがとうごぜます。
internalですね。アセンブリ言語レベルの話のようなので
まだそこまで至ってないのでpublic, private, protectedだけ使います。
すみませんでした。

82 :デフォルトの名無しさん :2017/10/09(月) 22:12:08.58 ID:Y4203ffV0.net
「アセンブリ」ってみて「アセンブリ言語」って理解するのは先が思いやられるな。全然意味が違う話なのに

83 :デフォルトの名無しさん :2017/10/09(月) 22:16:05.20 ID:28tAbNEV0.net
>>81
上記のページで「アセンブリ」と言ってるのはアセンブリ言語のことではなくて
「exe」とか「dll」とかのファイル単位での機械語のまとまりのことだよ

84 :デフォルトの名無しさん :2017/10/09(月) 22:41:05.37 ID:rAF1hT8M0.net
ありがとう。
今自分でも調べていてなんか違うなーって思ってました。

85 :デフォルトの名無しさん :2017/10/09(月) 23:04:42.97 ID:/pZGRYTm0.net
bin

バイナリ・ファイル

86 :デフォルトの名無しさん :2017/10/10(火) 00:40:47.02 ID:pliWVB3X0.net
今となっては、いや初めから忘れてもいい話だったけど
ファイル単位の物理的なまとまりはモジュール(.netmodule)で
モジュールをまとめた論理的まとまりがアセンブリ(.dll/.exe)
Visual Studioが2002の初めから一貫してサポートしてないこのモジュールって単位をMSはどう使うつもりだったんだろう

87 :デフォルトの名無しさん :2017/10/10(火) 21:13:43.71 ID:9Raz+qz10.net
最終的に1つのライブラリにしたいものをC#とF#で部分ごとに書き分けるとかそういう例は見た事あるけど
(ものによってはF#のほうが書きやすいとか)
実際それが必要なユーザがどれだけいるのかって話な

88 :デフォルトの名無しさん :2017/10/10(火) 23:25:11.21 ID:I+aeGBiR0.net
C++/CLIとC#の組み合わせがある。

最終的な呼び出し元はネイティブと同じ口なんだけど、
dynamicやasync/awaitなどを使いたいため、
dllexport付近の薄皮一枚だけ C++/CLI、
残りは全部C#で記述して1つの.dllにってのに.netmoduleを使う。

C#とF#の組み合わせとか、ほとんど無意味に思えるが…

89 :デフォルトの名無しさん :2017/10/11(水) 03:26:54.68 ID:rqqSAVqsM.net
iron python も?

90 :デフォルトの名無しさん :2017/10/18(水) 13:52:47.94 ID:ufsScDVj0.net
event解除ってnullぶっこんでもいいのかしら?
何処見ても-=でしろってのばかりで全解除の適切なやり方載ってないんだけど
一応null代入で動いてるぽいけどちと不安

91 :デフォルトの名無しさん :2017/10/18(水) 14:05:31.13 ID:4p9Ry6Jxa.net
まいなすはそれだけ消す、nullはすべて消す
できわるいコードだとnull入れると落ちるw

92 :デフォルトの名無しさん :2017/10/18(水) 14:18:32.71 ID:ufsScDVj0.net
全解除ってそれなりに需要あると思うんだが何処も扱ってない不思議
+=って内から外へ処理出しする訳だから
インスタンスが破棄されたら当然破棄されるべきなのにどうもそうなってない
nullぶっこめばGC回収されるみたいだけど正しいやり方なのかな

93 :デフォルトの名無しさん :2017/10/18(水) 15:17:21.27 ID:8oWZ+6kpM.net
設計次第じゃないの

94 :デフォルトの名無しさん :2017/10/18(水) 15:34:04.84 ID:jnsT8t6ma.net
購読側じゃなく発行側が勝手に解除ってのがちょっと...
むしろどういう場面で必要になるのか想像できないな

> +=って内から外へ処理出しする訳だから
> インスタンスが破棄されたら当然破棄されるべきなのにどうもそうなってない
ここは何を言ってるのかよく分からない

まあ、イベントというかデリゲートのマルキチャストの仕組みが分かりづらいのはわかる

95 :デフォルトの名無しさん :2017/10/18(水) 15:50:00.66 ID:h6dEijxza.net
>>92
正しいというかとりあえず安全なのは何もしないの放り込んどく
それでも勝手に消されて困るのがあるかもしれんがw

96 :デフォルトの名無しさん :2017/10/18(水) 16:11:03.50 ID:ufsScDVj0.net
>>94
例えば非同期通信でデシリアライズ終わったらイベント投げて後は勝手に死ね、って場合
-=だと発行側で解除するのが困難でリークしちまう
最新VerC#ならTaskで後処理書けばいいけど、Unityだとつい最近まで3.5だったから

97 :デフォルトの名無しさん :2017/10/18(水) 16:24:45.96 ID:jnsT8t6ma.net
>>96
俺の理解不足だったらごめん

リークするのはイベントの購読側のオブジェクトLがイベントの購読を解除しないまま
Lを参照する変数がなくなった場合で、発行側のオブジェクトPのイベントに
Lのメソッドが登録されたままPへの参照がなくなってもそれはリークにならないと思うんですが

98 :デフォルトの名無しさん :2017/10/18(水) 16:39:10.41 ID:ufsScDVj0.net
>>97
そう思ってた時期が俺にもありました
しかし実際はリークしてOutofMemoryが出る
どうも購読側参照が残ってると到達可能と見られてGC回収されないぽい
本当にそういう理屈かは知らんけどnullぶち込むと例外でなくなる

99 :デフォルトの名無しさん :2017/10/18(水) 17:26:02.20 ID:jNhOnQNR0.net
思い込みって怖いネー

100 :デフォルトの名無しさん :2017/10/18(水) 17:46:05.16 ID:GswCLlj60.net
>>98
>どうも購読側参照が残ってると到達可能と見られてGC回収されないぽい

登録解除してないから購読側は発行側から参照されてて回収されない
その状態で購読側が発行側を参照してるんなら発行側も回収されないよね

総レス数 1003
269 KB
新着レスの表示

掲示板に戻る 全部 前100 次100 最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★