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

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

C#, C♯, C#相談室 Part92 [無断転載禁止]©2ch.net

1 :デフォルトの名無しさん:2017/01/28(土) 16:46:53.58 ID:op86qfG/
■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

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

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

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

2 :デフォルトの名無しさん:2017/01/28(土) 16:47:59.00 ID:op86qfG/
■過去スレ
C#, C♯, C#相談室 Part88 [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1437808445/
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/

3 :デフォルトの名無しさん:2017/01/28(土) 20:11:01.67 ID:op86qfG/
すいません、前スレは実質Part92でこのスレ番はPart93でした…

>>2に追加
C#, C♯, C#相談室 Part91
http://echo.2ch.net/test/read.cgi/tech/1467142749/

4 :デフォルトの名無しさん:2017/01/29(日) 09:06:59.65 ID:yBayvk76
おつ

5 :デフォルトの名無しさん:2017/01/30(月) 06:23:24.90 ID:pve8veDd
ストアドでダラダラと数千行も書くクズは仕事やめてくれ

6 :デフォルトの名無しさん:2017/01/30(月) 07:26:13.95 ID:tWAIhpxB
>>5
C#でCOBOLみたいなコード垂れ流されるよりはマシじゃね?

7 :デフォルトの名無しさん:2017/01/30(月) 13:37:08.05 ID:aat2bJqh
SQLおじさんか
でもまぁDB内に閉じた処理なら長い処理でも
ストアドでいいと思うけどな

8 :デフォルトの名無しさん:2017/01/30(月) 17:43:50.02 ID:N6dz8FOe
ストアドの方がマシだろう

9 :デフォルトの名無しさん:2017/01/30(月) 23:35:25.12 ID:pve8veDd
SQLはどこベンダもデバッガがカスじゃん

10 :デフォルトの名無しさん:2017/01/31(火) 10:33:19.74 ID:OaREUEOV
デバッガがないからと言ってシェルスクリプトを書かないひとはいない

11 :デフォルトの名無しさん:2017/01/31(火) 14:32:45.02 ID:tcQh4bsA
書かなくて済むなら書こうとはしない

12 :デフォルトの名無しさん:2017/02/01(水) 00:11:53.74 ID:rMgcMaj2
webアプリの開発をASP.NET MVCで始めてみようと思うのですが、一般用Windows機で社内用(20名以上)の公開になるとライセンス違反になるのでしょうか
また、linuxで.NET Coreの開発にすればライセンスは何も気にしなくていいものなのでしょうか
いまいち良くわかっていないので変な質問でしたらすみません

13 :デフォルトの名無しさん:2017/02/01(水) 00:55:27.94 ID:SIRn8MTv
何の話だよ。もっときちんと謝れ

14 :デフォルトの名無しさん:2017/02/01(水) 00:59:00.68 ID:GoSmMZCV
>>12
スレチ

15 :デフォルトの名無しさん:2017/02/01(水) 01:44:48.27 ID:wmVXAizR
>>12
その規模のASP.NET MVCのサーバーをWindowsのクライアントOSで構築して運用すると明確なライセンス違反になる。
サーバーライセンスとCALをケチるなら、Linuxで.NET Core+ASP.NET Core+WEBサーバー。

16 :デフォルトの名無しさん:2017/02/01(水) 07:23:50.51 ID:/3Lab+Ym
少ない初期投資で手軽に始めてみたいならAWSかAzure使うのも検討したら?
Windows Serverも時間課金で使えるよ

17 :デフォルトの名無しさん:2017/02/01(水) 07:35:30.80 ID:QtOB6vhP
.NET CoreゆうてもVisual Studioは業務利用で有料じゃろ?
VSCodeじゃまだ開発しにくいよインテリセンスイマイチだし

18 :デフォルトの名無しさん:2017/02/01(水) 08:19:50.66 ID:y670B3So
>>17
Editionによるだろ

19 :デフォルトの名無しさん:2017/02/01(水) 08:23:46.42 ID:SIRn8MTv
>>12が言ってるのはVSじゃなくてWindowsのライセンスのこと
Windows ServerでないWindowsをサーバーとして使い、かつ、20台以上から同時接続されるならそれはライセンス違反

20 :デフォルトの名無しさん:2017/02/01(水) 12:00:03.24 ID:+pDV2e5Z
同時じゃなければいいんだ

21 :デフォルトの名無しさん:2017/02/01(水) 14:06:30.13 ID:UvWC25bF
すいません、C#を使用し、NV12色空間のバイナリデータをRGBに変換する方法を教えてください。
私なりに色々なサイトから情報を集めてサンプルのメソッドを作ったのですが、成果物が思ったように出力できません。
どこが悪いかもわからず…困っております。
どなたか、このコードのどこに問題があって正常に表示されないのかご教示いただけないでしょうか。

【コード】
 http://ideone.com/20PQG1
【その他資料】
 http://upup.bz/j/my76880EYEYtgYgvhYE8CIw.png
【背景】
 DirectShowでMP4動画の任意の位置の静止画を取得したい。DirectShowのサンプルフィルタのDumpFilterを使用し、IMediaSampleからダンプファイルを取得し、NV12からRGBに変換したいのだがうまくいかない・・・

お手数をお掛けしますが、何卒よろしくお願いします。

22 :デフォルトの名無しさん:2017/02/01(水) 14:49:28.30 ID:jnCvpXDY
>>21
横方向は色が連続してるから、wが絡んだインデックスの計算で誤りがあんじゃね

23 :21:2017/02/01(水) 14:57:10.29 ID:UvWC25bF
>>22
凡ミスでした・・・・
 var y = nv12Binary[h * width + h + cnt];
 ではなくて、
 var y = nv12Binary[h * width + w + cnt];
 でした・・・・


すいませんお騒がせしました;w;

24 :デフォルトの名無しさん:2017/02/01(水) 18:32:14.02 ID:fkh8yjaM
>>19
だからスレチ

25 :デフォルトの名無しさん:2017/02/01(水) 19:46:14.74 ID:W7n/VPVl
>>12です
スレチの質問すみませんでした
レスして頂いた皆さんありがとうございました
参考意見助かりました

26 :デフォルトの名無しさん:2017/02/01(水) 23:00:42.87 ID:ekCEdBsk
短いSQLの間に別の手続型言語を挟むような作りと長い一発SQLとは、処理速度が数十倍〜数百倍違うこともあるからしょうがない
だって、DBエンジンは自動的にマルチタスク処理してくれるのに、別言語で処理するってことはシングルスレッド化するんだから
それにSQLは長くても、うまければむしろ読みやすく書ける(手続型言語より短いステップでシンプルに書ける場合が多い)
ただし頭の中に複数のマス目をイメージできない人が読むと呪文に見えるらしい
常に低レベルなプログラマに合わせて標準化する利点はあるだろうけど

27 :デフォルトの名無しさん:2017/02/01(水) 23:29:02.19 ID:Q5WgQ/3w
クソ長いSQLは設計ミスったバカなDB固有の現象なんだぜ
100行超えたらなんか致命的にやらかしてるって疑った方がいい

28 :デフォルトの名無しさん:2017/02/01(水) 23:45:22.94 ID:tYeJxlUS
SQLとか長くて6行だろ

29 :デフォルトの名無しさん:2017/02/01(水) 23:47:28.74 ID:r1Eq5mSG
SQLは軽くしとかないと負荷分散し辛いだろ

30 :デフォルトの名無しさん:2017/02/02(木) 00:06:00.36 ID:335RX4F5
100行のSQLって何してんだよw

31 :デフォルトの名無しさん:2017/02/02(木) 00:22:55.82 ID:NP4cqTts
前スレ995に言ってくれ

32 :デフォルトの名無しさん:2017/02/02(木) 00:33:35.95 ID:Xhr9HRot
SQLがクソ長くなるのはだいたい横持ちのせい

33 :デフォルトの名無しさん:2017/02/02(木) 00:38:43.68 ID:jMAutYAP
100行ぐらいのSQLなら常人が読める程度にこなれているだろ
問題は、4つも5つもくっつけて集計したものを更に集計ている呪文のようなViewだな

「誰がこんなもの作ったんだよ」と、過去の自分に説教したくなることが偶にあるだろ

34 :デフォルトの名無しさん:2017/02/02(木) 01:06:08.80 ID:mPNRvOCD
SQLは再帰CTEの登場でチューリング完全な言語になったからな
https://wiki.postgresql.org/wiki/Mandelbrot_set

35 :デフォルトの名無しさん:2017/02/02(木) 04:14:19.22 ID:gxIOcfsw
select *でなく
select a,
b,
d,
....などはよくある行数稼ぎw

36 :デフォルトの名無しさん:2017/02/02(木) 11:36:33.30 ID:K/b9EIy4
行数で語るのはSIer脳

37 :デフォルトの名無しさん:2017/02/02(木) 22:58:09.73 ID:JuktWcDi
>>33
初心者って集計を嫌うよね
集計を覚えるとSQLの表現力がグッと上がるのにもったいない

38 :デフォルトの名無しさん:2017/02/02(木) 22:59:25.89 ID:cdo4XHzT
集計はよく使い方が分からない

39 :デフォルトの名無しさん:2017/02/04(土) 16:36:50.15 ID:sbknHPFF
ファイルサイズを高速に取得したいのですがFileInfoだと遅くて・・・
何か良い方法は無いものでしょうか。

40 :デフォルトの名無しさん:2017/02/04(土) 16:45:50.00 ID:atHQASm/
>>39
なぜ高速に取得したいの?
どういうアプリケーションを想定?
エクスプローラ?

41 :デフォルトの名無しさん:2017/02/04(土) 16:49:01.93 ID:sbknHPFF
>>40
はい。そのようなものです。

42 :デフォルトの名無しさん:2017/02/04(土) 16:52:42.09 ID:94H9RTyk
dir実行してパイプで取り込むとかw

43 :デフォルトの名無しさん:2017/02/04(土) 16:53:28.40 ID:ypmLJyxS
インデックス

44 :デフォルトの名無しさん:2017/02/04(土) 17:03:20.16 ID:atHQASm/
DirectoryInfoのEnumeateFilesとかでも遅いかな

45 :デフォルトの名無しさん:2017/02/04(土) 17:33:34.62 ID:sbknHPFF
>>44
DirectoryInfoで速くなりました。ありがとうございます!

46 :デフォルトの名無しさん:2017/02/04(土) 21:24:06.70 ID:znmRetLn
>>45
こういう処理はどれが正解って訳じゃないけど、見通しがついてよかったぬー

47 :デフォルトの名無しさん:2017/02/04(土) 22:20:54.73 ID:SpK5IAIQ
44が的確ですごいな

48 :デフォルトの名無しさん:2017/02/05(日) 00:02:27.35 ID:PGIZ+KFZ
>>44
GJ!!

49 :デフォルトの名無しさん:2017/02/05(日) 13:44:40.26 ID:jpxF0hW7
lock()と言うのがありますが、マルチスレッドの処理で
誰かが何らかのオブジェクトをlockしているかどうか知る方法はありますか?
if(IsLocked(obj)){

}else{

}
みたいな処理をしたいのですが。

50 :デフォルトの名無しさん:2017/02/05(日) 13:51:41.71 ID:QLCXp5gV
>>49
Monitor.IsEntered(obj)とか?

51 :デフォルトの名無しさん:2017/02/05(日) 14:09:45.29 ID:PGIZ+KFZ
>>49
lock は System.Threading.Monitor クラスを使うように展開されるみたいだからこいつの TryEnter( ) とか使えばいいんじゃね?
http://ufcpp.net/study/csharp/sp_thread.html

52 :デフォルトの名無しさん:2017/02/05(日) 14:22:39.19 ID:jpxF0hW7
>>50>>51
Monitor.TryEnterで上手く出来ました。
ありがとうございました。

53 :デフォルトの名無しさん:2017/02/14(火) 20:20:16.10 ID:9KVRWgtp
RxのSubjectで初期値のないBehaviorSubjectはないですか?
subscribeした時点でまだ一度もonNextをしていなければonNextするまでコールバックを呼ばず、
一度でもonNextされていれば最後の値をコールバックに渡す感じです

54 :デフォルトの名無しさん:2017/02/14(火) 20:49:20.54 ID:pU7mkQJz
>>53
Rxなんか使わずに単純に最後の値を変数に入れといてそれを読めばいいのでは

55 :デフォルトの名無しさん:2017/02/14(火) 21:07:29.79 ID:9KVRWgtp
>>54
変更通知…
rxが楽

56 :デフォルトの名無しさん:2017/02/14(火) 23:32:57.72 ID:sZcA1Jdu
マスコットキャラが作れると聞いて始めたのですが、
まったく、作れません。

軽く何かを教えてくださいお願いします。

57 :デフォルトの名無しさん:2017/02/14(火) 23:42:59.54 ID:jF3NlhZ4
不定形 ウィンドウ でググって、あとはタイマーで絵や座標を更新するとかかな

58 :デフォルトの名無しさん:2017/02/15(水) 13:44:40.41 ID:6MEGowR3
>>56
Unityちゃんでもいじってみ

59 :デフォルトの名無しさん:2017/02/15(水) 14:22:29.43 ID:fYC4NdgN
visual studio2012を使っています
c#でdatagridviewを使っていて、headertextを2行にしたいのですが、方法を教えてください

60 :デフォルトの名無しさん:2017/02/15(水) 14:38:33.74 ID:IaTHaUdU
>>59
改行コード入れればいいんじゃないか?

61 :デフォルトの名無しさん:2017/02/15(水) 18:06:53.63 ID:fYC4NdgN
GUI

62 :デフォルトの名無しさん:2017/02/15(水) 18:08:07.82 ID:fYC4NdgN
>60
GUIからだと入れることができませんでしたが、
コードから直接入れることができたので、
コードから入れました。

63 :デフォルトの名無しさん:2017/02/15(水) 19:46:34.50 ID:IaTHaUdU
>>62
俺も玉にはいい事言うよね。

64 :デフォルトの名無しさん:2017/02/16(木) 19:46:27.37 ID:3MqMajas
formアプリでformの大きさを小さくしたら配置してるコントロール全てがformの大きさに比率縮小されるっての出来ないですよね?

65 :デフォルトの名無しさん:2017/02/16(木) 20:07:17.83 ID:yaBP1ZBT
自前で比率計算すればできる
実装がめんどくさければGrapeCityのComponentOne買えばOK

66 :デフォルトの名無しさん:2017/02/16(木) 20:12:31.55 ID:C8TUip5w
WPFなら出来たけど、Winformはどうなんだろ

67 :デフォルトの名無しさん:2017/02/16(木) 20:34:36.40 ID:Dw9/ZFHg
http://m.chiebukuro.yahoo.co.jp/note/n77168
検索くらいしろよ

68 :デフォルトの名無しさん:2017/02/16(木) 22:06:01.73 ID:x6Naqncr
地道に力技でやるしかない
この辺りはformアプリは苦手

69 :デフォルトの名無しさん:2017/02/16(木) 22:16:06.79 ID:7GOAgwDK
メモ帳作ってるけど外観はできても中身ができなくて困ってる
クリックイベントは大丈夫なはずなんだけど、

開くや新規作成 検索とか、探してたら、

開くだけで、8行ぐらいコードが必要なんだけど?
1行で呼び出す、コードとか無いの?

70 :デフォルトの名無しさん:2017/02/16(木) 22:32:47.75 ID:/R92/z+7
8行でできるならいいじゃん
まとめたいならこれ
Process.Start("notepad.exe");

71 :デフォルトの名無しさん:2017/02/16(木) 23:25:56.09 ID:7GOAgwDK
>>70
どうも

初心者だから、妥協しようか迷ってたんだけど
当面はそちらで行かせて貰う

72 :デフォルトの名無しさん:2017/02/16(木) 23:30:09.61 ID:Dw9/ZFHg
いいのかよw

73 :デフォルトの名無しさん:2017/02/17(金) 08:32:40.56 ID:MUR4QGae
>>65-67
ありがとうござます
助かりました。調べて頑張ってみます

74 :デフォルトの名無しさん:2017/02/17(金) 08:33:43.24 ID:MUR4QGae
>>68
すみません。抜けてました。レスありがとうございます

75 :デフォルトの名無しさん:2017/02/18(土) 11:09:32.83 ID:cWaaGg3V
sqlの定義文をC#のソースにするのが面倒なんだが、気の利いたツールとかエディタの拡張とか知りませんか?

create tabale hoge ([hage] text) → "create table hoge " +"([hage] text)";

76 :デフォルトの名無しさん:2017/02/18(土) 11:15:39.58 ID:MSmTE/VQ
>>75
逐語的リテラル文字列
あとは補完文字列なんてのもあるが、SQLインジェクションには注意

77 :デフォルトの名無しさん:2017/02/18(土) 12:10:46.00 ID:52dA0McO
>>75
> create tabale hoge ([hage] text) → "create table hoge " +"([hage] text)";
変換規則がわからん
単にこれだけをやりたいだけなら正規表現でもできそうだが

78 :デフォルトの名無しさん:2017/02/18(土) 12:17:17.23 ID:rCytLmz9
>>75
スクリプトファイルの読み込みじゃいかんのか?

79 :デフォルトの名無しさん:2017/02/18(土) 13:26:45.21 ID:oikc5OUx
>>75
矢印が逆じゃあないの?
最終的には連結した一つの文字列にしたいんだろ?

80 :デフォルトの名無しさん:2017/02/18(土) 14:07:01.72 ID:uqTw3F8T
>>75
作れば

81 :デフォルトの名無しさん:2017/02/18(土) 14:25:52.73 ID:XkQA6zD3
>>75
そのサンプルだと両端にダブルクオーテーション付けて最後にセミコロン付けるだけでよくね?
わざわざ文字列を分割する必要性無いと思うんだけども

82 :デフォルトの名無しさん:2017/02/18(土) 18:29:25.18 ID:367vvwff
フォームを色分けしたいんですが、どうしたらいいでしょうか。
例えば半分から上は黒で下は白のようなものです。
現状panelを使ってそのように見せているんですが、いい方法あったら教えてください

83 :デフォルトの名無しさん:2017/02/18(土) 19:51:04.90 ID:d0hejx53
panelを2つ貼ってbackgroundcolourを設定しろよ

84 :デフォルトの名無しさん:2017/02/18(土) 19:58:44.57 ID:M4R1Zp6s
それやってるって書いてあんじゃん。読めよw
無理やりオーナードローかform捨てるしかないだろな

85 :デフォルトの名無しさん:2017/02/18(土) 20:00:20.55 ID:n/aPn98B
>>82
なんの目的があるかわからん。
色が分かれていても、別のものを表示している訳ではないの?

86 :デフォルトの名無しさん:2017/02/18(土) 20:24:06.51 ID:jkd676sQ
パネルじゃなくて、ラベルとか影響の少ないコントロールを Z オーダーの一番下に張るのとか出来なかったっけ。

87 :デフォルトの名無しさん:2017/02/18(土) 20:44:32.17 ID:n5oO6gvO
上にコントロール重ねること考えたらパネルが一番楽で無難なんじゃね
フォーム(パネル)の背景設定でもいいけど
>>86
パネル以外だと上にコントロール重ねたら下が見えなくならないかな

88 :75:2017/02/18(土) 22:28:19.09 ID:cWaaGg3V
sqliteで作るときに、テーブルをツールで定義してからそのsqlをC#のソースに変換するのが面倒だっから
ツールが有ったら使いたいなと思い聞いてみました

他のDBだと、ソースにテーブル定義を書くなんて無いからちょっと混乱させちまいましたね
面倒でも手でやるのが一番早そうだ

89 :デフォルトの名無しさん:2017/02/18(土) 22:56:35.91 ID:XkQA6zD3
EntityFramework でググれば幸せになれるよ

90 :デフォルトの名無しさん:2017/02/18(土) 23:07:16.07 ID:rCytLmz9
>>88
だからファイル詠み込めよ
なんで動的sqlでもないのにコードに書くんだよ

91 :デフォルトの名無しさん:2017/02/19(日) 00:04:30.14 ID:TkpsmKBX
>>82
サイズ変えないならFormのBackgroundImageに
色分けしたBitmap貼るとかいいんでないの?
好きな背景にもできるぞ

92 :デフォルトの名無しさん:2017/02/19(日) 00:14:46.31 ID:PjLfAeqZ
>82です。みなさんありがとうございます。
説明補足すると、メッセージボックスを自作していて、メッセージボックスのような背景を作りたかったんです。

93 :デフォルトの名無しさん:2017/02/19(日) 07:54:46.40 ID:ngALvOwB
>>88
> 他のDBだと、ソースにテーブル定義を書くなんて無いから
SQL-SERVER 使ってるけど一時テーブル作ったりで普通にあるけど?

94 :デフォルトの名無しさん:2017/02/19(日) 08:47:37.68 ID:iOIH+Q4P
>>92
似たようなことはDock=Top, AutoSize=FalseとしたLabelでよくやる。

95 :デフォルトの名無しさん:2017/02/19(日) 10:11:31.31 ID:93wksAh/
>>89
sqliteでEF使うと致命的に遅いから無理ですわ

>>90
何故に喧嘩腰?

>>93
俺はあまり一時テーブルに頼らずにviewでなんとかするのが好きだから、そこまで思い当たりませんでしたわ
たしかに一時テーブルが正義の場合だって少なくないだろうが

96 :デフォルトの名無しさん:2017/02/19(日) 10:23:29.24 ID:TZ/mXSM2
一時テーブルは保守性が下がりパフォーマンスもスケーラビリティも多くの場合悪くなるのでやめてください

97 :デフォルトの名無しさん:2017/02/19(日) 10:32:03.79 ID:kiv7S6GK
>>96
そう言って糞長いストアド作りまくった挙句に保守できなくなった案件があったと、DBコンサルが笑い話のネタにしてたな
一時テーブル=害悪はどこの文化なんだろ

98 :デフォルトの名無しさん:2017/02/19(日) 10:41:13.77 ID:98lVckOm
一時テーブルは使うけど実行時にcreateするってのは経験ないなぁ

99 :デフォルトの名無しさん:2017/02/19(日) 10:41:38.21 ID:7Avz8j0c
そういうのは結局は開発者の能力の問題
一時テーブルかストアドかはそれほど重要ではない

100 :デフォルトの名無しさん:2017/02/19(日) 11:34:46.47 ID:gpMreema
>>95, >>97
一時テーブルとビューとかストアドとは使いどころが違うと思うんだが何故に比較してるんだろ?

>>98
セッション内でのみ有効な一時テーブルとか使ったことないの?

101 :デフォルトの名無しさん:2017/02/19(日) 11:42:57.76 ID:98lVckOm
>>100
あったあった。そう言われると1度だけ。
あのときは言われたとおりやっただけだから忘れてた。

102 :デフォルトの名無しさん:2017/02/19(日) 11:52:35.81 ID:TZ/mXSM2
>>97
一時テーブルなんてなくてもクソ長くならないし
そもそもストアドなんて保守性の低いものをむやみに使う必要もない
リレーショナルデータベースとは何か勉強しなおしてこい

103 :デフォルトの名無しさん:2017/02/19(日) 12:29:51.72 ID:LQaPeC4X
普通はefを使うもんなの?

104 :デフォルトの名無しさん:2017/02/19(日) 12:40:55.60 ID:zEbYND7D
テーブルがシーケンシャルファイルにしか見えないCOBOL世代の人なんかは一時テーブルとかストアド好きだよね

結局は自分の慣れ親しんだ領域に持って行ってやるのがその人にとってはベストなんだよ
どうせ保守するのは自分じゃないし自社ですらないことも多いからその場でその人員でできるベストを採用しなきゃビジネスとして悪手
流行りや有名コンサルに乗せられて意識たかそうなコードをメンバーのスキルもないのに書こうとする
これが最悪の選択肢

列挙型とswitchで分岐しまくるほうがメンバーにとって理解しやすいならそれがいい
そういう現場では多態性を利用したコードは生産性が落ちる
一時テーブルとストアドも同じでメンバーが理解しやすいというなら保守を受注する会社あるいは保守担当の同僚に心の中で懺悔しつつ採用すべきだ

105 :デフォルトの名無しさん:2017/02/19(日) 12:43:22.84 ID:OMGCNA7z
スレチ

106 :デフォルトの名無しさん:2017/02/19(日) 12:55:43.81 ID:LQaPeC4X
>>104
>テーブルがシーケンシャルファイルにしか見えないCOBOL世代の人なんかは一時テーブルとかストアド好きだよね
新しい世代の人にはどう見えるの?
dbの操作はどういう手法が普通なの?

107 :デフォルトの名無しさん:2017/02/19(日) 12:58:51.41 ID:7Avz8j0c
>>106
大抵の処理は積極的にJOINを使えば1パスで済ませることもできる

108 :デフォルトの名無しさん:2017/02/19(日) 13:05:26.33 ID:NYetswUU
あとは、DBを永続化されたオブジェクトの単なるストレージと見做して
ORMを活用してほとんどC#の中でやってしまうスタイルもある

109 :デフォルトの名無しさん:2017/02/19(日) 13:10:17.55 ID:93wksAh/
速度が問題にならない場面でも速度ばかり気になるのは何故なんだろうな?
だから10倍遅くなるEFはあまり好きじゃない
エントリーみたいなものならEF使ったほうが良いとは思うんだけどね

110 :デフォルトの名無しさん:2017/02/19(日) 13:13:51.67 ID:LQaPeC4X
>>108
そのormというのは75みたいなsql文を実行するんですか?

111 :デフォルトの名無しさん:2017/02/19(日) 14:09:14.55 ID:zEbYND7D
>>106
別に新しくもなんともないけど普通は行あるいは命題の集合に見える
操作は当然DMLで行う(データ操作言語だからね)

112 :デフォルトの名無しさん:2017/02/19(日) 14:24:55.62 ID:7Avz8j0c
近年ではビッグデータ界隈で古典的なバッチ処理が最新技術として復活したけどね
処理を行単位ではなくテーブルからテーブルへの射影と考える粗粒度なバッチ処理は
分散処理や糞遅いスクリプト言語との相性がいい

113 :デフォルトの名無しさん:2017/02/19(日) 15:04:35.19 ID:rTEdd30o
最近EntityFrameworkじゃなくてDapperばっか使ってるわ

114 :デフォルトの名無しさん:2017/02/19(日) 15:09:45.51 ID:MFFmnvDE
真っ当な判断能力があるなら必然的にそうなる

115 :デフォルトの名無しさん:2017/02/19(日) 15:11:31.44 ID:OMGCNA7z
DbExecutor使ってるけど全然更新されなくて悲しい

116 :デフォルトの名無しさん:2017/02/19(日) 16:48:08.70 ID:LQaPeC4X
>>113
Dapperと言うのを調べてみたのですが生のSQLを実行するのと
何が違うのか良く分かりません。Dapperと言うのを使う場合でも
SQL文を実行するんですよね?
何が違うんですか?

117 :デフォルトの名無しさん:2017/02/19(日) 16:55:48.71 ID:JyXmk48j
>>116
Dapperは主にクエリ結果をオブジェクトにマッピングするためのライブラリ
Dapperを使わない場合でもDataTableやDataReaderをそのまま使わずに型安全なオブジェクトに変換してから処理をするだろう?
それを楽に書きたい人のためのものだよ

118 :デフォルトの名無しさん:2017/02/19(日) 17:11:25.76 ID:LQaPeC4X
>Dapperを使わない場合でもDataTableやDataReaderをそのまま使わずに型安全なオブジェクトに変換してから処理をするだろう?
Dapperを使わない場合ですが、DataTableに読み取ったあと、カラムの型は自分では分かっているので順番にデータを取り出して、
その型にキャストして読み出すのはダメですか?
それとも私何か勘違いしていますか?

119 :デフォルトの名無しさん:2017/02/19(日) 18:11:13.51 ID:7Avz8j0c
>>118
それを自動でやってくれるのがDapper

120 :デフォルトの名無しさん:2017/02/19(日) 20:35:23.16 ID:LQaPeC4X
>>119
なるほど。ありがとうございました。

121 :デフォルトの名無しさん:2017/02/19(日) 20:41:40.94 ID:+HIMLleH
Dapper気軽そうでいいね。

122 :デフォルトの名無しさん:2017/02/19(日) 21:16:27.26 ID:PjLfAeqZ
>94
なるほど、ありがとうございます

123 :デフォルトの名無しさん:2017/02/19(日) 22:55:47.64 ID:L+LZlPn0
35:54

10:40
https://www.youtube.com/watch?v=WTdY7h129Mk

https://www.youtube.com/watch?v=8R0luOy8ce8

124 :デフォルトの名無しさん:2017/02/22(水) 23:33:37.07 ID:yhciyQan
質問させてください。
なにかの処理中にフォームなどを起動させておく、以下の処理について。
while(xxx.HasExited == false) //xxxはインスタンス
{
Applcation.DoEvents();
System.Threading.Thread.Sleep(200)
}
この処理はwhile文で回していますが、DoEventsとSleepは、なにか処理が行われるたびに呼び出されると思ってよいのでしょうか。
起動中に
なにか処理する→0.2秒とまる→なにか処理する→0.2秒とまる→… みたいな。

またこのSleepは、現在起動中の処理を一時的に止めると思ってよいでしょうか。
ご教授お願いします。

125 :デフォルトの名無しさん:2017/02/22(水) 23:52:38.18 ID:d6y2GeKl
>>124
何を見たのか誰に教えてもらったのか知らないが、まずはそんなクソコードは忘れよう
DoEventsはVB時代の遺物であり、使用は推奨されない
今時は時間のかかる処理をGUIをフリーズさせることなく実行したい時は
await Task.Run(() => {
 何かの処理
});
と書く

126 :デフォルトの名無しさん:2017/02/22(水) 23:56:30.83 ID:huuz+PNn
その処理だと、全力でDoEventsと0.2秒休むを繰り返すだけだよ
つか、今どきDoEventsとか存在を忘れたほうがいいんじゃないかねえ

127 :デフォルトの名無しさん:2017/02/22(水) 23:57:19.06 ID:954rYVtd
>>124
そのセットは別スレッドの入力待ちのテンプレ
・・・Application.DoEvents()って必要だったっけ?w
それはあいまいだけど、キー入力待ちか外部exeからの返り値待ちで使われている

128 :デフォルトの名無しさん:2017/02/23(木) 01:32:48.34 ID:zQR1bKXh
>124です。みなさんありがとうございます。
最近は推奨されないんですね。
理解としては>127さんのとおり、イベント発生したらDoEventsが実行されると思ってよいのでしょうか。

129 :デフォルトの名無しさん:2017/02/23(木) 01:40:04.09 ID:l1pCIGHb

DoEventsが実行された時に貯まってるイベントを処理する

130 :デフォルトの名無しさん:2017/02/23(木) 14:52:23.00 ID:daVfofu2
C#をCGIぽく使うベストプラクティスとかないだろうか。
普段はcentOS+nginxでJavascriptとRuby/PHP、一部バッチにC#って感じでWebサービス開発してる。

リクエスト毎にサーバ側でC#アプリケーションを引数添えて実行して、戻り値を取得するのは出来るんだけど・・ 。
とても実用には耐えなさそうだし、Webホストとか使うのかと思ったがわからず困ってる。

131 :デフォルトの名無しさん:2017/02/23(木) 15:24:59.57 ID:0G6iEay4
なぜ実用に耐えなさそうだと思うの?
そう思うからには理由あるんでしょ。そこ解決すればいい

132 :デフォルトの名無しさん:2017/02/23(木) 19:34:00.47 ID:osMc+8cA
毎回プロセスつくんの?

133 :デフォルトの名無しさん:2017/02/23(木) 20:12:55.31 ID:OJm2Ca4N
じゃあC#でWebサービス作ればいいじゃないか

134 :デフォルトの名無しさん:2017/02/23(木) 20:13:27.60 ID:u2e4Httf
そんなごちゃ混ぜでちゃんと保守できるの?

135 :デフォルトの名無しさん:2017/02/24(金) 01:33:54.44 ID:eab+BK9O
>>130
ASP.NET Web API

136 :130:2017/02/24(金) 11:37:39.67 ID:dB0UjfyS
みなさん、回答ありがとう。

毎回プロセス作るのはオーバーヘッドでかいから、常駐型になるのかな?
その時のやり取りの仕方をSendMessageだったり、ファイル常時監視してキューファイル投げるとかしか知らないんだ。

WebサービスとかASP.NETで調べてたら、やっぱりC#としての回答はこれなのかなって気がしてきたわ。
個人的な宗教上の理由で避けたかったけど、検討してみる。。ありがとう。

137 :デフォルトの名無しさん:2017/02/24(金) 12:36:59.04 ID:YZGHPd2K
>>136
> 毎回プロセス作るのはオーバーヘッドでかいから
それが問題になるようなサイトなのか?

138 :デフォルトの名無しさん:2017/02/24(金) 15:11:03.84 ID:nwaeFCKh
ASP.NET MVCって案外重たいよ

139 :デフォルトの名無しさん:2017/02/24(金) 15:50:26.31 ID:pDljuoBB
そらそうやろ

140 :デフォルトの名無しさん:2017/02/24(金) 16:13:46.51 ID:0wjaf/O/
C#でWindowsフォームアプリケーションを作るための良い解説書はあるでしょうか?
独習C#はもう読み終えたので基本的なことはわかっていると思います。

141 :デフォルトの名無しさん:2017/02/24(金) 16:41:06.62 ID:nwaeFCKh
ゲームしたいです。ゲーム機とゲームソフト買いました。どっちのマニュアルも読みました
早く遊びたいです。次はどんな攻略本読んだらいいでしょう?

ゲームじゃこういうのないのに、プログラミングじゃ多いよな
基本わかったなら何故始めないw

142 :デフォルトの名無しさん:2017/02/24(金) 16:48:06.10 ID:0wjaf/O/
>>141
独習C#ではWindowsフォームの説明がいっさいなかったので、コンソールアプリしか作れないのです。
フォームに特化した解説書かサイトがあればと思い質問しました。

143 :デフォルトの名無しさん:2017/02/24(金) 17:08:33.80 ID:pp6ofCfh
本なんか一冊も読んでないけどWinFormアプリいくつも作っている
就活で役立てたいのならマ板に行って聞いたら?
趣味でやっているのなら向いていない

144 :デフォルトの名無しさん:2017/02/24(金) 17:45:41.09 ID:LZq2xNz5
Formアプリもコンソールアプリもコードベースで作るなら同じって慣れれば分かるけど、最初は分からないよねー
javaのswingで同じこと経験した

145 :デフォルトの名無しさん:2017/02/24(金) 17:57:21.18 ID:m8N/tmCl
本読むやつはプログラミング向いてない

146 :デフォルトの名無しさん:2017/02/24(金) 18:16:02.45 ID:2lTW2QAE
amazonでC#マガジンの海を渡ればWinFormの本が見つかる

147 :デフォルトの名無しさん:2017/02/24(金) 18:26:49.22 ID:2HxY6Dp6
まだWinFormの時代なんだなw

148 :デフォルトの名無しさん:2017/02/24(金) 18:27:42.45 ID:0tWWIcvC
>>145
悪かったな、読んでるよ。

149 :デフォルトの名無しさん:2017/02/24(金) 18:44:16.34 ID:ZTtaAqVi
きちんと勉強したいなら本代はケチんなってばっちゃが言ってた

150 :デフォルトの名無しさん:2017/02/24(金) 18:44:46.20 ID:WmxnDnjh
WPFの本出しても売れないのは明らかだしな

151 :デフォルトの名無しさん:2017/02/24(金) 18:47:19.91 ID:JpyYS2dN
コンソールアプリは明確にmainというエントリポイントがあるが、
GUIはイベントベースから最初の最初は戸惑うだろ。
(どこにコードを書くのかわからない)
ただ、1回やれば分かるが。

で、そのレベルならMDSNのチュートリアルで十分だと思うよ。
https://msdn.microsoft.com/ja-jp/library/dd492171.aspx
これで駄目なようなら向いてないってのは事実だよ。
本買って本格的に学ぶ内容ではない。
(これはWPFだけどどうせ違いも分かってないでしょ。
古いバージョンのを探せばフォームのチュートリアルもあるはずだし)

152 :デフォルトの名無しさん:2017/02/24(金) 18:49:16.49 ID:CB55ejbI
ダブルクリックしてれば何とかなる

153 :デフォルトの名無しさん:2017/02/24(金) 20:32:10.23 ID:DIkdt+H/
肥大化するForm1.cs

154 :デフォルトの名無しさん:2017/02/24(金) 20:55:52.19 ID:2lTW2QAE
ソリューションエクスプローラでファイルを入れ子にする
ttp://wiz.came.ac/blog/2009/09/post-2.html

155 :デフォルトの名無しさん:2017/02/24(金) 21:52:47.57 ID:KBFO5tFR
form動かすのは簡単だけどformのコードを破綻させずに書くのは難しい
少なくとも日本の大半の職業プログラマには無理
悲しいね

156 :デフォルトの名無しさん:2017/02/24(金) 22:19:08.66 ID:ezpXAtZb
動きゃいい

157 :デフォルトの名無しさん:2017/02/24(金) 23:22:45.93 ID:WdGON0E4
最近はウェブでなんとかなるんだが、きちんと本で勉強するべきだと思う。
C++長かったからC#楽勝と思ったけどラムダ式が読めない。
今更独習C#はと思ったが読んでよかった。

158 :デフォルトの名無しさん:2017/02/24(金) 23:40:01.37 ID:nwaeFCKh
ラムダ式使えなくって作りたいものは作れるからな
言語を学びたいのか、プログラミングしたいのか、だな

159 :デフォルトの名無しさん:2017/02/25(土) 00:07:49.88 ID:Hh3bBfOP
ラムダ?

登場してから60年以上たってもLISPが普及してないのが答え。いらん。

160 :デフォルトの名無しさん:2017/02/25(土) 00:27:59.19 ID:N0RLU+6x
俺が使っているのはJavaScriptなんだが、ラムダは超絶便利だぞ。
ただし使わなくても書けるし、いちいちクラスにしてしまう手もあるし、どうにでもなるのも事実だが。

本で学ぶことが必要なのではなくて、いろいろな道具があることを知るのが重要。
今時の言語は全てラムダ使えるんだから、他言語少しでも学んでいればラムダは使えたはず。
その点、C++は古い言語だったのも事実。

ただどう見ても142はそれ以前だろ。
そもそもWPF(というよりHTML)やったほうがいいんじゃないかと思うし。

161 :デフォルトの名無しさん:2017/02/25(土) 00:54:21.20 ID:N9ovtMND
ストラテジー用のインターフェース定義とかいちいちめんどくさい
Func、Action、ラムダでスパッと実装したい

162 :デフォルトの名無しさん:2017/02/25(土) 00:58:33.11 ID:Jm21gNIW
スパッと書く書式、
スパっと書くアルゴリズム、
スパッと書くクラス設計・・・
いつまで経ってもプログラミング始めれず勉強の毎日だぞ

163 :デフォルトの名無しさん:2017/02/25(土) 01:18:47.75 ID:N0RLU+6x
めんどくさい人にはマジでJavaScriptオススメ。
あのデタラメッぷりには最初戸惑ったが、慣れてしまうと相当いい。

ラムダに慣れたいだけなら、スクリプト言語系(JavaScript/Python/Ruby)がマジでいいと思う。
C#のデリゲートって使う前にいろいろ準備が要って面倒だし、
あるのを知ってても使う気にならないでしょ。
俺もVC++しか使ってないころは全く興味なかった。

でもJavaScriptでお気楽にラムダ使いまくった後は、VC++でも使いたくなる。
だってそのほうが楽だと知ってしまったから。
ただ、いちいち型を合わせないといけないのが面倒だったりする。

164 :デフォルトの名無しさん:2017/02/25(土) 01:26:56.21 ID:N9ovtMND
インテリセンス弱いスクリプト系言語は怠け者には向かない

165 :デフォルトの名無しさん:2017/02/25(土) 01:40:08.63 ID:N0RLU+6x
まあIDEに関してはC#が一番上なのだろうね。それは思うよ。

166 :デフォルトの名無しさん:2017/02/25(土) 01:45:57.08 ID:Hh3bBfOP
winform使うにしもてwin32の知識は必要。結局win32ラップだし。

167 :デフォルトの名無しさん:2017/02/25(土) 01:46:38.10 ID:FbflVc2K
ラムダはインテリセンスあってこそやね。

168 :デフォルトの名無しさん:2017/02/25(土) 02:39:26.60 ID:ByE41wZl
これからC#でGUIするんならWPFにしたらいいんじゃない。フォームは古いし。
但し、WPFの本はない、あるけど使えないと云うか価格に見合ってない。いい本あったら教えてもらいたい。

169 :デフォルトの名無しさん:2017/02/25(土) 07:34:49.62 ID:JxD18xMy
WPFやってみたけどやっぱりformのほうがお気楽だから戻ってきてしまった

170 :デフォルトの名無しさん:2017/02/25(土) 07:54:43.41 ID:fA+zhTaO
javascriptのラムダって例えばどんなヤツよ?

171 :デフォルトの名無しさん:2017/02/25(土) 08:03:07.91 ID:vx9FCuam
>>170
今のJavaScriptは (x, y) => x + y のようなC#と全く同じ構文の(というかC#をそのまま真似したんだろうけど)ラムダが使えるよ
もちろん従来の function(x, y) { return x + y; } でもいいし

172 :デフォルトの名無しさん:2017/02/25(土) 10:39:52.17 ID:TcOntMIt
JSだとインテリセンスが弱い?TypeScript使おうぜ

173 :デフォルトの名無しさん:2017/02/25(土) 12:04:24.91 ID:N0RLU+6x
JavaScriptのラムダがC#を真似したと言うのは自意識過剰すぎ。(短縮記法の()=>は真似してる)
インテリセンスはMS発なんだしはっきり言えば全員C#を真似しているからVS環境のTSではよくて同等まで。

JavaScriptは文法的な意味で関数とラムダを区別してない。
だからさらっと書いてそれだけ。

var count = 0;
var count_up = function(){count++;};
var show_count = function(){console.log(count);};

count_up();
count_up();
show_count(); // 2

見りゃ分かるが具しか書いてない。だから論理的にこれ以上お手軽なのはない。
(短縮記法は出来るがあれはタイプ数がケチれるだけ)
ついでに階層もクラスも関数で記述するというデタラメッぷり。
だからそもそも「ラムダなんて使いません(キリッ」みたいなことが出来ない。
(階層がラムダ)

知らなければ意味不明だと思うが、とにかくそういう世界だ。
その状況で慣れると、心理的な障壁が取り除かれる。
ラムダ嫌いって要するにこれだろうし。

174 :デフォルトの名無しさん:2017/02/25(土) 12:12:40.17 ID:TcOntMIt
ES6ならclass構文(内部では関数に変換されるけど)あるからかなり楽になったぞ

175 :デフォルトの名無しさん:2017/02/25(土) 12:24:18.16 ID:S4wbN3RD
ラムダは真似というか普通に輸入だろ
ES6の策定にはMSも主導的な立場のメンバーとして当然参加してるし

176 :デフォルトの名無しさん:2017/02/25(土) 12:26:33.18 ID:IfKbzrsT
>>173はjavascriptやったことない奴でも初見で何してるか分かる
でもこんなの書かれたら初見で見破るの無理でしょ
var res = ((Func<int, int, bool>)((i, j) => i == j))(5, 3);

ラムダ嫌いはラムダが嫌いなんじゃなくて、読みにくいラムダが嫌いなんでしょ
「ラムダなんて使いません(キリッ」じゃなくて「読みにくいラムダなんて使いません(キリッ」なんだよ

177 :デフォルトの名無しさん:2017/02/25(土) 12:31:25.09 ID:N0RLU+6x
>>174
あんなもん所詮慣れ。俺は従来のJavaScriptの構文でも苦労してない。
そしてラムダも所詮慣れ。慣れればどうって事は無い。(難しくは無い)
ただし使わなくても実装できるのは事実で、わざわざ慣れる必要があるかは微妙。

178 :デフォルトの名無しさん:2017/02/25(土) 12:45:06.30 ID:S4wbN3RD
>>176
関数の即時評価はJSでは非常によく使われるテクニックだよ
C#のラムダなんて、本来の副作用がない使い方をするのがほとんどだから可愛いもんだ
JSではガンガン副作用書いていくから超複雑だよ

179 :デフォルトの名無しさん:2017/02/25(土) 13:25:03.75 ID:Hh3bBfOP
>>176
パラダイムが違うものごっちゃにして何がしたいんだ?
やたらカタカナ使う田中康夫やルー大柴の日本語みたいなものだ。

180 :デフォルトの名無しさん:2017/02/25(土) 13:29:41.99 ID:N0RLU+6x
>>176
それは型情報を付加しようとしているから見た目複雑になる。
型情報が無いJavaScriptなら以下になる。

var func = function(i,j){return i==j;};
var res = func(5,3);

もちろん1行でも書けるが、これはJSer以外にはすこぶる評判が悪い。

var res = (function(i,j){return i==j;})(5,3);

そしてこれをアロー関数(短縮記法)で書いたらC#の型情報を落としたものと同じになる。

var res = ((i,j)=>i==j)(5,3);

そもそも「お手軽にやろうぜ」というノリなら型情報が無いほうがよく、
その点がC#だとどうにもフィットしない。


ただしラムダ使い全般が馬鹿なのか、
あるいはJavaScript含めた関数系一般に言える傾向なのかは定かではないが、
おかしな記述で余計複雑にする馬鹿、まさに「木を見て森を見ず」はよく見かける。
奴らは「木」つまり一箇所の記述を最小限にすることに異常にこだわり、
「森」つまり全体を最小限にすることを考えていない傾向がある。
だからラムダ(キリッな奴が出してくるコードが糞なことも多く、
これがラムダを知らない連中にとってラムダを学ぶ価値があるように見えない理由だと思う。
対してオブジェクト指向は「森」を「林」に小分けする手法だから、
オブジェクト指向をきちんと出来ている連中から見れば余計に馬鹿に見えてしまうし。

181 :デフォルトの名無しさん:2017/02/25(土) 13:31:51.44 ID:Hh3bBfOP
これだからemacs使いは嫌われるんだよ。

182 :デフォルトの名無しさん:2017/02/25(土) 14:43:31.03 ID:Qzh8dVTL
関数呼び出しでデリゲート渡すところをラムダ式で書いたりするのが便利だし、プログラムが小さくなり、関連ある記述がまとまり、慣れると読み易い。
まあ、伝統的と云うか、平均以下のレベルに合わせたコーディング規約が幅をきかせているプロジェクトでは忌み嫌われる。

183 :デフォルトの名無しさん:2017/02/25(土) 15:18:03.16 ID:IvVV1H8V
var res = (5 == 3)

それ関数使わなくてもいい例だから
もうちょい違うのなかったかな

184 :デフォルトの名無しさん:2017/02/25(土) 15:39:38.73 ID:9TfgDVOx
保守性や可読性でラムダを嫌う人がいるのはまあ良いんだけど
経験的にそういう人のコードが優れてるかっていうとそうでもない
同じような構造のループ処理を大量生産したり
try catch log出力を延々と全てのメソッドに書いたりする

185 :デフォルトの名無しさん:2017/02/25(土) 15:44:53.00 ID:3ZNX7OqZ
>>183
今日のとんちきレス大賞

186 :デフォルトの名無しさん:2017/02/25(土) 15:46:20.53 ID:TcOntMIt
ラムダは静的なダックタイピングにするべきだったと思う
長くなる時はエイリアス設定するとかにして

187 :デフォルトの名無しさん:2017/02/25(土) 15:46:55.92 ID:TcOntMIt
>>183
ガイジかな?

188 :デフォルトの名無しさん:2017/02/25(土) 16:24:58.90 ID:N0RLU+6x
>>182
つかそういう問題じゃない。C++なら例があるが。
> auto 型推論とラムダ関数を使用すると、コードをすばやく記述して、それを引き締め、より的確に把握することができます。
> https://msdn.microsoft.com/ja-jp/library/hh279654.aspx
この2つのコードで下のほうがいいと思えるかどうかだよ。

正直、俺にはどうでもいい範囲だよ、これは。
こんな局所的部分で活用(キリッしたところで大して意味が無い。
確かにコードは減るけど、バグる確率が減るわけじゃないでしょ。
そして関数型()の連中が出してくる「ラムダの優位性(キリッ」なコードはほぼ全てこの類であり、
巨大プログラムを分割して直接的に単純化する「オブジェクト指向」と比べて、訴求力に乏しい。

理由は簡単で、そもそもラムダは「糖衣構文」でしかないから。
実体は「関数ポインタ+変数」であり、
Cなら構造体ポインタを引数に取る関数、
C++なら関数オブジェクトまたはクラスで表現できる。
(見にくいが元々記述できる。これがストロウストラップがラムダ導入に反対していた理由だと聞いた)
だからJavaScriptの文法が関数=ラムダ=階層=クラスなのも自然ではあるし、
Rubyが匿名関数(ラムダ)を匿名クラスで表現するのもこのため。

結局、ラムダを導入したところで出来ることは増えず、本当の意味での「エレガント」なコードにはならない。
ところが関数型()の連中は「エレガント」=「短い」or「ラムダ使ってる」と勘違いしている馬鹿が多くて、
上記URLのコードなら「下側がイイ!」「下側じゃ無いと許さない!」とか言い出すからおかしくなる。
「自転車置き場の議論」と同じで、馬鹿なりに見える範囲で考えたんだろうが、所詮馬鹿でしかない。

プログラミングにおける「エレガント」は数学と同じで、
「こう考えればこんなに簡単に解けるんだ!」であり、
糖衣構文でしかないラムダは本質的には全く効果が無い。
ただし、俺自身も慣れる前はラムダを選択肢に入れていなかった=思考を狭めていた。
これはまずいので、通常の選択肢として考えられるほどには慣れておく必要はある。
ただ、それ以上の意味は無い。

189 :デフォルトの名無しさん:2017/02/25(土) 16:25:31.63 ID:N0RLU+6x
余談だが、JavaScriptのプロトタイプとダックタイピングはこの意味で面白い。
出来ることが増えているので、直接的にもっと「エレガント」を探求できる。
以前話題になっていた拡張メソッドの継承もJavaScriptなら最初から出来る。

ただし、何でもかんでも出来ればいいものでもなく、馬鹿に使わせたら余計におかしくなるのも事実。
その点、C#はいいバランスを目指していていい。
ただしこの意味で「封印済み」の場所もあるから、
C++やJavaScript等「何でもあり系」言語に親しむのも悪くないと思う。

190 :デフォルトの名無しさん:2017/02/25(土) 16:30:23.41 ID:IvVV1H8V
>>185,187
ほう? じゃ>>176のこのコードがどういう場合に有用なのか教えてくれ
>var res = ((Func<int, int, bool>)((i, j) => i == j))(5, 3);

191 :デフォルトの名無しさん:2017/02/25(土) 16:39:02.64 ID:TcOntMIt
>>190
C#とJSのラムダの比較の為に出しただけであって、有用なのかは今関係ない

192 :デフォルトの名無しさん:2017/02/25(土) 16:39:23.68 ID:3ZNX7OqZ
>>190
誰も処理内容の話なんかしてないぞ
みんなはアメをくるむ包装紙の話をしてるのに君だけアメの味を話題にしてる

193 :デフォルトの名無しさん:2017/02/25(土) 16:41:51.21 ID:TcOntMIt
例え上手い

194 :デフォルトの名無しさん:2017/02/25(土) 17:09:31.56 ID:fb/41uG4
>>190
まじasp

195 :デフォルトの名無しさん:2017/02/25(土) 17:21:54.68 ID:WB0pRnLv
変更されることがない前提のList<int>を複数のスレッド
でforeachするのは問題があるでしょうか。
やっぱりlockすべき?

196 :デフォルトの名無しさん:2017/02/25(土) 17:22:56.07 ID:N0RLU+6x
>>186
コードを最小限にするためには
・型=なし
・多重継承=あり
・ダックタイピング=あり
がいい。この点JavaScriptは、型無し、多重継承は手動で可能、ダックタイピングあり、なので向いている。

一方C#は、型あり、多重継承禁止、ダックタイピングなし、なので
「コード量」よりは「きっちり書くこと」を目指しており、
「手抜き」が主な目的のラムダとどうにも相性が悪い。
ここでダックタイピングだけ導入しても余計に混乱すると思う。

つかね、C#って「一文字でもケチりたい」奴用の言語ではなくて、
「型なし言語では堅牢なアプリは作れない」と考える連中用の言語だし。

197 :デフォルトの名無しさん:2017/02/25(土) 17:30:35.48 ID:IvVV1H8V
はあ?
包装紙の不要な物を包装紙でくるんでこんな包装の仕方はダメじゃって言ってる人に
包装紙の良し悪しについて平然と議論しつづける神経のほうがわからんよ

198 :デフォルトの名無しさん:2017/02/25(土) 17:43:27.22 ID:Hh3bBfOP
C#は業務系で使われたいのか、やっつけアプリ用に使われたいのかって話だ。

業務系で使われたいならシンタックスを増やすなって話だが、どうやら後者らしいので、c#はキティ用言語といえる。

199 :デフォルトの名無しさん:2017/02/25(土) 18:38:47.74 ID:ByE41wZl
>>195
lock不要に一票。
追加削除ないなら配列じゃダメなの。

200 :デフォルトの名無しさん:2017/02/25(土) 18:53:44.75 ID:ByE41wZl
C#はちゃちゃとプログラムにも業務にも使える優れもの。
シンタックス変えてない。拡張だろ。
LInqなんか追加されてホント便利になってる。

201 :デフォルトの名無しさん:2017/02/25(土) 19:22:21.24 ID:FbflVc2K
>>180
めっちゃ読みづらい。
いやスペースがないせいだけどw

202 :デフォルトの名無しさん:2017/02/25(土) 20:01:05.66 ID:lRvoFyV9
>>195
不要
もし後で変更する可能性があるならReaderWriterLockSlim使っとけばいい

203 :デフォルトの名無しさん:2017/02/25(土) 20:48:05.07 ID:kVUREvkV
>>199,202
ありがとう。
foreachによって実は内部的な変化が行われていたらまずいのではと
考えていました。

204 :デフォルトの名無しさん:2017/02/25(土) 20:49:00.75 ID:IvVV1H8V
>>195
AsReadOnly()とか使って使う側が変更しないことを保証しといたら?
ImmutableList<T>を使うともっと堅い

205 :デフォルトの名無しさん:2017/02/26(日) 03:14:38.88 ID:0YrJqBhk
ID:N0RLU+6xはもっと要点をまとめて端的に書き込めよ・・・
お前の言う「ラムダの優位性(キリッ」をC#で言ってる人なんてそうそう見ないぞ

変にプログラミング言語一般のラムダについて述べるせいで論点がブレブレだ

206 :デフォルトの名無しさん:2017/02/26(日) 04:03:21.89 ID:0YrJqBhk
日本語が苦手なのかもしれないが、「文法的な意味で関数とラムダを区別してない」とか「関数=ラムダ=階層=クラス」とかはよくないでしょ
初心者にjavascriptの関数が全てラムダみたいな誤解を与えかねない

>Rubyが匿名関数(ラムダ)を匿名クラスで表現するのもこのため。
Rubyの匿名関数(無名関数の方が一般的な呼び名だけど)は匿名クラス(無名クラスの方が一般的だけど)じゃなくて「Procオブジェクト」

207 :デフォルトの名無しさん:2017/02/26(日) 10:41:00.28 ID:/Q8k6Dmd
C#のラムダ式は、どっちかというと式木が目的で導入されたんじゃないの?

てか、いい加減スレ違いでしょ、この話題。

208 :デフォルトの名無しさん:2017/02/26(日) 11:19:59.83 ID:TMS4+8Av
>>207
式木はdynamicと関係あるだろ
ラムダ式はLINQのメソッド形式では必須

209 :デフォルトの名無しさん:2017/02/26(日) 11:26:13.98 ID:a7NPBA4e
いやメソッド形式では(事実上はラムダ式必須であっても)匿名メソッドでも代用はできる
式木は意味的に匿名メソッドが式にならないからラムダ式が必須だよ
匿名メソッドで式にできるように言語拡張しても良いけどそれってラムダ式そのものだし

210 :デフォルトの名無しさん:2017/02/26(日) 11:33:24.17 ID:asTjjGDY
どうでも良いがJavaScriptのfunctionとアロー関数は
等価じゃないぞ。
乱用してバグこしらえるパターンだな。

211 :デフォルトの名無しさん:2017/02/26(日) 11:36:25.80 ID:H7bo/69j
>>210
functionだとself定義しないといけなくて面倒だけどアローは楽だよな

212 :デフォルトの名無しさん:2017/02/26(日) 11:36:30.05 ID:Q2GAsSXo
式木の説明読んでみたが、言ってることが関数型()の連中と全く同じでワロタ

213 :デフォルトの名無しさん:2017/02/26(日) 11:44:07.89 ID:LLZCcrhN
>>208
式木はもともとdynamicとは全く関係ないよ
DLRプロジェクトで動的コンパイル用のASTが作られたが、System.Linq.Expressionsと被ってるということでそれを拡張する形で統合された
結局DLRは頓挫してコアの部分だけがCLRに導入され、そこに乗っかって実装されたのがdynamic

214 :デフォルトの名無しさん:2017/02/26(日) 11:49:23.90 ID:0YrJqBhk
>>212
(多少関連のある使い方ができるかもしれんが、)全然違うだろ
どこを読んだらそんな変な読み取りができるんだ?

215 :デフォルトの名無しさん:2017/02/26(日) 11:59:43.17 ID:LLZCcrhN
>>212
式木やdynamicのあたりは今時のミーハーな関数型()とはだいぶ色が違うと思う
LispのマクロとかMOPとかの影響を受けた、かなりガチなマニアックな設計思想の

216 :デフォルトの名無しさん:2017/02/26(日) 12:33:17.61 ID:Q2GAsSXo
>>215
てか式木っていったい何がやりたかったの?
超高速Evalか?

217 :デフォルトの名無しさん:2017/02/26(日) 12:57:05.99 ID:LLZCcrhN
>>216
式木の目的は、C#で書かれた式を独自に解釈して処理すること
例えばラムダ式を変換してExcelの数式を生成したりできる
文字列を使うのに比べて解釈が楽、型や構文の静的チェックが可能、インテリセンスが効くといった利点がある

218 :デフォルトの名無しさん:2017/02/26(日) 13:49:21.90 ID:Q2GAsSXo
>>217
おそらくLISP信者も同様にそのポテンシャルに魅了されているのだと思うのだが、
具体的に何に活用できるのだ?
何にでも使えそうだが、いざ何に使えば「他では達成できないほど」の結果を引き出せるのか分からない。

> 例えばラムダ式を変換してExcelの数式を生成したりできる
なるほど素晴らしい。しかしExcelシートを別に用意した方が楽だし、
通常の数式ならC#側で「テキスト」として出力するのも難しくは無い。
(もちろん出力パーサの再開発になるから、MS謹製自動変換のほうが楽だが、その程度)

> インテリセンスが効くといった利点がある
これは利点ではあるが、主な目的のうち大半は「手打ち」ではないだろうから、この際あまり関係ない。

> 文字列を使うのに比べて解釈が楽、型や構文の静的チェックが可能
これを「ユーザ側」の利点とするなら、ユーザー側でのパーサ生成、
つまりメタメタプログラミングを想定していることになるが、そうなのか?

結果的にLISPで成功したプロジェクトといえるのはemacsのみだ。
対してCはほぼ全てのPC世界を再構築しているに近い。
理由付けはいろいろ出来るだろうが、結果的に誰もLISPを選ばなかったということではある。
他でもっと簡単に目的を達成できる方法があるのなら、誰もより複雑な方式での解決なんてしない。
結果的に、何でも出来るLISPは誰にも使われなかった。式木の雰囲気も見た目これに近い。

ExcelはExcelで、C#はC#で、で誰も文句は無い。
(その分簡単になっていて、Excelは非プログラマでも十分使える)
そこを統合するのは学術的には意味があるが、現実的には意味が無い。
HaskellやPrologみたいにアカデミック向けなら分かるが、C#はそうではないし。

219 :デフォルトの名無しさん:2017/02/26(日) 14:12:54.65 ID:AZYnfb42
メタプログラミングで便利
以上

220 :デフォルトの名無しさん:2017/02/26(日) 14:23:30.18 ID:Q2GAsSXo
しかし現実的には、通常のプログラミング:メタプログラミング=100:1、位の分量しかないだろ。
どうでもいい箇所の高速化をやってる馬鹿と同じ。そこにこだわっても効果ないよ。

221 :デフォルトの名無しさん:2017/02/26(日) 14:36:14.18 ID:0YrJqBhk
>>220
リフレクションの代わりにして高速化するとかの目的で結構使われてる
アプリケーションで使うよりもライブラリの内部とかで使うことが多い

222 :デフォルトの名無しさん:2017/02/26(日) 14:37:28.54 ID:bMNV8RU5
一度時代から消えたような無用な機能を言語オタクが復活させてみんな迷惑してるいう状況。

223 :デフォルトの名無しさん:2017/02/26(日) 14:38:28.84 ID:BapL/ZVi
他言語からの移植が楽
可読性悪くなるから使うことはないな

224 :デフォルトの名無しさん:2017/02/26(日) 15:03:16.38 ID:bMNV8RU5
はるか昔、C++ vs Objective-Cの戦いで瞬殺されたObjective-Cを
コード書けないジョブスが引っ張り出してきて、みんなが迷惑してるレベル。

それがC#とヘジ。

225 :デフォルトの名無しさん:2017/02/26(日) 16:19:53.46 ID:cWe1Zi+O
C++が勝ったのはCとの互換性で、ジョブズがObjective-Cを選んだのはC++が美しくなかったからだと思う。
しかし、O-CはAppleだけだから、やらされる身からすると迷惑なんだろう。

226 :デフォルトの名無しさん:2017/02/26(日) 16:33:51.40 ID:bMNV8RU5
はるか昔、BASIC vs Pascalの戦いで、激戦の末、BASICが市場を制した。
にも関わらず、BSDにOSX、iOSなどと名前詐欺するように、PascalにDelphiなどとかっこいい名前をつけて売り出した男がいる。

ヘジである。

とある事業でMSの独占だと将来に保守するリスクが高まるのでDelphiを採用した開発があった。
Delphiは一瞬市場で人気は出たもののすぐに消えた。あのとき大量に作られたコードは今も保守されてるんだろうか。

市場から一度消えた古い技術を引っ張り出す輩はほんと迷惑である。

227 : ◆QZaw55cn4c :2017/02/26(日) 17:17:53.27 ID:1LlUyF33
pascal はいい言語だよ,LL(1) なんて美しいじゃないか

228 :デフォルトの名無しさん:2017/02/26(日) 17:26:34.35 ID:cWe1Zi+O
アルゴリズム+データ構造=Pascal
これが私の原点だ。
でも、生活の為に、いまだCやってる。
ヘッダファイルが面倒、C#はヘッダファイルなくていいね。

229 :デフォルトの名無しさん:2017/02/27(月) 08:50:13.59 ID:DR1RgDtx
式木は実行時コンパイルできるという利点もあるよ
実行時コンパイルはシリアライザの高速化に使用されている

230 :デフォルトの名無しさん:2017/02/27(月) 12:29:20.61 ID:4XW6lmAf
ラムダ式使ってたけど、>>104みたいな理由で自分以外保守できなくなったから.NET2.0時代の表記に戻したな
いくら便利でも周りが使う気無いなら意味ねえわ・・・

231 :デフォルトの名無しさん:2017/02/27(月) 13:39:39.07 ID:v0Y8eGO4
技術者の1割しか理解してないものを仕事で使用できるわけがない。
C#とVBでVBが選ばれるのも仕方がない。仮にC#なんか選んでしまうと一部の技術者に負担がすべていく。
するとC#にしろ、ラムダ、LINQOKにしろ、WPFにしろと言ってた輩が無責任に最初に転職していく。
残された奴らじゃとても保守は無理。

232 :デフォルトの名無しさん:2017/02/27(月) 13:47:01.73 ID:BO1ZZ84r
便利だから楽だからって言い張るから導入した途端
その人が辞めていく法則

233 :デフォルトの名無しさん:2017/02/27(月) 17:10:34.62 ID:ToRYKJiY
そういうのはマ板でやってくれ

234 :デフォルトの名無しさん:2017/02/27(月) 18:55:42.34 ID:bS39cZCs
業務では言われたことを適当にこなして定時で帰れば良い
お家に帰ってからが楽しいプログラミングの時間だ
誰にも足を引っ張られないで好きなことをできる
悲しいね

235 :デフォルトの名無しさん:2017/02/27(月) 19:12:51.30 ID:bir6oLGv
>>230-232
俺はそれでいいと思うけどね。
結果的に「従来記法しかしない会社」と「意識高い記法をする会社」で市場で勝敗つければいい。

本当に「生産性が高い」のなら相手を容易に駆逐できるはず。
出来ないのならその程度だってこと。
まだらになっている方が生産性が悪い。分離して競わせるのが正しい。

多分、ラムダ、LINQ、WPFには相手を駆逐できるほどのインパクトは無い。
対してメモリ保護、GCはかなり劇的に楽になるのでCはシェアを落としつつある。
ちなみに俺はHTMLはフォーム/WPFを駆逐できると思う。

236 :デフォルトの名無しさん:2017/02/27(月) 19:15:16.04 ID:Ftr1v2iE
ラムダとリスト操作系関数は少し慣れればかなり便利
WPFは、WEBフレームワークに似てるからそっち系の人は良いのでは

237 :デフォルトの名無しさん:2017/02/27(月) 19:17:31.38 ID:Ehytdfgf
>>235
ごちゃ混ぜで語りすぎてる。
ラムダ、LINQなんてちょっと学習するだけやん。
請負、派遣業界に無理なのは分かるがw

238 :デフォルトの名無しさん:2017/02/27(月) 19:47:36.34 ID:RCbBwD75
書籍代は幾ら有っても足んね〜

みんなは、どうしてる?

図書館は、全くと言って良いほどロクな書籍が無い
後はグーグル書籍で、漁る位だし……。

239 :デフォルトの名無しさん:2017/02/27(月) 19:55:43.62 ID:GaZbolX8
APRESSから買っている

240 :デフォルトの名無しさん:2017/02/27(月) 20:15:06.48 ID:RCbBwD75
ほむ

241 :デフォルトの名無しさん:2017/02/27(月) 20:17:13.08 ID:zuqOpmfm
>>238
MSDNのリファレンスを全部プリントアウトしたほうが安いんじゃね?

242 :デフォルトの名無しさん:2017/02/27(月) 20:46:05.22 ID:RCbBwD75
>>241
その発想は無かった

因みに get setの使い道が微妙なんだけど、
具体的な使用例とか、教えてくれ><

243 :デフォルトの名無しさん:2017/02/27(月) 20:55:40.51 ID:SheqW2pp
>>242
カプセル化

244 :デフォルトの名無しさん:2017/02/27(月) 21:04:36.29 ID:bir6oLGv
>>236
WPFざっくり見てみたが、HTML/CSS/JavaScriptの再開発でしかない。
時期的な問題もあったのだろうが、
ここまで似せるなら最初からHTML/CSS採用しろよ、とWEB系からは見えるだろう。
WEB系の連中を引っ張り込みたいのなら、今からでも全面採用して、
HTML/CSS/C#出来るようにするべきだろう。

見た目、WEB系はC#よりも新技術の使い捨てが酷くて、余裕が無い。
彼らにとってWPFは簡単だが、学ぶのが面倒であり、その価値もないから、
Electron(HTML/CSS/JavaScript)でデスクトップアプリを作る方を選択するだろう。

面倒だから学ばない、というのはラムダもLINQも同じ。
元々無くても出来るのだから、それで苦労してない人には同期付けが無い。
その辺がメモリ保護/GCと根本的に異なる。

245 :デフォルトの名無しさん:2017/02/27(月) 21:14:29.75 ID:Ehytdfgf
>>244
相変わらず馬鹿だな。

246 :デフォルトの名無しさん:2017/02/27(月) 21:19:28.45 ID:QfkRDmsT
ざっくりじゃなくて、もう少しちゃんと使って理解してから評価しなよ。

247 :デフォルトの名無しさん:2017/02/27(月) 21:22:26.99 ID:aCjjvIHm
15年ぐらい前htmlviewでui作るの流行ったな。もうすっかり見かけなくなったがw

248 :デフォルトの名無しさん:2017/02/27(月) 21:34:20.63 ID:sVGz7y9C
html5ならUWPにあるから良かったじゃん

249 :デフォルトの名無しさん:2017/02/27(月) 21:39:40.07 ID:Ftr1v2iE
>>244
Electronは遅すぎる

250 :130:2017/02/27(月) 22:16:01.34 ID:8x434lFb
>ここまで似せるなら最初からHTML/CSS採用しろよ、とWEB系からは見えるだろう。
>WEB系の連中を引っ張り込みたいのなら、今からでも全面採用して、
>HTML/CSS/C#出来るようにするべきだろう。

ASP.NET MVCってまさにこれ?

251 :デフォルトの名無しさん:2017/02/27(月) 22:49:12.00 ID:bir6oLGv
>>248
> UWP
名前しか聞いた事無かったけど、これは良いね。
HTML/JavaScriptならElectronと同じコンセプトが可能か?

HTML/C++で使いたいんだが、この組み合わせは無理なのか、、、

252 :デフォルトの名無しさん:2017/02/27(月) 23:22:57.99 ID:ENJIvJC4
妄想だけでよく書くなほんと

253 :デフォルトの名無しさん:2017/02/27(月) 23:40:54.02 ID:o2MHRqlI
>>238
最近の本は安くなってるよ。
一番高かったのは2000年当時、Windows関連書籍で一冊1万越えもあった。
平均7、8千円かな、5千円だと安いと感じた。
本代はケチらずばんばん買ってる。
飯の種だし、1日悩んでたら人件費何万になる?
本買って解決すれば安上がり。

254 :デフォルトの名無しさん:2017/02/28(火) 00:00:06.65 ID:8+bIkryZ
>>251
WPF → UWP という進化だよw

255 :デフォルトの名無しさん:2017/02/28(火) 00:13:12.42 ID:3lr7jZCG
一応最終的には全ての組み合わせが出来ることを目指してるんだろ?
看板付け替えただけ、という見方かもしれんが、俺は進化でいいと思うぞ。

256 :デフォルトの名無しさん:2017/02/28(火) 00:17:57.53 ID:C4A7F+ay
>>251
MFCでだいぶ前からhtml/c++はできるじゃん。

257 :デフォルトの名無しさん:2017/02/28(火) 19:37:38.52 ID:yxAUZLha
テキストファイル中の、特定の行だけを読み込むにはどうしたらいいでしょうか?
読みたい行が何行目かは決まってるんですが、
1.1行目からその行までに含まれる文字数
2.読みたい行からファイルの末尾までの行数
は不定です。
FileStream.Seekの、バイト数ではなく行数指定出来るものがあればいいんですが。

258 :デフォルトの名無しさん:2017/02/28(火) 19:42:51.05 ID:9Xdv30xY
>>257
ループ回して対象行のカウントでホゲホゲすれば?

259 :デフォルトの名無しさん:2017/02/28(火) 19:44:38.27 ID:yxAUZLha
>>258
ありがとうございます。
うまくできました。
StreamReader reader = new StreamReader(file,Encoding.Default);
for(int i = 0; i < 10; i++)
{
reader.ReadLine();
}
this.listBox1.Items.Add(reader.ReadLine());

260 :デフォルトの名無しさん:2017/02/28(火) 20:23:35.47 ID:K7hLR7oh
>>259
実践で使えないコード過ぎてイラっときた
気分で改行したら終わりって

261 :デフォルトの名無しさん:2017/02/28(火) 20:29:23.68 ID:+WocOs48
>>260
読みたい行が何行目かは決まってるのに気分で改行したがるその仕様無視にイラっときた

262 :デフォルトの名無しさん:2017/02/28(火) 20:35:19.50 ID:K7hLR7oh
本当はキーワードがありそうじゃん
n行目ってのはあくまで質問者が宿題を読んだ感想文なわけで

263 :デフォルトの名無しさん:2017/02/28(火) 20:37:44.89 ID:Fq1JMnLG
>>262
エスパーさんはいらないから
汎用性のないコードだってのならともかく「本来はこんな問題のはず」とか議論しても何もならん

264 :デフォルトの名無しさん:2017/02/28(火) 21:08:18.23 ID:pIiGTdLD
>>260
どこが実践で使えないんだ(笑)

265 :デフォルトの名無しさん:2017/02/28(火) 21:15:58.55 ID:wrouDyFM
とんちき臭がする

266 :デフォルトの名無しさん:2017/02/28(火) 21:19:57.27 ID:BFmlECVl
ClosedXMLを使って、2行分のデータとスタイル(罫線等)を、任意の2行へコピーしようとしています。
CopyToを使って動かしてみると、マージされているセルなどが思った通りにはコピーされないようです。

worksheet.Range(rowno + 2 + ":" + rowno + 3).CopyTo(worksheet.Range(rowno + 4 + ":" + rowno + 5));

お助けください

267 :デフォルトの名無しさん:2017/02/28(火) 21:34:46.83 ID:A2md68KB
2 + ":"
こういうの気持ち悪い

268 :デフォルトの名無しさん:2017/02/28(火) 21:59:17.96 ID:39alJvfi
>>259
StreamReaderをCloseしようね
内部的には同じだけどFile.ReadLines()を使ってElementAt()とかで目的の行が取れるよ

269 :デフォルトの名無しさん:2017/02/28(火) 22:08:38.41 ID:s47hQ+GZ
>>264
じゃ、お前んとこってテキストファイルの行数でデータ定義するの?

270 :デフォルトの名無しさん:2017/02/28(火) 22:11:57.45 ID:39alJvfi
ログファイルの1行目と2行目はヘッダーだからみたいな定義は十分ありえるだろ

271 :デフォルトの名無しさん:2017/02/28(火) 22:14:30.88 ID:pIiGTdLD
>>269
普通にID管理だけど、チートやバグが発生した場合に行数管理で正常か
どうか判断する局面も有るけど?

272 :デフォルトの名無しさん:2017/02/28(火) 22:24:32.74 ID:+WocOs48
>>269
測定データ1分1行で定義されてて、1日置き=1440行ごと読み出しとか、行数でのデータ取扱なんてざらだよ

273 :デフォルトの名無しさん:2017/02/28(火) 23:03:34.74 ID:s47hQ+GZ
>>272
面倒でも日時入れるわ
データがないとき(?)って空白出すの?
超面倒じゃん

データがないって判定もヤバそう

274 :デフォルトの名無しさん:2017/02/28(火) 23:10:22.11 ID:AHF/JWRt
>>268
ReadLinesは全部メモリに読むから、ファイルがでかい可能性があるなら避けたほうがよいかも

275 :デフォルトの名無しさん:2017/02/28(火) 23:12:03.23 ID:z/77EZzb
メインフレームのシーケンシャルファイル(固定長レコードのバイナリファイル)ですら件数で判断なんかやらねえわ
運用が面倒臭すぎる

276 :デフォルトの名無しさん:2017/02/28(火) 23:25:18.45 ID:39alJvfi
>>274
読まないよ
全部読むのはReadAllLines

277 :デフォルトの名無しさん:2017/03/01(水) 01:43:58.56 ID:jez9uqUV
自分もテキストでハマってるわ。
テキスト読み出しながら、登録したキーワードに引っかかったらreplaceする必要があるんだけど、(足りない脳味噌の範囲で)どうやってもクッソ遅い。
キーワードと置換後文字はDictionaryで管理してるけど、そもそもキーワードが8200程ある上に、テキストも1ファイルあたり平均約2.7万文字あってもう無理(テキストファイルは1日あたり1600ほど生産されてる)
速度は諦めるしかない?

278 :デフォルトの名無しさん:2017/03/01(水) 01:54:31.83 ID:XgpeB6sR
>>276
すまん、そうだった

279 :デフォルトの名無しさん:2017/03/01(水) 04:22:26.99 ID:uGJVx5D1
>>277
どのくらいで遅いって言ってるのか次第じゃない?
キーワードにマッチする単位で単語分割できてれば入力の単語単位で辞書にぶつけるのが効率よさそう
ただ3万文字程度ならキーワードの数だけ入力を走査しても言うほど時間かからない気がする

280 :デフォルトの名無しさん:2017/03/01(水) 07:58:17.12 ID:ElQ6OcG3
>>277
キーワードを予め文字単位でツリー化しておいて辿っていけば?
1文字読むたびに最大でもキーワードの最大文字数と同じ数だけのツリーのポインタを1歩進めるだけで済む

281 :デフォルトの名無しさん:2017/03/01(水) 08:04:58.33 ID:SJrJxNnQ
>>268
> StreamReaderをCloseしようね
そこは using だろ

282 :デフォルトの名無しさん:2017/03/01(水) 08:26:19.47 ID:mkeal5qn
トライ木か

283 :デフォルトの名無しさん:2017/03/01(水) 14:31:13.79 ID:UzmiTiRe
System.Net.CookieのDomainについてですが、RFC 6265の4.1.2.3が実現できないように思えます
Domainのスコープを設定するにはどうすればいいでしょうか?

284 :デフォルトの名無しさん:2017/03/01(水) 15:36:27.74 ID:yuocqMDO
キーワード「ねこ・こねこ」があるとき、「こねこ」はどちらに該当する?

また、キーワード「こね・ねこ」があるとき、どちらに該当する?

285 :デフォルトの名無しさん:2017/03/01(水) 17:28:21.57 ID:9PjUMtQQ
初心者質問すみません
フォームにボタンAとボタンBの二つのボタンがあります
ボタンAをクリックすると、ある反復処理が延々と繰り返されます
ボタンBをクリックしてこの反復処理をストップさせるには通常どのような記述をするのでしょうか

286 :デフォルトの名無しさん:2017/03/01(水) 17:33:43.62 ID:kRYqKFSr
>>285
反復処理の中に条件付き中断処理を入れる
もう一つのボタンを押したときに中断処理用のフラグをセットする
もちろん別スレッドじゃないとボタン押せないけど

287 :デフォルトの名無しさん:2017/03/01(水) 17:36:44.01 ID:kRYqKFSr
連レスごめん
反復処理中にApplication.DoEvents入れてもボタンの入力受けるけど
反応悪くなるし、今時はまず使わないだろうな

288 :デフォルトの名無しさん:2017/03/01(水) 19:13:43.54 ID:1ptPBH8r
>>285

CancellationTokenSource cancellationTokenSource;
async buttonA_Click()
{
this.cancellationTokenSource = new CancellationTokenSource();

while ( this.cancellationTokenSource.Token.IsCancellationRequested )
{
await Task.Run( () =>
{
// 何か
}, this.cancellationTokenSource.Token );
}
}

private void buttonB_Click()
{
this.cancellationTokenSource.Cancel();
}

289 :デフォルトの名無しさん:2017/03/01(水) 19:21:54.77 ID:z3LIBqaM
>>279に一票。

290 :デフォルトの名無しさん:2017/03/01(水) 19:31:02.44 ID:CFmNTLsk
>>277
ソース上げたら誰かみてくれるよ

291 :デフォルトの名無しさん:2017/03/01(水) 19:53:57.57 ID:SJrJxNnQ
正規表現に 8,200個も連結して検索させたら死ぬかな?

292 :デフォルトの名無しさん:2017/03/01(水) 20:31:55.65 ID:r70GDLNP
>>291
not Defined

293 :デフォルトの名無しさん:2017/03/01(水) 21:37:40.58 ID:PGtJZLdC
C#から2chに書き込みたいんだけど、
「At2chLib」が使用できなくなってて困っています。
なにか良いライブラリとか有りますか?

294 :デフォルトの名無しさん:2017/03/01(水) 21:39:56.43 ID:PR7YLHWZ
HttpClient

295 :デフォルトの名無しさん:2017/03/01(水) 21:46:15.04 ID:RAuT14LS
荒らしツールは日本では違法だぞ。

296 :デフォルトの名無しさん:2017/03/01(水) 22:01:49.72 ID:r70GDLNP
いやぁ……海外でもダメだろ

297 :デフォルトの名無しさん:2017/03/01(水) 22:08:23.90 ID:PGtJZLdC
荒らしじゃなく、荒らし駆除的なの作りたいんだけどなー

298 :デフォルトの名無しさん:2017/03/01(水) 22:31:30.38 ID:78O8EuSm
荒らしに構う奴も荒らしだぞ

299 :デフォルトの名無しさん:2017/03/01(水) 22:38:28.52 ID:fB20izlq
>>295
違法だったら良いのにな…
もし違法だったらVIPで埋めまくってる奴逮捕されていなくなるはずなのにな…
はぁ…

300 :デフォルトの名無しさん:2017/03/01(水) 23:00:18.14 ID:U2Od4VRx
VIPなんぞ行かなくてよろしい

301 :デフォルトの名無しさん:2017/03/01(水) 23:13:49.83 ID:fB20izlq
ゲ雑…

302 :デフォルトの名無しさん:2017/03/01(水) 23:57:19.29 ID:6tJnN0su
>>287
1処理1個挟むんじゃなくて100処理か1000処理に1回ぐらいでお願いします

303 :デフォルトの名無しさん:2017/03/02(木) 00:33:44.50 ID:IBdXO0OO
>>277
どこが遅いか分析が足りてないな
キーワードにヒットしたら番地とヒットしたキーワード格納して置換はしないでみたら?
置換って頭使わないと最悪な方法で処理してくれてる気がする
abcを見つけたらdefghijkに変換してくれる処理って
c言語だったら変換後の配列のサイズの計算からしなきゃいけないわけで
それをc#ってreplaceしやがったら配列の再確保余裕でしたみたいなことするアホだろ
その辺は考慮に入ってる?

304 :デフォルトの名無しさん:2017/03/02(木) 00:54:02.49 ID:FuaoIGJx
やっとらおまえらも実装してはじめてMSのWordが糞遅い理由を理解してくれたか。

305 :デフォルトの名無しさん:2017/03/02(木) 00:54:51.19 ID:IBdXO0OO
ならば文字列をつなげていくかとして
str1 + str2
みたいなことするとこれも合体後の文字列の長さで配列を再確保する
3万文字もある文字列だと1回文字列連結をするだけでヤバイ
変換に使用するキーワードの使用回数から最終的な文字列の長さを算出する必要があるかも
ってそれも考慮済みだろうか?

306 :デフォルトの名無しさん:2017/03/02(木) 00:58:24.20 ID:FuaoIGJx
string使ってるという馬鹿なオチかよ。これだからC言語できない奴は。

307 :デフォルトの名無しさん:2017/03/02(木) 01:07:45.83 ID:B13E3oAw
アルゴリズムの問題。stringだろうと*だろうと同じだろ。これだから自称C使いは・・・

308 :デフォルトの名無しさん:2017/03/02(木) 01:09:29.82 ID:FuaoIGJx
アホに世界常識を教えてやる。

stringは糞遅い。

だからMSは最初から別のクラスを用意してる。ググレカスども。

309 :デフォルトの名無しさん:2017/03/02(木) 01:14:29.76 ID:oXaAut0o
ボディービルダーになれば良いらしいのか

310 :デフォルトの名無しさん:2017/03/02(木) 01:18:09.17 ID:iFkNWUjs
興味があるならどうぞ StringBuilderのReplace
https://referencesource.microsoft.com/#mscorlib/system/text/stringbuilder.cs,1485
https://referencesource.microsoft.com/#mscorlib/system/text/stringbuilder.cs,1535

311 :デフォルトの名無しさん:2017/03/02(木) 01:20:26.39 ID:iFkNWUjs
>>308
Replaceのパフォーマンスはそんな変わらないよ
ググレカス

312 :デフォルトの名無しさん:2017/03/02(木) 01:22:58.33 ID:o9lMs6ta
ここはWinFormsだし、10年前のインターネッツだな。

313 :デフォルトの名無しさん:2017/03/02(木) 01:23:22.99 ID:FuaoIGJx
おれがコード書けば瞬殺レベルの高速化できる案件。

最後のヒントな。

大山札

314 :デフォルトの名無しさん:2017/03/02(木) 02:04:51.98 ID:ggH8M0CB
>>313
もしかしてあらかじめ領域を準備して,自分で足していく,とか‥

315 :デフォルトの名無しさん:2017/03/02(木) 02:30:07.47 ID:4HioNM+3
>>299
違法と犯罪は違うぞ

316 :デフォルトの名無しさん:2017/03/02(木) 02:41:55.30 ID:iFkNWUjs
>>313
>>280

317 :デフォルトの名無しさん:2017/03/02(木) 06:45:07.41 ID:JZiPjSZc
言語だのStringBuilderだのという小手先のテクニックの問題ではないだろ
>>280のアルゴリズムで実装したら100倍とかのオーダーで速くなるはず

318 :デフォルトの名無しさん:2017/03/02(木) 07:40:36.76 ID:WqhQkxL/
口だけならなんとでも言える
実装して計測してコードと計測結果を晒してから主張して

319 :デフォルトの名無しさん:2017/03/02(木) 07:52:06.73 ID:Ct6l/xwh
>>317
280は検索で遅いとき
置換で遅いときはstringbuilderをキッチリサイズ指定する方法でやらないとダメ

まず切り分けかな?

320 :デフォルトの名無しさん:2017/03/02(木) 08:49:47.79 ID:oX3M/pPf
検索が8,200あるのに、マッチするのはそのうち1つ有るかどうかなんだから
圧倒的に検索の問題になるだろうね

普通は

321 :デフォルトの名無しさん:2017/03/02(木) 09:05:00.59 ID:Ct6l/xwh
>>320
いや3万文字を置換のたびに1回1回stringのreplaceしてたらその度に3万文字分の配列を再確保
これが致命的
stringのreplaceはやってはならない
stringbuilderで
これも使い方悪いと速度出ないので正しい感じで

322 :デフォルトの名無しさん:2017/03/02(木) 09:06:59.45 ID:Ct6l/xwh
キーワードの検索の方はdictionary使ってるって言うし十分早いんじゃないかと予想

323 :デフォルトの名無しさん:2017/03/02(木) 09:07:18.82 ID:cjA1b3op
ツリーポインタに文字列中の開始インデックスをセットで持たせておいて、
終端ノードまで来たら開始インデックスから後を削除し、終端ノードに持たせてある置換文字列を付加し、現在のツリーポインタを全て破棄
こうすれば280で置換も効率的にやれるよ

324 :デフォルトの名無しさん:2017/03/02(木) 09:17:20.56 ID:cjA1b3op
>>321
それ文字列が長ければreplaceのための線形探索がネックになるはずで、StringBuilderは直接関係ないでしょ
簡単に効率を改善するんなら、全キーワードのうち最長のキーワードの文字数と同じサイズのバッファを持っといて
そこに対して置換をかけりゃいい
もちろんその置換結果を最終出力の文字列として連結していくところはStringBuilderを使うべきだけど

325 :デフォルトの名無しさん:2017/03/02(木) 10:02:53.43 ID:xcfTeAxl
問題は用途が不明だから、仕様が決まらない
に限定されると思ふ ノ ヽ(・ω・)/ズコー

326 :デフォルトの名無しさん:2017/03/02(木) 12:13:19.52 ID:63yIksCz
いいからコード書いて結果出そうぜ

327 :デフォルトの名無しさん:2017/03/02(木) 13:30:45.83 ID:NvG2Ox0H
ある程度の個数だとキーワードを全部つなげた正規表現を作るのが定石っぽいけど、
一万近いとどうなんだろうか

328 :デフォルトの名無しさん:2017/03/02(木) 13:39:24.58 ID:Ct6l/xwh
>>324
置換後に短くなっても駄目っぽいけどね

329 :デフォルトの名無しさん:2017/03/02(木) 13:42:21.47 ID:j0RdOmJS
8200のうちマッチが1つあるかどうかなのか、マッチがたくさんあるのか
で方法変えた方がいいな

330 :デフォルトの名無しさん:2017/03/02(木) 16:45:48.51 ID:yzi1qiN6
>>277
そんな変な処理をしなければいいだろ。
解決!

331 :デフォルトの名無しさん:2017/03/02(木) 19:36:05.41 ID:tOCPWbBv
こういうアルゴリズムのボトルネックってどうやって探すんだ?

332 :デフォルトの名無しさん:2017/03/02(木) 19:43:30.86 ID:j0RdOmJS
アルゴリズムのというか、処理のボトルネックはパフォーマンスプロファイルで出る

333 :デフォルトの名無しさん:2017/03/02(木) 19:47:35.64 ID:eNjjKtZ0
味見すりゃ分かるだろ。
それ以前にベタにやっても余裕だと思うが。

334 :デフォルトの名無しさん:2017/03/02(木) 19:54:31.82 ID:Ct6l/xwh
>>331
プロファイラ使えるようになるのが一番いいね
ただ、それじゃわかりにくいときもあるから知恵をつけるのも大事だと思う

335 :デフォルトの名無しさん:2017/03/02(木) 20:14:46.47 ID:eNjjKtZ0
ちなみに今回のはプロファイラでは分からんぞ。
例えばString.Replaceと出て終わり。
https://msdn.microsoft.com/ja-jp/library/ms182372.aspx
https://msdn.microsoft.com/ja-jp/library/fk49wtc1(v=vs.110).aspx
その先の解像度は一般的に無いでしょ。(俺はC#のプロファイラを使ったことは無い)
だからここでやってるみたいにCLR内の動作を考える必要がある。

336 :デフォルトの名無しさん:2017/03/02(木) 20:23:23.74 ID:j0RdOmJS
>>335
それはプロファイラの考え方を間違ってる(使ってないみたいだから知らないのは当然かもしれんが)
replaceがネックって出ればそれでいいんだよ

337 :デフォルトの名無しさん:2017/03/02(木) 20:34:59.52 ID:Ct6l/xwh
>>336
そうだね
さらにgoogleで

replace 遅い c#

なんてキーワードで検索かければもう解決方法も見つかったようなもんだね

338 :デフォルトの名無しさん:2017/03/02(木) 20:42:38.33 ID:eNjjKtZ0
>>336
いや俺は他言語(JavaScript)ではプロファイラ使いまくりだぞ。
そしてプロファイラ自体は見た目ほぼ同じだし。当たり前だが。
というか今回は20行程度のプログラムで2重ループするだけだろ。
ベタでやった場合、String.Replaceが出るに決まってるだろ。
お前はアホの子か?

問題はそれをどう変えたらどう改善されるかの見通しを立てることだろ。
それはここでみんながやってるように、自分で考えないと分からない。
とはいえここで案を出してもらってるんだし、後はがんばれでしかないが。

339 :デフォルトの名無しさん:2017/03/02(木) 20:44:03.61 ID:maE+uJIv
>>338
馬鹿は一生js書いてろ
くせえから出歩くなクソが

340 :デフォルトの名無しさん:2017/03/02(木) 20:49:46.45 ID:rlmCwDYA
javascriptのプロファイリングは大切だからねえ
品質の悪いライブラリと品質の悪い人材によって書かれているから
すぐsucks so muchになるんだ

341 :デフォルトの名無しさん:2017/03/02(木) 21:44:03.77 ID:eNjjKtZ0
>>340
いやJavaScriptはJITがエグイからでしょ。(同じ傾向はC#にもあるはずだが)
例えばHTMLの特殊文字を変更する場合、string.replace(Regex,func)で纏めるよりも、
数個なら string.replace().replace().replace() とかハードコードした方が速かったりする。
ボトルネックがソースから予測しづらいからプロファイラを使うしかない。
その点、Cは最初から見えた状態で書くからいい。

ただこのあっさり感、C#ならString, StringBuilder, Regexで試して、
それ以上は諦める文化なのかもしれんね。そういう用途の言語ではあるし。
C的アプローチで限界速度を追求するのではなくてね。

342 :デフォルトの名無しさん:2017/03/03(金) 07:07:46.01 ID:GM13pkfI
やっぱここで質問したのが間違いでした
ろくな解決策が出ないので
もう結構です

343 :デフォルトの名無しさん:2017/03/03(金) 07:16:35.43 ID:cZXazyZL
なあ、、、

文字列探索アルゴリズムの問題だと思うのは俺だけかな?

そこを自前で実装すれば高速化できると思うのだけど

344 :デフォルトの名無しさん:2017/03/03(金) 07:22:10.27 ID:4qcBtzlj
>>343
それは>>280で出てる

345 :デフォルトの名無しさん:2017/03/03(金) 07:22:40.42 ID:cZXazyZL
http://developer.hatenastaff.com/entry/2016/12/22/210006

置き換え後、どこに格納するかはたいして重要じゃないはず。

状況に応じた探索アルゴリズムを使用することが重要。

自前実装は辛いけど。

346 :デフォルトの名無しさん:2017/03/03(金) 07:31:45.18 ID:ELiKOyhw
誰か>>280を実装してみてよ

347 :デフォルトの名無しさん:2017/03/03(金) 07:34:13.74 ID:4qcBtzlj
>>345
その「状況」は単純に探索をどうするかだけではないよ
置換処理に適したアルゴリズムを使用することが重要
その意味ではトライ木を使った方法(280)はリアルタイムで読んだそばから置換できるから目的に合ってる

348 :デフォルトの名無しさん:2017/03/03(金) 07:50:58.21 ID:pVtcQ1mY
そもそも何が目的なのか説明しろよ

349 :デフォルトの名無しさん:2017/03/03(金) 07:54:40.78 ID:a7lwSDS4
アフィ目的って気づけよバカども

350 :デフォルトの名無しさん:2017/03/03(金) 07:56:17.33 ID:pVtcQ1mY
アフィって何よ?

351 :デフォルトの名無しさん:2017/03/03(金) 08:06:18.44 ID:hxiWJWmX
>>347
検索された文字列から変換後の文字列を求める手間の話?
8,200個くらいならたいしたことないと思う

352 :デフォルトの名無しさん:2017/03/03(金) 08:19:11.00 ID:ELiKOyhw
誰も実装できないの?

353 :デフォルトの名無しさん:2017/03/03(金) 08:30:26.60 ID:LqKyLlg1
>>352
できるのわかってるし
正直、対象の文字列に対してdictionaryでまとめてある群からヒットさせるならそこまで変わらないと俺は思ってるので興味ない
さらに話題提供者は明確な仕様を出したわけではないので現状では「組めない」が正解
さらにこの問題は対象のデータの持ち方で解決する方法もあって多くの場合そっちのほうが楽なので
あまりこのスレで出たような解決方法を適用することは無いかも

354 :デフォルトの名無しさん:2017/03/03(金) 08:56:05.96 ID:LqKyLlg1
例えば対象の文字列がソースコードのように人間の目視できる文字数で改行が必ず入り、
キーワードが改行を含まないのであれば
行ごとにreplace処理して文字列の統合だけstringbuilderを使えばこれだけで十分な速度が出ると思われる
(1行300文字程度と想定)
とかね
僕のカコイイスペシャルエディタでも作らない限りはフォーマット自体に特有の癖があるもんで
大抵の場合は独自の解決方法を考えたほうが早い

355 :デフォルトの名無しさん:2017/03/03(金) 09:35:42.12 ID:velk9AIH
テキスト読み出しながらって書いてあるからすでに行単位でやってると思うが

356 :デフォルトの名無しさん:2017/03/03(金) 13:45:46.60 ID:hf3TFoOq
>>346
UNIXのShellのコマンド解析の実装がそんな感じ。
ただしスイッチ文の嵐だが(一文字目がCならCPを検査とか・・・

357 :デフォルトの名無しさん:2017/03/03(金) 15:59:24.43 ID:GTe30Tvn
あーアフィかぁ 超納得
1ファイルの文字数がやたら少ないし何の目的か全くわからんかった

>>346,352がアフィ本人だね

358 :デフォルトの名無しさん:2017/03/03(金) 16:00:23.77 ID:GTe30Tvn
間違えた
>>342,346,352がアフィ本人

359 :デフォルトの名無しさん:2017/03/03(金) 16:00:55.70 ID:oAXP4RlZ
>>352
アホの子なの?

360 :デフォルトの名無しさん:2017/03/03(金) 16:02:40.13 ID:nP8cPyWm
IT速報かな?

361 :デフォルトの名無しさん:2017/03/03(金) 16:54:07.87 ID:Loi48FLt
>>352こう煽ると情報出て来ること多いからな。いい手w

362 :デフォルトの名無しさん:2017/03/03(金) 17:00:38.87 ID:nP8cPyWm
C#で自動コメント投稿スクリプト作ってIT速報荒らすンゴwwwwwwwwwwww

363 :デフォルトの名無しさん:2017/03/03(金) 19:35:06.90 ID:MASUg06L
まーたカニンガムの法則を証明してしまったのか

364 :デフォルトの名無しさん:2017/03/04(土) 00:57:57.14 ID:V1fO2YUM
>>352
馬鹿かこいつ。

365 :デフォルトの名無しさん:2017/03/06(月) 15:15:15.66 ID:c2C1QaOD
俺に実装出来ないものなどない

実装しないだけだ(´・ω・`)

366 :デフォルトの名無しさん:2017/03/06(月) 16:53:48.94 ID:HdaZCaDT
うっせ!消えろ!
(´・ω・`).Dispose();

367 :デフォルトの名無しさん:2017/03/06(月) 17:04:44.11 ID:gswSb9xJ
void Dispose(){
  throw new GenjyuminException("お兄ちゃん僕を消さないで");
}

368 :デフォルトの名無しさん:2017/03/06(月) 18:04:17.43 ID:fLI2L2/v
while(true){
if((´・ω・`)==null)break;
}
これでどや、消えるまで永久に彷徨え

369 :デフォルトの名無しさん:2017/03/06(月) 18:06:58.06 ID:SM9wIIjZ
int (´・ω・`) = 0;
こういうのエラーになっちゃうんだけど、ならないのあるかな

370 :デフォルトの名無しさん:2017/03/06(月) 18:10:04.79 ID:gswSb9xJ
>>369
とうふさんをすころう🙋

371 :デフォルトの名無しさん:2017/03/08(水) 07:21:50.44 ID:0djAud0F
ASP.NETでEntityFrameWorkを
使い始めてデータエンティティの設計を
意識するようになったのですが
論理ER図とクラス図がほとんど同じ
ようなエンティティになるのは
良いのでしょうか?

使ってる言語がC#なだけで
OOPの話になっているみたいで
恐縮ですが

372 :デフォルトの名無しさん:2017/03/08(水) 07:57:43.96 ID:j5hWWAog
>>371
オブジェクト指向原理主義的に言うなら、最初にデータ設計ありきで作ったのが間違い
DB構造はオブジェクトを抽出した上でその永続化層として結果的に導出されるもの
その結果、テーブル構成がクラスと一対一になるのはおかしくはない

373 :デフォルトの名無しさん:2017/03/08(水) 09:10:06.96 ID:4zQ1zZR+
>>371
>論理ER図とクラス図がほとんど同じ
>ようなエンティティになるのは
それをEFと言うんじゃないか?
殆ど同じじゃなく完全一致するんじゃないの?

374 :デフォルトの名無しさん:2017/03/08(水) 11:04:45.08 ID:WDLIW5bb
処理文より定形文の方が多くなる問題

皆さんはどうやって解決してますか?

375 :デフォルトの名無しさん:2017/03/08(水) 11:21:49.05 ID:j5hWWAog
>>374
メソッドやクラスを適切に使って使い回せばそんなことにはならない

376 :デフォルトの名無しさん:2017/03/08(水) 12:38:38.92 ID:xVFA2xmi
>>375
適切とは?

377 :デフォルトの名無しさん:2017/03/08(水) 12:46:41.42 ID:FTYppI6w
>>376
例えばこうしろってだけでしょ
method(0); method(1); method(2); method(3);・・・method(x);

for (int i =0; i <= x; i++) method(i);

ただいくらそうしたって作るものによっては定形だらけになるからな。そんなの気にするなとしか言えん

378 :デフォルトの名無しさん:2017/03/08(水) 13:31:44.38 ID:WDLIW5bb
>>377
それに、クラスとリターン、ラベル貼るから一行より長くなるんです

379 :デフォルトの名無しさん:2017/03/08(水) 14:05:18.27 ID:pm5pCz2z
>>373
EDM理解してる?

380 :デフォルトの名無しさん:2017/03/08(水) 14:35:54.93 ID:jFDZ8cwh
絵が描けなくても無料・有料とわず素材なんて腐るほどいっぱいあるんだから
リアルでカードゲームやボードゲーム作ってゲームマーケットで売ろう

個人利用、商用利用も可の198,381 個の無料ベクター画像
http://jp.freepik.com/popular-vectors
オシャレ感をプラスできる手書きのアイコン50選
http://blog.nest-online.jp/27240
無料素材:ヴィンテージ感がおしゃれ!デザインソフトのツールアイコン49個セット
http://switch-box.net/free-resources-vintage-design-icons.html
無料素材:魔法陣の文様が描けるユニークな英語フリーフォント「MagicRing」
http://switch-box.net/free-font-magic-ring.html
ねくらファンタジーマップチップ素材集
http://piposozai.blog76.fc2.com/blog-entry-500.html
ひぽやマップチップ
http://piposozai.blog76.fc2.com/blog-entry-485.html
クオリティの高いゲーム用のモンスター素材画像が手に入るフリー素材サイト5つ
https://agency-star.com/freelance/articles/117/
ファンタジー世界地図を簡単に作れる「Inkarnate Worlds」をゲーム制作に活用しよう
http://www.moguragames.com/entry/inkarnate-worlds-indiegame-dev/
QRコード・クトゥルフ神話・24世紀などユニークすぎるデザインてんこ盛りのサイコロ「Dice Empire」レビュー
http://gigazine.net/news/20150313-dice-empire/
駆け出し奮闘記「ゲームチップ・他小物類の作り方」
http://yuofc2.blog72.fc2.com/blog-entry-233.html

381 :デフォルトの名無しさん:2017/03/08(水) 16:48:47.00 ID:EwGirieA
c#初心者なんですが
https://www.ibm.com/developerworks/jp/linux/library/l-mono/
>実際、作成された実行可能ファイルを別のシステム、おそらくWindowsが稼動しているシステムにコピーして、そこでそのまま実行することができます。
Linuxで動くexeファイルがwindowsでもそのまま動くのはなぜですか?
本来、実行可能形式に互換性はありませんよね?
Javaだと.jarファイルでjavaが関連付けられてるからどこでも動作するというのは分かるんですが

382 :デフォルトの名無しさん:2017/03/08(水) 17:05:53.57 ID:FTYppI6w
>>381
javascripはテキストファイルなのに実行できるってのと同じで、exeという拡張子だけど中身はスクリプトって考えりゃいい
linux側は「mono example.exe」のように実行するのはexeでなくmonoでしょ

383 :デフォルトの名無しさん:2017/03/08(水) 17:10:53.01 ID:CceDL3fb
>>381
Linuxはexeが実行ファイルという訳でもなし、mcsがPE互換でも吐いてるんじゃない?
C#はそもそも中間言語にコンパイルされるし、.NET Framework(あるいは互換ランタイム)を通して
色々な操作を行うので、DllImportとか除けばコード部分はプラットフォーム依存にはならない、Javaと一緒

384 :デフォルトの名無しさん:2017/03/08(水) 17:41:17.11 ID:4q4g4kgy
>>373
やはりそう思いますよね

自分もデータエンティティと
クラス図が一致してしまって
アンチパターンしてないか
不安になったもので

クラス図要らないじゃん
てことになって良いのかなと

385 :デフォルトの名無しさん:2017/03/08(水) 17:56:23.47 ID:EwGirieA
>>382
わかりました
linuxでもx window systemとかGUIシステムで
拡張子とプログラムの関連付けがあるみたいだけど
.exeをmonoに関連付けるのは少し疑問です
.jarみたいな固有拡張子じゃないので
windowsだと関連付け関係無く実行可能形式として動くんだろうけど
他のOSでは特定のプログラムから起動しなければならないというのが
非対称的でクロスプラットフォーム感欠けてるような気がします

386 :デフォルトの名無しさん:2017/03/08(水) 18:12:34.14 ID:ZazPDLJU
Windowsでもexeの中にあるMSILを
特定のプログラムでコンパイルしないと動かないぞ

387 :デフォルトの名無しさん:2017/03/08(水) 18:13:37.64 ID:NpQQdkRq
>>385
クロスプラットフォームにこだわるのならC#使わない方がいいだろ
>>383に書いてあるようにDllImportとか入っていたらどうしようもないんだから

388 :デフォルトの名無しさん:2017/03/08(水) 20:03:39.84 ID:VZtOnmtc
EF使いたいけど仕事での開発は腐りきったDBと手続き型の権力者が支配しててうまくいかないよ
ビジネスロジックはほとんどSQLとストアドに書かれ
ホスト言語はデータセットをUIとバインドするだけ
マイクロソフトは業界の現実を見据えたフレームワークを提供してほしい

389 :デフォルトの名無しさん:2017/03/08(水) 20:08:18.13 ID:jS0zQn/F
ジャップローカルな業界標準なんか基準にしても仕方ねーだろ

390 :デフォルトの名無しさん:2017/03/08(水) 20:25:11.68 ID:q0ZuMA54
今後は品質を上げるためにC#やめてJavaにするってさ
品質を上げるために

誰だよJavaオワコンとか言ってたの
Javaつよすぎんだろ

391 :デフォルトの名無しさん:2017/03/08(水) 20:37:42.27 ID:WDLIW5bb
新しく、C++,C#,Javaを超える言語の誕生を切に願う

392 :デフォルトの名無しさん:2017/03/08(水) 20:43:44.50 ID:YCUi9zWw
>>390
実際Javaは周辺技術はすごい
世界中の叡智が結集して糞を料理し、なんとか食えるものにしてる

393 :デフォルトの名無しさん:2017/03/08(水) 20:50:23.47 ID:YUr8l1RF
Java人にとってWindowsは周辺ではなく僻地です。

394 :デフォルトの名無しさん:2017/03/08(水) 21:09:03.23 ID:psTqZ+Sc
なんか中国人みたいだな

395 :デフォルトの名無しさん:2017/03/08(水) 21:32:29.32 ID:U5noIHdN
javaはoracleの時点で将来どうなるか判らないって不安がつきまとう
golangもgoogleだから不安がつきまとう
swiftもappleだから数年後の未来も予測出来ない

でも不思議とc#とmsの場合はあんまそういう不安が無い

396 :デフォルトの名無しさん:2017/03/08(水) 21:39:55.81 ID:Uljnsbub
>>388
>ビジネスロジックはほとんどSQLとストアドに書かれ
最適化のためにしかたなくストアド化することはあっても
ビジネスロジックまるごととかあるんだね
おいたわしゅう

397 :デフォルトの名無しさん:2017/03/08(水) 21:49:14.72 ID:YUr8l1RF
Javaが糞遅いからC#じゃないのか。
Javaと同じ設計をしたいならJavaを使えばいい。

398 :デフォルトの名無しさん:2017/03/08(水) 21:51:54.89 ID:MEKWLPl8
Windowsで趣味で遊ぶのにC#より楽な言語が無い

399 :デフォルトの名無しさん:2017/03/08(水) 22:28:25.34 ID:gllfe4Ss
みんな仕方なくうんこなJava使ってるだけだから。
大人の事情。

400 :デフォルトの名無しさん:2017/03/08(水) 23:15:48.59 ID:nWki5I6G
>>397
いやJavaが使われるような分野ならJava(やその周辺のライブラリ類)は糞速い
クライアントじゃビチグソだが

401 :デフォルトの名無しさん:2017/03/08(水) 23:21:37.62 ID:YUr8l1RF
高速ライブラリはすべてC++とアセンブラで書かれてます。

402 :デフォルトの名無しさん:2017/03/08(水) 23:31:16.51 ID:RgWWdtUJ
結果的には現実的な判断だったと思うよ。
OracleにはJavaを伸ばすほどの能力はない。
環境の互換性に固執した結果、エコシステムがブラッシュアップされたのならそれでOK。
あとはC#で実験済みの便利機能を順に採り入れていけばいい。

C#がJavaに滅ぼされない為には数歩先を走り続けるしかない。
そのうちにJavaと同レベルのエコシステムが揃えられればJavaを食えるかもしれないが、
これはかなり厳しいとは思う。

403 :デフォルトの名無しさん:2017/03/09(木) 00:10:57.40 ID:x6aOWZGA
Javaのエコシステム!?
今Javaの一番メジャーなパッケージマネージャって何?

rubygemsやnpmみたいなのないって聞いたら
Mavenでpom.xmlって言われて愕然としたことがある

404 :デフォルトの名無しさん:2017/03/09(木) 00:43:02.76 ID:zrZoqbyp
>>403
Mavenで用は足りるし、LLっぽいのがお好みならGradleも人気

405 :デフォルトの名無しさん:2017/03/09(木) 07:33:43.82 ID:i1kRuTOP
>>388
EFって何がいいの?
そんなの使わなくてもsql実行すればいいんじゃないの?

406 :デフォルトの名無しさん:2017/03/09(木) 19:18:10.50 ID:NWFSmelL
>>405
ORMでググれ

407 :デフォルトの名無しさん:2017/03/09(木) 19:27:05.21 ID:kp/XS3en
operational risk management
業務運営リスク管理

sqlを文字ではなくオペレーションとして記述できるからsqlコマンド記述ミスによるバグやsqlインジェクションに強くなり
リスク回避に繋がるソース運営や管理ができる

408 :デフォルトの名無しさん:2017/03/09(木) 19:28:46.08 ID:ekX4ZlFq
C言語って何がいいの?
そんなの使わなくてもアセンブラ使えばいいんじゃないの?

35年前の会話

409 :デフォルトの名無しさん:2017/03/09(木) 19:38:38.06 ID:6OW1VF+t
ただまあ、便利な道具も、出来の良し悪しというのがあって

410 :デフォルトの名無しさん:2017/03/09(木) 19:39:54.78 ID:NWFSmelL
>>409
使う側の頭の良し悪しってことかな

411 :デフォルトの名無しさん:2017/03/09(木) 19:43:58.45 ID:6OW1VF+t
そう、EFはあまり出来は良くない

412 :デフォルトの名無しさん:2017/03/09(木) 19:45:09.07 ID:NWFSmelL
>>411
具体的に

413 :デフォルトの名無しさん:2017/03/09(木) 20:12:05.29 ID:J4siqdXV
クエリビルダとかコードファーストは要らないかな
まっさらなDB扱う機会なんてそうそうないし

414 :デフォルトの名無しさん:2017/03/09(木) 21:56:54.03 ID:i1kRuTOP
>>407
sql記述ミスしなければいいだろ。

415 :デフォルトの名無しさん:2017/03/09(木) 22:09:20.08 ID:ZZ1gzprq
>>413
既存DBからのコードファースト

416 :デフォルトの名無しさん:2017/03/09(木) 22:09:48.58 ID:GqwkUUnW
>>414
ばーか

417 :デフォルトの名無しさん:2017/03/09(木) 22:25:30.67 ID:FW6HepzM
>>414
そんな根性論・精神論的なものでミスは無くならないよ

418 :デフォルトの名無しさん:2017/03/09(木) 22:38:08.68 ID:i1kRuTOP
>>417
プログラムのミスを無くすのも
sqlのミスを無くすのも同じだろ。

419 :デフォルトの名無しさん:2017/03/09(木) 22:45:19.50 ID:mybEc7J1
SQLじゃ静的チェックが効かないし、列名とメンバ名のマッピング作業でミスを生じやすい

420 :デフォルトの名無しさん:2017/03/09(木) 23:05:42.43 ID:ZZ1gzprq
EntityFramework以前の問題だなこいつ

421 :デフォルトの名無しさん:2017/03/09(木) 23:06:17.34 ID:ojqe9dcn
>>411
具体的に

422 :デフォルトの名無しさん:2017/03/09(木) 23:10:24.76 ID:4hz9mkjX
おそい
かたい
つかいづらい

423 :デフォルトの名無しさん:2017/03/09(木) 23:15:15.25 ID:ZZ1gzprq
>>422
おそい→単純に速さを求めるならDapper使えば?EFは速さが目的のORMじゃないし
かたい→意味不明
つかいづらい→馬鹿ならプログラミング諦めれば?

424 :デフォルトの名無しさん:2017/03/09(木) 23:15:20.88 ID:i1kRuTOP
>>422
確かに遅いよね

425 :デフォルトの名無しさん:2017/03/09(木) 23:15:56.47 ID:OsFG/gY3
>>422
日本語でよろしく

426 :デフォルトの名無しさん:2017/03/09(木) 23:16:37.66 ID:OsFG/gY3
>>424
うん、当たり前だよね

427 :デフォルトの名無しさん:2017/03/09(木) 23:36:02.15 ID:4hz9mkjX
>>423
→おそい
昨今なにが速度のボトルネックってDBアクセスなのにおそくていいわけがない

→かたい
なんというか、型が固いんだ…
データいっぱい取ってきてもダックタイピングとかないからいちいち入れ替えなきゃいけないし
メソッドをまたいでデータをやり取りしづらい

→つかいづらい
変な落とし穴いっぱい
あと抽象化しすぎ
DBと通信するタイミングとかこっちの好きにしたい


よさそうだった
よさそうだったんだ…
ちょっと触った最初の一瞬は夢が見れたが

428 :デフォルトの名無しさん:2017/03/09(木) 23:39:24.67 ID:P0KhFIxP
>>427
お前C#向いてないからやめとけ

429 :デフォルトの名無しさん:2017/03/09(木) 23:40:17.24 ID:4hz9mkjX
なんでよ

430 :デフォルトの名無しさん:2017/03/09(木) 23:45:18.70 ID:ZZ1gzprq
>>427
生のADO.NETと比較すると遅くても、実運用に耐えられる程度なら問題ない
遅さのデメリットをメリットが上回る場合に採用すべき

設計ミス

お前の頭が足りてないだけ
抽象化しないとInMemoryやFakeのIDbcontext使ってUnit Testできない

431 :デフォルトの名無しさん:2017/03/10(金) 00:07:57.78 ID:Kg4/WRpJ
>>430
Dapperのところ見ると10倍以上遅いって数字弾いているし
体感上も遅いだろ
https://github.com/StackExchange/Dapper

432 :デフォルトの名無しさん:2017/03/10(金) 00:14:08.74 ID:cBCq3F3F
>>431
日本語

433 :デフォルトの名無しさん:2017/03/10(金) 00:15:07.75 ID:PorFrx4J
>>431
遅いのは皆わかってるんだけど
何言ってんのこいつ

434 :デフォルトの名無しさん:2017/03/10(金) 00:29:46.92 ID:cBCq3F3F
>>431
そのEntityFramework、3世代前くらいじゃね?

こっちの方がまともに比較してる気がする
https://msdn.microsoft.com/ja-jp/magazine/mt703432.aspx

435 :デフォルトの名無しさん:2017/03/10(金) 00:35:01.00 ID:PorFrx4J
誇大広告ワロタ

436 :デフォルトの名無しさん:2017/03/10(金) 00:47:22.95 ID:Cysk3AQ/
>>431
Dapperを使ってメモリ上でUnit Testやる方法教えて

437 :デフォルトの名無しさん:2017/03/10(金) 01:56:20.00 ID:YvYLhW/g
割といままで関わったプロジェクトは、敢えてスドアドで疎結合にしてるの多かったな。

438 :デフォルトの名無しさん:2017/03/10(金) 05:22:26.01 ID:hxjDKO5o
以下のページを参考にしてい
指定したURLからHTMLを取得するプログラムを作成しております
http://www.kekyo.net/2016/12/06/6186

取得する処理を作成することは出来たのですが
取得処理を走らせてからリクエストが帰ってくるまでの間
GUIの操作が一瞬とまってしまう現象が発生しております(一瞬フリーズするような感じです)
ですので連続してhtmlを取得したり、サイズの大きなものを取得する場合
長時間フリーズしてしまうことになるので大変困っております

どなたか解決方法をご存知の方がおりましたら
教えていただければ幸いです
よろしくお願いします

439 :デフォルトの名無しさん:2017/03/10(金) 05:22:50.13 ID:hxjDKO5o
ちなみに参考にしたソースは以下の通りです。

public static async Task<string> ReadFromUrlAsync(Uri url)
{
using (WebClient webClient = new WebClient())
{
using (Stream stream = await webClient.OpenReadTaskAsync(url))
{
TextReader tr = new StreamReader(stream, Encoding.UTF8, true);
string body = await tr.ReadToEndAsync();
return body;
}
}
}

public static async Task DownloadAsync()
{
Uri url = new Uri("https://github.com/Microsoft/dotnet/blob/master/README.md");
string body = await ReadFromUrlAsync(url);
Console.WriteLine(body);
}

440 :デフォルトの名無しさん:2017/03/10(金) 07:53:36.33 ID:/HdMhfmB
>>437
ストアドはビジネスとデータが密着して全く疎にならないだろ

441 :デフォルトの名無しさん:2017/03/10(金) 07:55:23.13 ID:LDoDwujD
>>437
かわいそうに

442 :デフォルトの名無しさん:2017/03/10(金) 07:56:43.00 ID:CZUjNxSc
普通シングルスレッドでは、処理中は、

進捗状況を表示するプログレスバーでも、描画が止まるから、
GUI/worker用のスレッドは、別々のマルチスレッドにする

プログレスバー描画のサンプルでも見れば?

443 :デフォルトの名無しさん:2017/03/10(金) 09:46:49.61 ID:ccNaYHW5
>>437
そのうちいいことあるよ、頑張って

444 :デフォルトの名無しさん:2017/03/10(金) 11:25:04.92 ID:LzpSY1Zb
>>438
WebClient(とその中で使ってるHttpWebRequest)が
名前解決部分を非同期化できてないっぽい

HttpClientを使おう

445 :デフォルトの名無しさん:2017/03/10(金) 12:24:52.88 ID:/STnO1DK
え?みんなEF使わないがデフォなの?

446 :デフォルトの名無しさん:2017/03/10(金) 12:26:08.18 ID:Tes7zBzn
あんなものを使うのはお勉強ができるだけの無能だけ

447 :デフォルトの名無しさん:2017/03/10(金) 12:36:20.43 ID:wvkqDHaL
>>445
使わないじゃなくて使えないんじゃない?新しいことを学習できないんだよ

448 :デフォルトの名無しさん:2017/03/10(金) 12:46:27.34 ID:Tes7zBzn
新しいものに飛びついてもあとであれはゴミだったというものもたくさんある
EJB2.0とか

449 :デフォルトの名無しさん:2017/03/10(金) 12:51:59.29 ID:wvkqDHaL
>>448
それはその通りだね
EntityFrameworkはもうそろそろ10年たつんだけど

450 :デフォルトの名無しさん:2017/03/10(金) 13:10:03.19 ID:mpFYTheR
やっぱJavaなんやね

451 :デフォルトの名無しさん:2017/03/10(金) 13:53:22.42 ID:AGPJ29Rn
新しいのを使うのも、古いのを使い続けるのも、どっちも長所短所がある
同じ長所短所でも環境によって評価が変わるからどっちが絶対にいいってのはない
それ考慮してどっち使うって当たり前の選択ができない奴多すぎるんだよ

452 :デフォルトの名無しさん:2017/03/10(金) 15:40:00.20 ID:y8xCqliG
>>440
んなの書き方によるだろ

453 :デフォルトの名無しさん:2017/03/10(金) 18:15:05.97 ID:NraHDdZK
使って文句ないやつは使ってればいいのよ。

俺は使うのをやめた。理由を他人に説明する必要も、他人が納得する必要もない。

454 :デフォルトの名無しさん:2017/03/10(金) 18:36:12.55 ID:wvkqDHaL
>>453
使えるやつは使う、使えないやつは使わない

455 :デフォルトの名無しさん:2017/03/10(金) 18:42:37.52 ID:NraHDdZK
そういうこった。俺には使えない。

456 :デフォルトの名無しさん:2017/03/10(金) 18:43:15.86 ID:NraHDdZK
使わなきゃ、使いにくいとこも分かんないからな。

457 :デフォルトの名無しさん:2017/03/10(金) 18:46:25.98 ID:Gc8NaZGi
世の中はまだWinFormsだからな。
新しいものに対応できないジャパン。

458 :デフォルトの名無しさん:2017/03/10(金) 18:49:44.85 ID:YN/8CtFT
>>456
ADO.NET直書き?

459 :デフォルトの名無しさん:2017/03/10(金) 19:38:33.09 ID:jSwjVui3
>>457
Microsoftはバグ管理にExcel使ってるんだぞ
振り回されたらあかん

460 :デフォルトの名無しさん:2017/03/10(金) 19:44:07.45 ID:PPM6ZnbB
DotNet CoreでバッサリWebFormsとDataSet切り捨ててくれたから
日本もこれからはMVCとPOCOにシフトしていくだろうね(希望)

461 :デフォルトの名無しさん:2017/03/10(金) 20:10:01.97 ID:cBCq3F3F
>>445
基本的にはEntityFrameworkで、パフォーマンスほしいとこはDapper

462 :デフォルトの名無しさん:2017/03/10(金) 20:35:03.91 ID:BdCDiQus
dapperって何がいいの?

463 :デフォルトの名無しさん:2017/03/10(金) 20:40:29.72 ID:cBCq3F3F
>>462
上にもいろいろ比較出てるけど、とにかく速くて簡単
DBとオブジェクトの最低限のマッピングだけでいい場合はこれで十分

464 :デフォルトの名無しさん:2017/03/11(土) 09:49:08.82 ID:+LwMML+J
動的だけど滅多にソースが更新されないほとんど静的なページのキャッシュってどう扱えばいいんですか?
クライアントにキャッシュさせて更新があった時だけアクセスしてほしいです

465 :デフォルトの名無しさん:2017/03/11(土) 09:53:48.23 ID:h5T3JHpB
>>464
ブラウザーがやってくれるんじゃないか?

466 :デフォルトの名無しさん:2017/03/11(土) 13:46:01.01 ID:SoGUL2Zu
VisualStudio2017お試しで使ってるんだけれど
タプルとか求めていたものが有ったので使おうとしたら
ValueTupleのライブラリが標準で入らずNuGetにしか無いとか
まだ安定しない無いとか何かあるんだろうか・・・
凄い作りかけ感あるコンパイラに仕上がってるwww

使うべきか暫く様子見すべきか?

467 :デフォルトの名無しさん:2017/03/11(土) 13:50:47.46 ID:/3A6iA0R
Windowsのcsc.exeでコンパイル出来ないC#6.0も見送ってるならそうだな

468 :デフォルトの名無しさん:2017/03/11(土) 14:02:34.64 ID:SoGUL2Zu
タプルの利用はしばらく様子見にしとくか・・・何か怪しいし。
ローカル関数いいね、これやる時名前空間が汚れてインテリセンスが腐るから欲しかった
これだけでも移行価値は無くは無いか・・・
IEnumerable<int> Enumerate(int begin, int end)
{
 if (end < begin
  || end < 0
  || begin < 0)
   throw new System.ArgumentOutOfRangeException("ほげぇ");
 IEnumerable<int> Body()
 {
 for (int i = begin; i <= end; ++i)
  yield return i;
 }
 return Body();
}

469 :デフォルトの名無しさん:2017/03/11(土) 14:40:42.15 ID:SoGUL2Zu
ちらちら見ていると、ValueTaskの方はもっと状況が酷いのかなw

http://www.buildinsider.net/column/iwanaga-nobuyuki/008
言語みたいな基幹部分を小出しにするとか、頭おかしくなってるなw
今までそんな事をした言語の末路がどうなったか知らないわけじゃなかろうに・・・

NuGetにして普通にコードする人には使わせないようにするのは、これはヤバイと中の人が感じているのかもしれんね
マイクロソフトの技術力&組織力低下酷いな、半端に才能ある奴のスタンドプレーでグダクダなってるんだろうな。
Web系に翻弄され過ぎだろ

とりあえず使えそうなのは、ローカル関数と型switchくらいかな
この辺りなら変更あってもダメージ少ないだろうし。

タプルの実装に致命的問題があるならローカルclass&struct&enum宣言でもええんやでぇ
名前空間お腐れ問題はカッコイイ事しなくても、これでも解決するんや > microsoft

470 :デフォルトの名無しさん:2017/03/11(土) 15:24:01.58 ID:SoGUL2Zu
>>218
横だけど、式木はちゃんと言語でサポートしなきゃ誰にも読めない言語になるなと思った。
逆に、それ自体は難解でもないし難しい話じゃないなとも。

プログラムとは違うけれど
3Dモデラーでツリー構造とか法線とか難解な数学概念が見ての通りの操作で動かしたり創れたりするようになって
門外漢の3Dデザイナーが普通に使えるようになったように
一度概念をキッチリ整理する必要があるんだよ、あれは。
そして言語の作りこみがあの頃から甘くなってき始めてたな、ちょっと残念な感じになっていった時代だね。

とりあえず腐り過ぎのWin10をWin7の仕様に戻せや、ストアもユニバーサルアプリも使い物にならん、色使いも糞でUIが見ずらい > microsoft
あと、WindowsUpdateのタイミングはユーザーの自由にさせよ、お前がお前のタイミングで勝手にやったら業務はむちゃくちゃになる。

471 :デフォルトの名無しさん:2017/03/11(土) 22:05:54.03 ID:h5T3JHpB
>>466
タプルなんて昔からあるだろ

472 :デフォルトの名無しさん:2017/03/11(土) 22:18:07.78 ID:15EAzLR8
>>471
残念ながら昔からあるTuple<>とは全くの別物
機能的には匿名型にも似ているが、匿名型との互換性もない
ローカル関数なんかも極めて場当たり的なゴミだろ
デリゲートの型を省略できるようにして var func = (int x) => x * 2; と書けた方がずっと便利

473 :デフォルトの名無しさん:2017/03/11(土) 22:40:13.41 ID:7U1HyGmG
>>472
いつからここが初心者用になったんだ

474 :デフォルトの名無しさん:2017/03/12(日) 01:14:05.08 ID:+ulIycHH
>>469
https://github.com/dotnet/roslyn/issues/13177
によると、.NET4.7に入れることにしたみたいだね
nugetで済むのに.NETのバージョンを上げるのは面倒が多いし、今後C#のリリース速度を早めるならある程度まとめて.NET4.7にしようって考えじゃないかなぁ

言語機能の小出しについても他の言語と比べれば遅いし、互換性と将来を考えて慎重に作ってるから完全な完成を待つと永遠にリリースできなくなっちゃうし、やむをえんだろ
CLRのバージョンを保ってくれれば文句は無い

475 :デフォルトの名無しさん:2017/03/12(日) 02:13:23.38 ID:lK2SBg8L
List<string> list; があって
そのlistのx番目からy個文字列連結したいのですがLinqでどう書けますか?
x番目から3個なら

var result = $"{list.Skip(x).Take(1).FirstOrDefault()}{list.Skip(x + 1).Take(1).FirstOrDefault()}{list.Skip(x + 2).Take(1).FirstOrDefault()}";

こんな感じですけど短く綺麗にしたいのですが…

476 :デフォルトの名無しさん:2017/03/12(日) 02:33:41.68 ID:tHLqC2EA
>>475
var result = String.Join( "", list.Skip(x).Take(y) );

477 :デフォルトの名無しさん:2017/03/12(日) 05:07:11.99 ID:lK2SBg8L
>>476
わー、短くて綺麗。
ありがとうございました。

478 :デフォルトの名無しさん:2017/03/12(日) 06:43:42.92 ID:RIOf9bqD
>>472
>デリゲートの型を省略
できるならとっくにやってるんじゃないかなw
ラムダ式は書けるコードが限定され過ぎるのが問題かな。>>468 はそれではどうやっても書けないでしょう。

479 :デフォルトの名無しさん:2017/03/12(日) 08:53:09.32 ID:bReP5RFT
>>475
自分で理解できねーもん他人に強制するその姿勢がすでにクソ
なんでその処理linqで書いた?
しかも自分は掲示板で質問しなきゃわかんねーのに
さっさと辞めちゃえお前
伸びる目もねーから

480 :デフォルトの名無しさん:2017/03/12(日) 09:23:31.23 ID:7tB+K/sW
何でこの人キレてんの?あの日?

481 :デフォルトの名無しさん:2017/03/12(日) 10:01:53.12 ID:RIOf9bqD
みるからに自演臭くてキモイからじゃねw

482 :デフォルトの名無しさん:2017/03/12(日) 10:23:22.36 ID:1QMoXo8Q
ラムダ式自体は型を持たないから、delegate型と決めつけてvar対応するなら専用のルール付けが必要だと思う。
そこまでする価値は無いかな。

483 :デフォルトの名無しさん:2017/03/13(月) 06:11:29.33 ID:o9PLbB2Z
すいません質問なんですが
アプリ起動中はAキーを推すと左クリック Bキーをおすと右クリック Cキーを押すとアプリ終了
みたいな感じでキー入力をマウス入力にいれかえるようなアプリを作りたいんですが
Windows上でフォーカスのあるウインドに依存せずにキー入力を取得するのってどうしたらいいんでしょうか

484 :デフォルトの名無しさん:2017/03/13(月) 06:55:37.31 ID:2GKmTNuX
以前、遠隔ウイルス片山も似た質問していましたね。

485 :デフォルトの名無しさん:2017/03/13(月) 07:01:39.19 ID:WHuP7MmV
フォームのKeyPreviewプロパティをTrueにすると、すべてのキーイベントをまずフォームが受け取り、処理が終了してからフォーカスのあるコントロールに渡されるようになります。

ってdobon.netで見つけた
やったことはない

486 :デフォルトの名無しさん:2017/03/13(月) 07:17:17.53 ID:o9PLbB2Z
ありがとうございます
KeyPreviewについて調べてみます

487 :デフォルトの名無しさん:2017/03/15(水) 09:07:02.25 ID:k1u612YY
すみません、EFで質問させて下さい。
下記のようにエンティティを定義して、それを編集するクライアントを作ろうとしています。
とりあえず、Modelに対する編集は無効にしてあるものとします。Unitに変更を加えて保存すると、
DBの中でModelのレコードが増えてしまいます。NameにUnique制約を付けると当然例外が派生します。
Unit.ModelがDbContextの管理外になってしまったので、別のインスタンスとして認識されているという理屈は分かります。
contextを都度作成せずに維持していれば、期待する動作になるのも分かりますが、それはできればしたくはないです。
何か上手い解決方法はないでしょうか?

public class Model
{ public int ModelId {get;set;}
 public string Name {get;set;} ※
}
public class Unit
{ public int UnitId {get;set;}
 public VM Model {get;set;}
 public string Serial {get;set;}
}
List<Unit> GetUnitList()
{ using (var context = ...)
 { return context.units.Include(x => x.model).Select(x => x).ToList(); }
}
void UpdateUnit(Unit unit)
{ using (var context = ...)
 { var target = context.units.Where(x => x.UnitId == unit.UnitId).FirstOrDefault()
  target.Model = unit.Model;
  target.Serial = unit.Serial;
  context.SaveChanges();
 }
}
var list = GetUnitList();
...リスト表示->エディタでunit.Serialを編集
UpdateUnit(unit);

488 :デフォルトの名無しさん:2017/03/15(水) 09:27:37.16 ID:N2+3G59G
>>487
そこまで分かってるなら解決策は簡単。
ModelIdで検索し直す。

489 :デフォルトの名無しさん:2017/03/15(水) 11:16:57.42 ID:k1u612YY
>>488
ありがとうございます、すっきりしました。
期待する結果に対してのコストが少々重くなるかなという気はしているのですが、
処理コストが問題になるほどの規模ではないので、そうさせて貰います

490 :デフォルトの名無しさん:2017/03/16(木) 03:52:05.80 ID:l+qA2/0G
C#でwebBrowserを使ってるんですが
以下のhtmlをwebBrowser.DocumentTextに突っ込んで表示させたいんですが
何故かwebBrowserではそのままjqueryを読み込むことが
できないようでスクリプトエラーが発生してしまいました
対処方法のわかる方いたら教えていただけますでしょうか?

↓以下のhtml

<!DOCTYPE html>
<head>
<meta charset=""utf8"">
<script src=""https://code.jquery.com/jquery-2.1.4.min.js""></script>
<script type=""text/javascript"">
$(function() {
alert(""test"")
});
</script>
</style>
</head>
<body>

491 :デフォルトの名無しさん:2017/03/16(木) 11:36:09.87 ID:oyR0ujl0
なんでダブルクォーテーション2つ続いてるの?

492 :デフォルトの名無しさん:2017/03/16(木) 16:49:18.07 ID:l+qA2/0G
エスケープです
文字列に突っ込んでるのをそのままコピペしちゃったのでそのようになってます
すいませんがエスケープは無視して考えてください。

493 :デフォルトの名無しさん:2017/03/16(木) 16:58:42.52 ID:Qa1xgsfZ
<style>
<head>
<body>

</style>
</head>
</body>


最後のbodyを/スラッシュで括ってないからでは?

494 :デフォルトの名無しさん:2017/03/16(木) 17:03:26.21 ID:RyFuDdep
>>493
君は冷静だな

495 :デフォルトの名無しさん:2017/03/16(木) 17:05:05.86 ID:Qa1xgsfZ
HTMLソース
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>HTML5サンプル</title>
</head>
<body>
<p>HTML5で作成しました!</p>
</body>
</html>

連投ですまん
もっと解り易いサンプル

496 :デフォルトの名無しさん:2017/03/16(木) 18:14:35.84 ID:kQHrflry
WebBrowserがデフォだとIE7モードで動くせいでjquery 2.1.4が動かない
・jquery 1系使う
・headに
<meta http-equiv="X-UA-Compatible" content="IE=edge">
等を書く
・レジストリでモード変更する
好きなのどうぞ

497 :デフォルトの名無しさん:2017/03/16(木) 18:38:16.89 ID:RyFuDdep
>>496
君は詳しいな

498 :デフォルトの名無しさん:2017/03/16(木) 20:09:32.60 ID:G/L2rMHg
簡単に単体テストできるのか知りたいです

public static async Task DoHeavyAsync(string path, IProgress<long> progress, CancellationToken token)
という非同期メソッドの単体テストで、同期版の DoHeavy() と同様のテスト以外に、

(1) progress が動作していることの確認
(2) token が動作していることの確認

が必要だと思います

(1) が簡単ではない
var progress = new Progress<long>(n => { Assert.Fail(); });
などやっても、テストが成功してしまう(レポートがメソッド終了後に届くため)
まじめにやるとしたら別スレッドを作る必要がありそう?

(2) は、巨大ファイルを使って new CancellationTokenSource(20) などでキャンセルされることを確認という
汚い手法でテストしています(処理速度があがった場合にテストが失敗する可能性があるのが汚い点)

(1)と(2)、それぞれどのようにテストするべきでしょうか? 特に(1)
NUnit を使ってますが、他のフレームワークでもいいです

499 :デフォルトの名無しさん:2017/03/16(木) 20:16:08.57 ID:kgKaK9fl
非同期処理の確実なテスト方法は存在しないのでどっかで妥協しなきゃならない

500 :デフォルトの名無しさん:2017/03/17(金) 07:37:50.30 ID:gTyXrRTf
よく分からんな
Taskなんだから結果が出るのを待機すればいいだろ
Progressは呼ばれたらcalledフラグを立てるようにしてそいつでAssetする
タイムアウトが必要かどうかは状況次第

2つめは、内部でFileStreamを使っているならだが
Streamを受け取るインターフェースを追加する
クッソ遅いStreamは自由に再現できる

501 :デフォルトの名無しさん:2017/03/17(金) 08:16:11.77 ID:VDcrtJ6N
>>496
ありがとうございます!大変助かりました!

502 :デフォルトの名無しさん:2017/03/17(金) 21:11:54.40 ID:G6TjLWRU
>>499
やっぱり妥協かなー

>>500
(2) はなるほどね。作ってみる
(1) なんだけど、Progress.Report() での通知は、タスクを await で待機したとしても、
待機が終わった後でも Action<T> が呼ばれているとは限らない
巨大なタスクを渡して、 Progress.Report() が『たぶん』呼ばれるという妥協が必要かなー

単体テストをパスしたとしても、たまたま運良く Action<T> が先にスケジュールされただけだよ
下記のコードはうちの環境ではテストに失敗してた

public static async Task DoLightAsync(IProgress<long> progress)
{
await Task.Delay(10);
progress.Report(123);
}

[Test]
public async Task DoLightAsyncTest()
{
bool called = false;
await DoLightAsync(new Progress<long>(n => { called = true; }));
Assert.IsTrue(called);
}

503 :デフォルトの名無しさん:2017/03/18(土) 00:00:39.16 ID:3lIBsEeS
惜しいところまでは行ってるな

Progressのインスタンスを渡すのではなく
IProgressを継承し同期のReportを実装したクラスのインスタンスを渡す

504 :デフォルトの名無しさん:2017/03/18(土) 10:58:29.15 ID:UTVmwL6L
ふむー、こうか
確かに Progress<T> にこだわる必要はなかったなー

public class SynchronousProgress<T> : IProgress<T>
{
private readonly SynchronizationContext _Context;
private readonly Action<T> _Action;

public SynchronousProgress(Action<T> action)
{
_Action = action;
_Context = SynchronizationContext.Current ?? new SynchronizationContext();
}

private void Callback(object state)
{ _Action?.Invoke((T)state); }

public void Report(T value)
{ _Context.Send(Callback, value); }
}

見づらいと思うので一応 pastebin にも貼っておく
http://pastebin.com/QjF0XkH4

505 :デフォルトの名無しさん:2017/03/19(日) 00:14:21.68 ID:xAk2llJg
ファイルのタイムスタンプを指定した時刻に変更したいんですが、コードのヒントをくださいm(_ _)m

506 :デフォルトの名無しさん:2017/03/19(日) 00:19:27.37 ID:8DI2TWvJ
>>505
FileInfo

507 :デフォルトの名無しさん:2017/03/19(日) 00:30:52.74 ID:VKtnwSVx
「ファイルのタイムスタンプ」でグーグル先生に聞けば
http://www.atmarkit.co.jp/fdotnet/dotnettips/370timestamp/timestamp.html
が一発で出てくるんだけど掲示板で聞く方が面倒じゃないの

508 :デフォルトの名無しさん:2017/03/19(日) 06:34:49.31 ID:bkt1N2YW
検索知らないんでしょ

509 :デフォルトの名無しさん:2017/03/19(日) 13:50:14.09 ID:PWrmpV5o
2chスレへたどり着けるのに検索知らないとかこれ如何に

510 :デフォルトの名無しさん:2017/03/19(日) 14:33:00.16 ID:DWsQT7k4
「お前ら、検索頼むわ(丸投げ)」

511 :デフォルトの名無しさん:2017/03/19(日) 14:45:08.30 ID:1DEeFth3
おまいらは回答する機械

512 :デフォルトの名無しさん:2017/03/19(日) 14:53:33.02 ID:VKtnwSVx
まあ調べたら自分の新しい知識になる場合もあるからいいんだけど
この程度の事も検索しないのならコードなんか書けないような

513 :デフォルトの名無しさん:2017/03/19(日) 15:03:19.30 ID:lJcyTqFl
プログラムやる奴らって質問されるとキレながらも答えたい願望あるんだよな
そして煽って議論させるのも好き
だからわざわざ検索しないでここに投げてあげたりする

514 :デフォルトの名無しさん:2017/03/19(日) 15:04:25.29 ID:1DEeFth3
それにしたって餌としてはしょぼすぎる

515 :デフォルトの名無しさん:2017/03/19(日) 15:10:14.91 ID:p4p+SSjy
ボランティアを馬鹿にすんじゃねーぞ、コラ!

516 :デフォルトの名無しさん:2017/03/19(日) 16:02:53.06 ID:T5IZ831S
人力検索

517 :デフォルトの名無しさん:2017/03/19(日) 16:06:30.35 ID:z5/tCjGK
>>513
そういうのは初心者向けふらっとの方でやってくれw
あそこなら解決済みでもグダグダ続けたがるのがいっぱいいる

518 :デフォルトの名無しさん:2017/03/19(日) 18:48:36.73 ID:lJcyTqFl
>>517
でも質問してくれないと寂しいんだろ?

519 :デフォルトの名無しさん:2017/03/19(日) 18:52:31.68 ID:bcM43571
くだ質とかVSスレとかこの板で変なやつ増えたよな
本当にプログラムやっているのかって感じの
ここにも来てるのか

520 :デフォルトの名無しさん:2017/03/19(日) 21:56:16.72 ID:HC9gBYvT
マ板行けって思うスレ多いよな

521 :デフォルトの名無しさん:2017/03/20(月) 01:44:39.35 ID:SU/B8MWa
アクセスアップとお小遣い稼ぎの裏技
トラフィックエクスチェンジ
http://tra-chan.jugem.jp/?eid=1

522 :デフォルトの名無しさん:2017/03/20(月) 10:11:03.85 ID:Afs087wZ
>>520←コイツの馴れ合おうとするレスうざっ

523 :デフォルトの名無しさん:2017/03/20(月) 12:24:29.57 ID:y4a+UdUh
>>522
マ板行け

524 :デフォルトの名無しさん:2017/03/20(月) 14:10:48.91 ID:pi/vFj6F
>>523お前が行け

525 :デフォルトの名無しさん:2017/03/20(月) 14:57:32.61 ID:98bjORSB
ここは幼稚園じゃないんだが。

526 :デフォルトの名無しさん:2017/03/20(月) 15:41:51.51 ID:4DDUMBY5
似たようなもんよ

527 :デフォルトの名無しさん:2017/03/20(月) 15:48:57.55 ID:LcNjV7jZ
言い争いを見てたら幼稚園児とたいして変わらん気がする

528 :デフォルトの名無しさん:2017/03/20(月) 16:00:23.53 ID:pi/vFj6F

いい加減うざいって、お前らずっとスレちがい

529 :デフォルトの名無しさん:2017/03/21(火) 05:52:14.36 ID:SG0A/rfm
ただいま C# 7.0 利用中
ジェネリックのローカル関数まで書けるのにオーバーロードは出来ない事に気づいてがっかりモードになっている件
なぜできんOrz
あと大抵の場合キャプチャは要らないんだけどな・・・
0b1110_1011 とか二進数のリテラル地味に便利w

530 :デフォルトの名無しさん:2017/03/21(火) 06:45:57.61 ID:0zsWCCNl
オーバーロードはクラス外からみて合理的なインターフェイスを提供するためのもので、
内部で使うだけなら紛らわしいだけだろ
オーバーロードが欲しくなるほど長いメソッドを作ること自体が間違ってるし

531 :デフォルトの名無しさん:2017/03/21(火) 14:40:35.20 ID:SG0A/rfm
>>530
そんな事は無いよ、型別にスイッチするくらいならオーバーロード見通しいい

532 :デフォルトの名無しさん:2017/03/21(火) 19:18:26.99 ID:bA9h/8/p
似たような処理するのにメソッド2つも要らない
中で分岐させて使え、その方が保守楽だから

って言われたことある。
オマエラも結局中で分岐させてる?

533 :デフォルトの名無しさん:2017/03/21(火) 19:23:26.02 ID:qbQ1Fjub
>>532
時と場合による
何でもかんでも共通部分をまとめようとするのはバカだが

534 :デフォルトの名無しさん:2017/03/21(火) 19:24:42.66 ID:qRIPyX6L
内部の分岐とかどうでもよくね?
似たような処理のメソッドが複数出来る時点で設計からして間違っているだろうし

535 :デフォルトの名無しさん:2017/03/21(火) 19:30:08.87 ID:72kEtT2Q
>>530
利用するかどうかは別にしてわざわざ禁止するほどのことではないよね
ってことだろ

536 :デフォルトの名無しさん:2017/03/21(火) 19:31:27.83 ID:qbQ1Fjub
>>534
ループ中で分岐処理が必要な場合があるので2行目は違うと思う
速度ちょっとでも稼ぎたいと思ったらループの外で分岐させておくだろうし

537 :デフォルトの名無しさん:2017/03/21(火) 19:39:30.55 ID:RrALGwyw
>>532
そういうことするとすぐに分岐が増えて収集がつかなくなる
この業界は既存のコードの権力が強すぎる
一回でもはまるともう最後まで逃れられない
だから最初から妥協せずクリーンな状態を維持し続けるしかない

538 :デフォルトの名無しさん:2017/03/21(火) 19:50:56.44 ID:UqOt5XZ1
だったらなおのこと分岐のが楽だな
実行して見ないとなんの処理が走るか分からないコードにメリットなんて感じない
資料にも書けないしお客さんにも説明できない

539 :デフォルトの名無しさん:2017/03/21(火) 20:14:47.71 ID:7sd4gAxo
>>535
オーバーロードを許すと実装コストは増えるよ
オーバーロードされたメソッドのマングリングってこれまでにやったことないはず
クソ長いメソッドを定義する馬鹿のために無駄な実装コストをかけることは許容できない

540 :デフォルトの名無しさん:2017/03/21(火) 23:05:57.08 ID:UqOt5XZ1
マンコリング?

541 :デフォルトの名無しさん:2017/03/22(水) 02:05:33.87 ID:YDOC/IGa
オーバーロードがないのは多分キャプチャが原因だと思うよ
可能なら多分やってる、というかキャプチャ無しならオーバーロード可能にしてほしい感じ
さらにいうなら、キャプチャ無し指定をして普通のメソッドが単純に名前空間上に合わられないだけにして欲しい。
でもって、ローカル変数と被る名前OKにしてくれれば一番いい。
結局、ローカル関数にした理由はインテリセンスが機能不全になって欲しくないという話なだけだから。

542 :デフォルトの名無しさん:2017/03/22(水) 02:11:31.86 ID:YDOC/IGa
なんであんなに変更可能キャプチャが好きなんだろうな・・・
関数型言語のように一度割り当てられたら変更がないことが保証されれば見通し良いし使い勝手も良いけれど
手続き型言語にキャプチャが入ると見通し悪い事この上ないから、可能な限り使わないようにしたい気分になっている。

543 :デフォルトの名無しさん:2017/03/22(水) 11:28:29.87 ID:hks7EAC1
C#の糞拡張はこれからが本番ですよ。

544 :デフォルトの名無しさん:2017/03/22(水) 12:58:18.38 ID:7zaDxJTN
文句あるなら自分で言語作ればいいのに
何で作れない分際で文句言ってるんだか

545 :デフォルトの名無しさん:2017/03/22(水) 13:01:02.87 ID:+8Koiwe2
基地外発想だな

546 :デフォルトの名無しさん:2017/03/22(水) 13:23:33.31 ID:6nIA/xoV
フジテレビ的発想

547 :デフォルトの名無しさん:2017/03/22(水) 13:50:44.67 ID:FLtL2zh7
自分で作れないから文句言ってんだろ
お前も同レベルに頭わるそうだなw

548 :デフォルトの名無しさん:2017/03/22(水) 14:47:13.98 ID:T50yqk9Q
>>544
できらぁ!

549 :デフォルトの名無しさん:2017/03/22(水) 15:44:09.05 ID:YDOC/IGa
ValueTuple使ったら、変数見えないデバッグできねぇwwww
まさに作りかけwwwww

550 :デフォルトの名無しさん:2017/03/22(水) 15:45:53.48 ID:YDOC/IGa
>>544
みんなで同じものを使うから意味があるんだよ、一人で勝手に作って勝手にやってたら滅茶苦茶なるだろw

551 :デフォルトの名無しさん:2017/03/22(水) 19:44:37.37 ID:JvcKijZm
ヘジたんも言語なんか開発するのは時間の無駄だからやめなさいと言っていたしな

552 :デフォルトの名無しさん:2017/03/22(水) 20:41:21.23 ID:qEl3ed9E
だれよ

553 :デフォルトの名無しさん:2017/03/22(水) 20:59:39.74 ID:eP+YAd4z
>>549
それ、お前がメクラなだけじゃね?

554 :デフォルトの名無しさん:2017/03/22(水) 21:17:25.63 ID:YDOC/IGa
>>552
Delphiの開発者で、ゲイツ御大にC#のアーキテクトしてボーランドから引き抜かれた人

555 :デフォルトの名無しさん:2017/03/22(水) 21:23:40.38 ID:YDOC/IGa
暫く使ってみたけど、やっぱ、ラピッドリリースはよくねぇよな
どんどん品質が落ちていく
誰だよこんな糞な手段はやらした馬鹿は
Windows10もVisualStudioもボロボロやん

556 :デフォルトの名無しさん:2017/03/22(水) 22:28:00.53 ID:MyrW3Mfd
>>555
どんどんお前が老いていってるだけ

557 :デフォルトの名無しさん:2017/03/22(水) 22:41:57.96 ID:Qh2JSeLT
最近思うんだけどRazor使わずに普通のhtml+JS+REST API(.NET)の方が開発しやすくない?
Razorって本当に便利なのかな?生産性あがる?

558 :デフォルトの名無しさん:2017/03/23(木) 01:12:53.78 ID:eX8m9MWo
業務アプリで同じような画面を大量生産するには便利A: [1.201975 sec.]B: [2.281051 sec.]

559 :デフォルトの名無しさん:2017/03/23(木) 01:47:02.34 ID:FaFIhE+0
C#に限らずかもしれないけれど、invokeってフォームに限ってどうして必要なのですか?
invokeを書けばメソッドを呼び出してプロパティにアクセスできるのは分かるのですが
invokeがないと何がダメなのか内部的なことを教えていただけますか?

560 :デフォルトの名無しさん:2017/03/23(木) 01:52:24.45 ID:Un9Q+jtZ
>>556
心配しなくても若い子はもうWindowsも使わなければVisutalStduio何それ?状態だからw
みんなWeb系でスマホばっかりやっている。
もう、ここに残っているのは年寄りだけだよw

561 :デフォルトの名無しさん:2017/03/23(木) 01:56:59.96 ID:Un9Q+jtZ
>>559
昔のシングルスレッド時代の遺産を引きずっているんだよ
Formは、半ばラッパーライブラリなので。
シングルスレッドの利点はデッドロックの可能性がないこと。
マルチスレッド当たり前になってしまった今だと、逆にデッドロックの元になってしまったりと困った有様だけど。
遺産の量が大きいので、全く別の物を作るのは簡単ではないだろうね。

562 :デフォルトの名無しさん:2017/03/23(木) 02:00:44.79 ID:FaFIhE+0
>>561
ありがとうございます
もっと詳しく知りたいのですがどう言葉で調べればよいのでしょうか?
できればネットで調べれるものがよいのですが、書籍でも平気です
英語のサイトでも平気です
なにかあれば教えていただけますか?

563 :デフォルトの名無しさん:2017/03/23(木) 02:04:38.43 ID:VjAjr2s9
>>559
UI関連は、UIスレッドでのみ動作することを前提に設計することで、パフォーマンスを上げてる。
マルチスレッド対応にすると排他制御等が増えてしまい、パフォーマンスが下がる。

>>561
非同期処理とか書きやすくなったから、最近は割と楽だろ。
Invokeも使う必要ないし。

564 :デフォルトの名無しさん:2017/03/23(木) 02:05:51.99 ID:Un9Q+jtZ
>>562
C言語から、直接Win32APIを叩いてみればわかると思うよ。
WM_XXXXとかを直接使ってGUIを動かしてみれば、古いインターフェイスの感触どんなもんか分かるかと。
年代物なので、古本屋でWin32の本でも探してみるのもいいかも。
今更みる価値あるのかって思うので、お勧めはしないけど。

565 :デフォルトの名無しさん:2017/03/23(木) 02:07:28.88 ID:Un9Q+jtZ
>>563
Task作った奴はバカだと思うwww
Invokeの方がまだ誰にでも分かりやすい。

継続なにそれおいしいのwww
関数型言語面白いねって感じだね

566 :デフォルトの名無しさん:2017/03/23(木) 02:09:33.89 ID:Un9Q+jtZ
このマルチコア時代にシングルスレッドで頑張ってパフォーマンス上げるとか
時代錯誤も甚だしいよな・・・

567 :デフォルトの名無しさん:2017/03/23(木) 02:16:32.78 ID:FaFIhE+0
>>563,564
新人にinvokeを教える際に困ってしまったので
浅くでも知識として知っておきたかったので助かりました
Win32からの流れなのですね、Formだけこんなに違うのはそういうことなのですね。。
時間があるときにもう少し調べてみようと思います
ありがとうございました

568 :デフォルトの名無しさん:2017/03/23(木) 02:21:34.59 ID:VjAjr2s9
>>565
async/awaitやIProgress<T>あるから、Taskの継続を直接使う事はあまり無いな。
間接的には使ってるわけだが。

569 :デフォルトの名無しさん:2017/03/23(木) 02:21:39.46 ID:9gkqdxMB
>>566
時代関係ないから
スレッドセーフにするとパフォーマンスが犠牲になるのはUIだけじゃない
BCLのクラスのインスタンスメソッドも大半はスレッドセーフじゃない

570 :デフォルトの名無しさん:2017/03/23(木) 02:22:11.13 ID:Un9Q+jtZ
Win32は、当時のオブジェクト指向の実現にむけての試行錯誤が見れるのは面白いかもしれない
メッセージ飛ばしたり、メール飛ばしたり、色々試行錯誤の末にC++の仮想テーブル方式にたどり着く訳だけれども
その前の段階のオブジェクト指向が見れるよw

571 :デフォルトの名無しさん:2017/03/23(木) 02:23:39.71 ID:Un9Q+jtZ
>>569
いつまでも凝り固まってますねwww
もうハイハイって感じですわ

572 :デフォルトの名無しさん:2017/03/23(木) 02:28:42.19 ID:Ei+8urX3
しかしGUIなんて所詮人間速度だし、パフォーマンスって要らないよな?
フォームに関しては最初からマルチスレッド対応でinvokeの必要無しの方が良かった気がするが。

573 :デフォルトの名無しさん:2017/03/23(木) 02:30:27.90 ID:9gkqdxMB
>>571
いるよね、こういう量的な進歩と質的な進歩の区別のつかない奴
馬鹿な奴だ

574 :デフォルトの名無しさん:2017/03/23(木) 02:31:53.25 ID:VjAjr2s9
何でもマルチセーフにすれば良くなるってもんでも無いのね。
排他制御のコストは大きいから、なるべくそれを無くす設計が重要。

575 :デフォルトの名無しさん:2017/03/23(木) 02:32:30.61 ID:Un9Q+jtZ
>>572
いやいや、それでもあった方がいいよ
マルチスレッドできっちり分散できれば、1CPU辺りの負荷が軽くなる
すると低クロックで動いて消費電力が小さい。
シングルスレッドだと、同じ負荷でも1CPUに集中するからクロックが上がってしまう。

576 :デフォルトの名無しさん:2017/03/23(木) 02:35:01.08 ID:Un9Q+jtZ
>>573
質的にはTaskは逆立ちして徒競走しているようなモンだなw
普通立ってに走れよ、頭オカシイんかいってなもんだね。

577 :デフォルトの名無しさん:2017/03/23(木) 02:36:32.46 ID:9gkqdxMB
しかし、マルチコアっていうのは苦し紛れの「苦肉の策」であってポジティブな進歩じゃないって
パソヲタレベルでも知ってる常識だと思ったけどプログラマでもそういう認識がない奴がいるんだね。

そういう奴は「人月の神話」って言葉も聞いたことないんだろうな。
生産性は作業者の投入人数に比例しないのはコンピュータも同じだよ馬鹿

578 :デフォルトの名無しさん:2017/03/23(木) 02:38:13.08 ID:Ei+8urX3
>>575
いやお前実は分かってないだろ。
575はinvokeを肯定しているぞ。てかお前どっち派よ?

579 :デフォルトの名無しさん:2017/03/23(木) 02:40:35.49 ID:Un9Q+jtZ
>>578
async / await 最新わかってる俺スゲーなヤツが死んでほしい派
技術的には、まぁあるもん使うさってなもんだ。

580 :デフォルトの名無しさん:2017/03/23(木) 02:57:11.32 ID:VjAjr2s9
>>576
Taskはスレッドプールを使いやすくしたもの。
スレッドプール自体は昔から使われるテクニックだし、なんでそこまで嫌うのか分からん。
Taskのおかげで非同期処理が非常に楽に扱えるようになったのに。

581 :デフォルトの名無しさん:2017/03/23(木) 03:07:35.11 ID:Un9Q+jtZ
>>580
以前作って滅びたATLなんかと同じだね、入門者がすぐに理解して使えない物は糞
WPFも同様の香りがするね
分からないけれどなんとなく使えているって人だらけになって理解していないから、エラー対処ができない。
そうすると、全部特定の人に負担が行く、そんなコードやライブラリは使えない。
これはマイクロソフトの象牙の塔だよ

582 :デフォルトの名無しさん:2017/03/23(木) 04:45:12.92 ID:0wLqn0eU
ATLがいつ滅んだんだよw

583 :デフォルトの名無しさん:2017/03/23(木) 07:10:17.81 ID:UmFjwc/F
昔の名残とかじゃなく、単にマルチスレッドでUI部品を扱うのが大変だということだと思うんだが

ユーザーインターフェイススレッド - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%82%A4%E3%82%B9%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89

>例えば、Java の AWT では、1996年の最初の時点では、
>単純にスレッド間でデータ共有型のマルチスレッドになっていた。
>しかし、データ共有するには、ロックをかけないといけないが、
>親コンポーネントから子コンポーネントを呼んだり、
>コールバックで子から親を呼んだり、
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
>異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。
>これはソフトウェアが非常に複雑になる原因となってしまう。
>また、ロック順序のミスが引き起こすデッドロックは常にではなく
>たまに発生したりすることの多いバグ(時間的確率要因が関与する偶発性のあるバグ)であり、
>バグ取りが大変になるという問題があった[3]。
>
>そこで、1997年の Java の Swing からは、
>UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから
>操作しなくてはならない、というルールを設けた。

584 :デフォルトの名無しさん:2017/03/23(木) 07:23:37.05 ID:i5lX3ZQq
それを昔の名残とかラッパー、速度優先って言ってるんでしょ
マルチスレッドにしようと思ったらできるんだから

585 :デフォルトの名無しさん:2017/03/23(木) 08:05:24.99 ID:eX8m9MWo
WinFormsやWPFを含めたGUIフレームワークって
イベントハンドラなどのユーザーコードに制御を渡す前後で
一時的に状態を変えたりしてることが多いから、
それ以外のタイミングで触られると壊れる
結局それを防ごうとするとユーザーコードの実行タイミングまでブロックすることになるので、
Invokeと変わらなくなる

586 :デフォルトの名無しさん:2017/03/23(木) 08:14:01.02 ID:HovpjxiM
>>584
> マルチスレッドにしようと思ったらできるんだから
話がループしてるぞ
やればできるけどコールバックとかでロックの管理が面倒だしUIだから極限まで性能追い求める必要もないから
>> UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから
>> 操作しなくてはならない、というルールを設けた。
ってことだろ

587 :デフォルトの名無しさん:2017/03/23(木) 10:27:00.68 ID:BTeOg9CT
>>564
COMのアパートメント問題を解決するためじゃないの?
厳密にはInvokeしなくて良いケースもあるけど、それを保証する方法が皆無に等しいという。

ウインドウメッセージ云々とか、本質とはかけ離れている気が。

588 :デフォルトの名無しさん:2017/03/23(木) 12:30:56.91 ID:Un9Q+jtZ
>>582
もう誰も使っている奴いないだろう、放棄されて保守だけが残っている。
こういう技術はいずれそうなるよ

589 :デフォルトの名無しさん:2017/03/23(木) 12:53:23.45 ID:Un9Q+jtZ
>>586
UI側がバージョン管理システムみたいな扱いをすればいいんだと思うけどね
非ロック型で同期をとる方法としては有効だと思う。
いわゆる
読み込んで、内容を変更して、読み込み時点データとともにUIに返す。
UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
ロックオブジェクトが自分自身に限られるからデッドロックの可能性はない。
この方法の場合、読み出すだけならロック不要でいつでも読み込めるしね。

俺は、UIに関してはそういう設計にして自分のメソッドはすべてスレッドセーフだ。
長年の実績ある方法だし、このやり方は非常に優れていると思う。
更新失敗とリトライは発生するが、並列度はかなり高くなる。
デッドロックは皆無で、見通しも良い。

590 :デフォルトの名無しさん:2017/03/23(木) 12:55:44.66 ID:Un9Q+jtZ
>>589 に追加
これのよい所は、バージョン管理システムは普通誰でも使わなきゃならないもので
どういう風に機能させるのか誰にでもすぐ分かる。
問題が発生しても初心者に簡単に解決できるという点が良いと思っている。

591 :デフォルトの名無しさん:2017/03/23(木) 17:07:47.97 ID:EtPn1ouj
なんか酷いやり取りだね
マルチスレッドを根本的に理解してないのが何人かいるねw

スレッドセーフに作ることは高コストだから特に理由がない限りそうしないのは
マルチスレッド理解の初歩の初歩だと思うんだけど。

あれだ、UIは別スレッドからのアクセスを検出して例外投げるようになってるわけだけど、
例外が投げられなければ何も問題ないはずだ、っていうVBerな発想なのかねw

592 :デフォルトの名無しさん:2017/03/23(木) 17:21:43.84 ID:ncdnXTN/
.NETは実行コストよりも実装コストを重視する傾向にあるからね
スレッドセーフなformになってもいいと思うわ

593 :デフォルトの名無しさん:2017/03/23(木) 17:24:03.63 ID:30c+rZIc
>>592
君のコードはイベントハンドラが並列に実行されても大丈夫?
利用する側の実装コストも確実に跳ね上がるよ

594 :デフォルトの名無しさん:2017/03/23(木) 18:15:58.21 ID:ncdnXTN/
マルチスレッド動作のformにとは言ってないんだよ・・・

595 :デフォルトの名無しさん:2017/03/23(木) 18:57:02.57 ID:99dRkoLd
>>592
そこでwpfのバインディングですよ

596 :デフォルトの名無しさん:2017/03/23(木) 19:28:24.32 ID:Un9Q+jtZ
>>591
酷いやり方というのはある意味正しい
そもそもformsが腐っている以上綺麗な方法はハナから存在しない。
それでも誰にでもわかり、誰にでも修正可能なやり方っていうのが重要なんだよ。
それができなきゃ、一人で勝手にやっていろって話になる。
チームで作業は不可能だ。

597 :デフォルトの名無しさん:2017/03/23(木) 19:30:23.84 ID:Un9Q+jtZ
バインディングとか最悪やな、何処がどうなっているのか把握できる人間が居なくなって
誰にもメンテできなるなる典型w

598 :デフォルトの名無しさん:2017/03/23(木) 19:32:40.10 ID:Ei+8urX3
>>583
> GUIライブラリからアプリケーションをコールバックしたりと、
これってあるか?ピンとこない。

そもそも、UIってロックする必要があるか?
現状、UIスレッドとタスクスレッドは別で、結果的にプログレスバー等の更新にはinvokeを使うしかない。
これがウザイから「直に書き込みさせてくれ」というのが俺の希望。
そもそも、排他的な実装をしなければならない理由がないだろ。
プログレスバーなんて普通は共有しないし、
してたらしてたで「どちらの内容が表示されてもいい」が仕様になるのだから、
レーシングしたところで問題ない。
結果、リクエストがあったらただ更新すればいいだけ、それを表示すればいいだけ、で終わりじゃないか?
ファイルみたいにロックありきの物ではないと思うんだが。

599 :デフォルトの名無しさん:2017/03/23(木) 19:35:54.46 ID:g/kXmQSp
マルチスレッドアクセス可能なGUI採用してるシステムなんてあったっけ
UIスレッドモデルが遺産だというのなら
新しいシステム(Windowsに限らんぞ)ほど「そうなってはいない」はずだが
実際は最近のOS(やはりWindowsに限らない)でもUIスレッドモデルだ
何故だろうなあ

下手の考えなんぞ大抵は
「先人が思いついたけどあえてやらなかった」か「すでに失敗した」か

600 :デフォルトの名無しさん:2017/03/23(木) 19:36:15.02 ID:Un9Q+jtZ
Haskellみたいに極度に小さい記述で複雑なシステムが組めるのは確かに凄いんだよ
あれはマジ使える、ただし誰にでも使えるものでは無い。
こういう物は、チーム作業には向かない。
少人数で高度なプログラミングをするのには向いているがね。
で、C#はHaskellみたいなアプリケーションを作るために開発されたものなのかというと、それは違う。
誰でも使えるBasicの延長線上のものだ。

TaskもWPFもHaskellみたいな超絶技巧を目指しているだな、そんなものは要求されていないのに。

601 :デフォルトの名無しさん:2017/03/23(木) 19:37:49.41 ID:Ei+8urX3
>>595
あー、WPFのバインディングはこれを目指していたのか。
なるほど俺の要求だけならこれでいいわ。

602 :デフォルトの名無しさん:2017/03/23(木) 19:39:47.03 ID:FkdET+B0
不思議だな
新しい技術のおかげでプログラミングはますます簡単になってるのに
まるで難しくなったような意見が出てくる

603 :デフォルトの名無しさん:2017/03/23(木) 19:40:57.33 ID:Un9Q+jtZ
結局ね、マイクロソフトの技術者はコンセプトという物が理解できないバカの集団と化してしまったんだよ。
多分、社内政治とスタンドプレーの果てにこうなったんだろうなと。
だから、マイクロソフトは象牙の塔。
勉強しまくっているが自分のやっている事しか見えていない奴が音頭を取り始めてしまっている。

604 :デフォルトの名無しさん:2017/03/23(木) 19:46:09.55 ID:J2eFkRx5
ほーん、で?いちいち同意求めんなカス
知恵袋で恋愛相談してるクソアマかテメー

605 :デフォルトの名無しさん:2017/03/23(木) 19:57:59.50 ID:HovpjxiM
>>589
> UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
一致してない時に再計算をする必要があるからその計算が軽い時に有効な方法
ちなみにバージョン管理システムでは他の人が変更してるからやり直せって言ったら使い物にならないのでいわゆるマージ処理を行うのでちょっと違う

606 :デフォルトの名無しさん:2017/03/23(木) 20:26:39.42 ID:HovpjxiM
>>598
GUI 組んだことないのか?
イベントってフレームワークからのアプリケーションの呼び出しだぞ
あとロックするのは GUI のフレームワークじゃなくてアプリケーションの方
マルチスレッド化したフレームワークだとイベントっていつ発生するかわからないのでお前みたいなよくわかってない奴が組むとデッドロックを引き起こしたりしやすいって話

607 :デフォルトの名無しさん:2017/03/23(木) 20:27:34.06 ID:99dRkoLd
>>601
但しコレクションに関してはBindingOperations・・・のおまじないが必要だ

608 :デフォルトの名無しさん:2017/03/23(木) 20:48:03.89 ID:Ei+8urX3
>>606
今時GUIしかやらんだろ。
が、まあこっちの認識がずれていたのは分かった。

>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
前者が「プログレスバーの更新」で、
後者が「 XXX.click += YYYY;」か。
確かに双方向だ。

で、ロックは必要か?
プログレスバーの更新なんて、ロックする必要ないだろ。
他もそうだと思うが。

609 :デフォルトの名無しさん:2017/03/23(木) 20:49:29.54 ID:30c+rZIc
>>606
具体的な最大の問題は、マルチスレッドアクセスを許容するとUIスレッド上で排他処理をしなきゃいけないことなんだよな
UIスレッドは多種多様なタスクによってタイトに使い回されるので、それをブロックすることは容易にデッドロックを引き起こす
UIスレッド上で別の処理Xが終わるのを待ってたら、XもUIスレッド上で呼び出される処理で
いつまでもXが呼ばれなくなりデッドロック、というのはよくあるパターン

610 :デフォルトの名無しさん:2017/03/23(木) 20:55:57.96 ID:30c+rZIc
>>608
そのプログレスバーの更新一つとっても中でどれだけ複雑なことをやっているかは君にも想像できるだろ?
君がロックしてるつもりがなくてもプログレスバーの更新処理を呼び出せば内部で当然ロックがかかる

611 :デフォルトの名無しさん:2017/03/23(木) 21:00:57.40 ID:Ei+8urX3
>>609
普通に組んだらデッドロックはしなく無いか?例えば、

1. UI <- Task_thread_A で Aが止まる。
2. Task_thread_A <- Task_thread_B で Bが止まる、ここまではありがち。
3. Task_threadB <- UI :これはねーよ。

UIスレッドがTaskスレッドを見てロックするという使い方は普通しないだろ。

612 :デフォルトの名無しさん:2017/03/23(木) 21:14:48.29 ID:Ei+8urX3
>>610
いや、ロックの必要はないだろ。
正確に言えば、外部からの明示的なロックが必要無いように作れば作れるだろ。
今そうなってないだけで。

要するにプログレスバーを UI, Task_thread_A, Task_thread_B の
どこからも更新出来るようにしたいとして、
全部、 progressBar.value = x; と書かせろ、と言いたいだけで。

内部的に細かくロックして、順に処理するのはCLRが勝手にすればいい。
その結果、それぞれのスレッドが微妙にロックするのも仕方ない。
ただ、循環ロックにならない限り、デッドロックにはならないだろ。
そして普通に書けば、循環ロックにはならないだろ。

613 :デフォルトの名無しさん:2017/03/23(木) 21:17:21.47 ID:5A+rvbXC
独りで仕方ないと思って存分に射精してろハゲ

614 :デフォルトの名無しさん:2017/03/23(木) 21:24:07.98 ID:NnBP2eXC
>>608
GUIしかやらない?どこの世界の話だよ

615 :デフォルトの名無しさん:2017/03/23(木) 21:27:34.82 ID:VjAjr2s9
>>589
アトミックなデータでない限り、読み出しでロックが不要は誤り。
更新中の中途半端なデータが読みだされたらどうすんの。

616 :デフォルトの名無しさん:2017/03/23(木) 21:30:44.46 ID:5A+rvbXC
生兵法はケガの元だな
毛がなくて良かったね〜

617 :デフォルトの名無しさん:2017/03/23(木) 21:32:55.65 ID:HovpjxiM
>>608
> あとロックするのは GUI のフレームワークじゃなくてアプリケーションの方
の意味を理解してないのかよ...
そりゃ単純にプログレスバーに表示するぐらいなら問題は発生しないよ w
例えば複数の銀行口座の預金額を表示して振り込みを行うアプリケーションを作るとして
他の端末から入/出金があるのです定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
でないと額の不整合が起きるからな
このロックして時に振り込みボタンが押されたら当然こっちも振り込み元と振込先の口座をロックしないとダメだろ
でこのロックの順番がテレコになってたら簡単にデッドロックをするって訳
もちろんちゃんとロック順序を考えて組めばいいんだけどでかいシステムをよくわかってないドカタに組ませることを考えたらわざわざそんな危険な構造にする意味がないってこと
前にも書いたけどUIなので超高速で画面のあちこちが更新できても意味ないしな

618 :デフォルトの名無しさん:2017/03/23(木) 21:33:06.10 ID:0wLqn0eU
>>588
寝ぼけるのはいいかげんにしろ。

619 :デフォルトの名無しさん:2017/03/23(木) 21:34:23.52 ID:5A+rvbXC
3行以上はキチガイ

620 :デフォルトの名無しさん:2017/03/23(木) 22:20:43.54 ID:ncdnXTN/
>>617
> 定期的に預金額を更新しようとしたら各口座をロックして値を読み出してロック解除して画面を更新するだろ
そういう糞UIでもつくれるけど、まともだったらやらないよ・・・

621 :デフォルトの名無しさん:2017/03/23(木) 23:30:21.13 ID:u0oYY3Ci
>>620
で、お前はどうやるんだい?

622 :デフォルトの名無しさん:2017/03/23(木) 23:38:12.29 ID:uQaoHdGv
普通は読みだす時はロックなんてしないよw
複数のデータの不整合が問題になる場合は微妙だけど、その場合でも
2回一致するまで読む方が低コスト

623 :デフォルトの名無しさん:2017/03/23(木) 23:39:06.22 ID:uQaoHdGv
っていうか、何でこんなマルチスレッドの初歩みたいな話になってるの?w

624 :デフォルトの名無しさん:2017/03/23(木) 23:47:48.47 ID:Ei+8urX3
てす

625 :デフォルトの名無しさん:2017/03/23(木) 23:50:59.28 ID:Ei+8urX3
>>617
ちげーよ。まあ結論としては、簡単に出来るけどC#はやらなかった、というだけだ。
そして俺はこの選択は間違いだったと見るね。
実装例としては以下。(C#の文法は知らないので真似てみた。適宜脳内修正よろしく)

//ここにコードを書いたのだが、403 Forbidden になるぜorz

mutexを使う場合、mutex確保中に他ロックを取りに行かなければデッドロックはしない。
或いはthread_IDを付けておいて、UIなら直接変更、その他ならinvokeにしてもいい。
いずれにしても、ユーザー側にはinvokeが見えなくなる(隠蔽される)
これの方が良かったと思うよ。いちいち混乱しなかった。

そちらの例は、2人のユーザ間でのデッドロックであって、
俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
なお、解法は、普通に「両方取れなかった場合は一旦全部リリースしてリトライ」でいい。
ただし今時はそれはDB任せで、ユーザ側でのロック管理なんてしない(はず)

626 :デフォルトの名無しさん:2017/03/23(木) 23:52:19.70 ID:FkdET+B0
スレ読み返すと細かいことはどうでもいいけどとにかくInvokeしたくないプロパティでアクセスさせろって暴れてる変な子が居るように読めるんだが
Invokeを適当なプロパティでラップしろで終わる話じゃないのこれ?

627 :デフォルトの名無しさん:2017/03/23(木) 23:53:41.78 ID:u0oYY3Ci
>>622
ケースバイケースだろ
そもそも >>617 は説明のためのサンプルだから不満なら両方書き込みのケースを考えればいいだけ

>>623
マルチスレッドGUIフレームワークに夢見てる奴がいるからでしょ w

628 :デフォルトの名無しさん:2017/03/23(木) 23:54:44.80 ID:Ei+8urX3
>>626
その通りだ。そしてそのコードを貼ろうとしている。
つか、貼らなくても分かるんならもういいね。

629 :デフォルトの名無しさん:2017/03/23(木) 23:57:20.64 ID:u0oYY3Ci
>>625
> 俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
そんなことを言ってるのお前だけ
>>583 をちゃんと読み返せよ

630 :デフォルトの名無しさん:2017/03/24(金) 00:00:02.01 ID:Lq7k+m1v
>>622
そんな力業してないでリーダー/ライターロック使いなよ。
比較のループとかデータ量次第ではCPUパワーの無駄遣いだろ。

631 :デフォルトの名無しさん:2017/03/24(金) 00:07:18.67 ID:P/PrHj1p
既製品に文句があるなら自分で作ってgithub
これができないプログラマはいつまでも三流のまま
コードを書き使ってもらい持論を証明するんだよ

632 :デフォルトの名無しさん:2017/03/24(金) 00:13:35.16 ID:OAgok+ci
Windows Formsの場合は、単純にFormがActiveXコンテナになり得るから、
アパートメントの制限に対応するために用意された、実装上の都合による物だよ

おそらく、ロックの問題ではなく
リソースリークを根本的に解決する方法がないから用意された手続きなんだよ。
ラップして解決できると思うなら、それで良いんじゃないか

633 :デフォルトの名無しさん:2017/03/24(金) 00:14:57.73 ID:gW3AbLz/
だからUIスレッドが気になるなら、wpfでMVVMやれば解決でしょうに

634 :デフォルトの名無しさん:2017/03/24(金) 00:38:36.13 ID:9w5lj4S/
UWPで非同期メソッドとかTask使ってるけどすごい不毛。
非同期メソッドの完了を基本的にはawaitで待つから
非同期メソッドを複数回実行するような場合だと
全部同期呼び出しにして全部まとめてTask.Runしたい。

635 :デフォルトの名無しさん:2017/03/24(金) 00:50:30.06 ID:RtKD05ZR
>>630
俺は622じゃないけど。

従来型のロック機構だとコストが高すぎる場合もあるんだよ。
俺は詳しくないけど、多分Erlangとかの世界で。
mutex等は共有メモリへの書き込みが生じるから実はかなり重い。

636 :デフォルトの名無しさん:2017/03/24(金) 02:13:48.63 ID:5bMFJR3b
馬鹿にマルチスレッド。

637 :デフォルトの名無しさん:2017/03/24(金) 02:33:18.25 ID:99176uAd
結局少しでも重たい処理は全部ワーカーにしなけりゃならないから
UI弄る時だけInvokeした方が見通しすっきりするんだよねw
async/awaitとか使うよりは
ここがUIスレッドですってはっきりわかる。

638 :デフォルトの名無しさん:2017/03/24(金) 02:44:50.15 ID:7cONiVN5
ここはまだWinFormsの時代かw

639 :デフォルトの名無しさん:2017/03/24(金) 02:50:50.13 ID:99176uAd
WPF?誰が使うか
そんなもんが必要なモバイルなら普通にJavaScriptにWebアプリで行くわって感じだねw

640 :デフォルトの名無しさん:2017/03/24(金) 03:11:50.24 ID:m/Lurhmo
>>612
progressBar.Value+=1
としたときに
1.読み込み
2.加算して書き込み
の処理が必要とすると、1と2の間に別スレッドが書き換えを行うことで結果が矛盾する
Interlocked命令を使えばそれは防げるけど、MaxValueを超えないかとかの判定が入るので結局ロックが必要

この程度ならまだしも、裏でWin32やCOMを叩いてるコントロールはさらにややこしい

641 :デフォルトの名無しさん:2017/03/24(金) 03:44:24.59 ID:5bMFJR3b
レベル低すぎて引くわ C#、LINQ、WPFが高速とか言ってたおれ最先端君が戻ってきたのか?

642 :デフォルトの名無しさん:2017/03/24(金) 06:28:32.59 ID:Cpc8yNoh
高速(で書ける)

643 :デフォルトの名無しさん:2017/03/24(金) 07:23:36.10 ID:vGZXBTd1
高速で壊れるの間違いだろ
馬鹿はphp書いてろ

644 :デフォルトの名無しさん:2017/03/24(金) 07:56:00.46 ID:P/PrHj1p
>>640
壊れても遅くてもいいからとにかくプロパティで書きたいというのが要件

645 :デフォルトの名無しさん:2017/03/24(金) 08:24:47.57 ID:gW3AbLz/
データの保証がないコントロールなど、標準品ではありえないから
頑張って作ってくれとしか言いようがないな

646 :デフォルトの名無しさん:2017/03/24(金) 12:55:58.77 ID:99176uAd
>>645
横だけれど、そもそも問題としてValueをインクリメントする事自体が余り良くない考え方かもね。それは表示と処理が分離できていないから。
カウント処理のカウンターはUIがもっているべきじゃない。
別途カウンターを作って、結果だけをUIに代入すべきだ。
このように設計されているなら、破損無視で書き込んでもうまく動作するだろうと思う。

問題は、それをすべての人に要求するのは難しい、自分の忙しくなったらきちんとせずにインクリメントしてるしなw
という事なんだな。

647 :デフォルトの名無しさん:2017/03/24(金) 15:14:34.51 ID:suDsBIm1
やっとまともなやつ来た

648 :デフォルトの名無しさん:2017/03/24(金) 16:13:38.13 ID:m/Lurhmo
>>646
今もそうなってるじゃん
ProgressBarクラスがカウンターを持ってて、ネイティブのmsctls_progress32にメッセージを送って表示を更新してる

ぜひスレッドセーフに再実装してみてくれ

649 :デフォルトの名無しさん:2017/03/24(金) 18:30:43.13 ID:kZHdS/d5
>>646
> カウント処理のカウンターはUIがもっているべきじゃない。
そんな低レベルな話をしてるのは ID:Ei+8urX3 だけだから、お前らもうでてくるな

650 :デフォルトの名無しさん:2017/03/24(金) 19:42:33.91 ID:RtKD05ZR
>>640
> 結局ロックが必要
いや、要らん。正確には、要らない組み方はある。
アトミックはデータを構造体にして参照を持つことで解決出来る。(一発ライト)
レーシングはインミュータブルとCASで解決出来る。x86ならCMPXCHG命令。

具体的には以下。
1. まず有効な値かどうかを先に判定する。(これは今も先にやっているはず)
2. 書き換える場合、元データのポインタをローカルにまず確保する。
3. 上記旧ポインタから参照して、書き込むデータを
new ProgressBarData() で新しく作る。(インミュータブル)
4. 本体のポインタをCAS命令(LOCK付き)で差し替える。
5. 失敗した場合は3からリトライする。(CAS命令の結果に最新ポインタが入っている)

この方法だとメモリを余分に食うけど、ロックは要らなくなる。
(なおErlangは共有メモリ無しで全て通信という別解決方法だった)

いずれにしても、やりようはあるんだよ。どこにコストを掛けるかという話で。
そもそもGUIなんてレーシングしても問題ないようにも組めるし。
(ProgressBar.value += なんて要らない。 = だけでも組める。>>646に同意)
その上で、invokeなんてユーザーに見せる必要あったのか?というのが疑問。
.NETはVC++でも使うから少しでも速い方がいいという需要もあるのかもしれんが、
C#のノリならここは隠蔽して欲しいところでしょ。GUIなんて極限まで速い意味はないし。
ラップしてもいいし、上記のようにロックフリーにしてもいい。
(もちろんユーザがやってもいいんだが、そういう言語じゃないでしょ)

https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%9A%E3%82%A2%E3%83%BB%E3%82%A2%E3%83%B3%E3%83%89%E3%83%BB%E3%82%B9%E3%83%AF%E3%83%83%E3%83%97
https://ja.wikipedia.org/wiki/Lock-free%E3%81%A8Wait-free%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0
つかいつからお前らこんなに馬鹿になったんだ?ふらっとから混ざったのか?
ロックの設計の仕方を知らないのはお前ら全員じゃねーかよ。

651 :デフォルトの名無しさん:2017/03/24(金) 19:51:21.19 ID:9LJ2CaVF
>>650
なーんかしょうもない話を延々続けて頭悪そうだけど、
特に理由がない限りわざわざスレッドセーフに作らないのはGUIに限らんって何度言えばわかるの?

馬鹿なのかほんと

652 :デフォルトの名無しさん:2017/03/24(金) 19:54:06.25 ID:HsxCjAja
>>650
2と3もロックされなければ既に破棄され別の領域として
再利用された誤った情報を読み出す可能性があるだろ

653 :デフォルトの名無しさん:2017/03/24(金) 19:54:24.48 ID:9VMQOfeX
MSにとっての実装コストの問題でもあるしな
MSが苦労するのはいいとしても、その結果激増したバグに悩まされるのはお前らだぞ

654 :デフォルトの名無しさん:2017/03/24(金) 20:07:48.70 ID:RtKD05ZR
>>651
お前がinvokeをウザイと思わなければそれでいい。
俺はinvokeをウザイと思うからMSが隠蔽しとけ、と思う。
多分後者の方が多いだろ、この件に関しては。

>>652
ついにC#がGC言語だと知らない奴も出てきたか、、、

>>653
MSはこの程度ならきっちり実装出来るよ。
というかMSって比較的まともだと思うぞ。

655 :デフォルトの名無しさん:2017/03/24(金) 20:09:50.64 ID:UKoqSEXl
BeginInvokeはどうするの?

656 :デフォルトの名無しさん:2017/03/24(金) 20:15:53.11 ID:RtKD05ZR
というかここでも単発は池沼なんだな。
いちいち言ってることがアレだし。

657 :デフォルトの名無しさん:2017/03/24(金) 20:24:26.17 ID:RtKD05ZR
つかまあ、百歩譲って他のコントロールならいいよ。
ただ、ProgressBarなんてどう考えてもタスクスレッドから書き換えられるのが仕様だろ。
(むしろUIスレッドから書き換えることがない)
それをいちいちinvokeはねーだろ。

せめてProgressBarだけでも対応しとけよと思うだろ普通。

658 :デフォルトの名無しさん:2017/03/24(金) 20:27:59.45 ID:9LJ2CaVF
>>656
アレなのはお前だよ馬鹿...
しかも重症のな。
何度も言うけど、こんなのはweb上にあるようなマルチスレッドの入門記事レベルの話だ。
そもそもスレッドセーフってどういうことなのかすら理解してないし、自分でそういうコードを書いたこともないだろお前。

しかし、こういう馬鹿に限って偉そうなのは何なのかね

659 :デフォルトの名無しさん:2017/03/24(金) 20:32:42.95 ID:RtKD05ZR
皆さん、今からスレッドセーフ大先生の講義が始まります。ご静聴下さい。
ではよろしく>>658

660 :デフォルトの名無しさん:2017/03/24(金) 20:57:32.53 ID:UKoqSEXl
>せめてProgressBarだけでも対応しとけよと思うだろ普通。
ProgressBarを対応させたら○○も対応させろとか言い出す人が出ると思うでしょ普通

661 :デフォルトの名無しさん:2017/03/24(金) 21:56:51.21 ID:vGZXBTd1
馬鹿+偉そうときたから例外を握りつぶすニキだな

662 :デフォルトの名無しさん:2017/03/24(金) 22:04:34.44 ID:vGZXBTd1
ああでも今回はさすがにClickOnceは危険ニキを支持だな

>MSならこの程度はきっちり実装出来る

ここが一番面白かった

663 :デフォルトの名無しさん:2017/03/24(金) 22:13:22.45 ID:RtKD05ZR
つまり、俺が言いたいのは、以下ね。

>>559 > invokeってフォームに限ってどうして必要なのですか?
老害: それがしきたり。
ゆとり池沼連呼リアン>>658: スレッドセーフ!スレッドセーフ!
俺: MSが馬鹿だから。

ゆとりって連呼リアン程度の知能しかないよなマジで。
そもそも俺の>>650>>589(俺ではない)とほぼ同じ内容だぞ。
お前ら馬鹿が付いて来れてないから書き直しただけでね。
お前らが589を最初から理解していればもっとマシな議論だったろうさ。

664 :デフォルトの名無しさん:2017/03/24(金) 22:24:18.31 ID:9LJ2CaVF
だからスレッドセーフじゃないのはControlのメンバだけじゃないって言ってるのに懲りない奴だな
馬鹿なのはMSじゃなくてお前だっての馬鹿

665 :デフォルトの名無しさん:2017/03/24(金) 22:36:30.53 ID:9LJ2CaVF
Control「だけ」がメンバをUIスレッドからしか呼べないとか訳の分からん錯覚をしているのは、
Controlのメンバが非ユーザーコードからも呼ばれることを理解してないからだろうなたぶん

666 :デフォルトの名無しさん:2017/03/24(金) 22:41:45.59 ID:RtKD05ZR
スレッドセーフ君はやはり連呼リアンであったか、、、
お前がそう思うんなら(ry

667 :デフォルトの名無しさん:2017/03/24(金) 22:42:26.38 ID:9LJ2CaVF
馬鹿な上にネトウヨって人生終わってるな

668 :デフォルトの名無しさん:2017/03/25(土) 01:12:27.10 ID:66tFvNtY
>>657
こんなもんで余計なパフォーマンス食われるのも嫌な感じだしね
スレッド無視で叩きこめるならその方がありがたい物ではある。
インクリメント問題くらいならこっちで対処するわって感じですな。

669 :デフォルトの名無しさん:2017/03/25(土) 01:17:38.46 ID:66tFvNtY
ああ、そういえば高負荷バックグラウンドスレッドで
progreassBarの操作をasync/awaitでブチかましてスレッドプール爆発させてた新人いたな(笑)
凄い困ってたけど、きっと何が何だか分からなかったんだろうな。

670 :デフォルトの名無しさん:2017/03/25(土) 01:39:16.42 ID:O6oCv4KM
>>668
そもそもコードの設計論から言ってもワーカースレッドからUIを操作するなんてありえない。
UIに依存するモデルってどんな糞設計だよ。

モデルにSynchronizationContextとか持たせてUIスレッドに同期したイベントで通知させるのは
設計としてありだけど、直接コントロールをいじるとかありえん。

それも気に入らないならUI側が能動的にタイマーでも使ってモデル側を読めばいいだけ。

671 :デフォルトの名無しさん:2017/03/25(土) 04:16:02.72 ID:++OH//Pd
VB上がりにモデルなんて概念ないからw

672 :デフォルトの名無しさん:2017/03/25(土) 09:54:01.33 ID:QDpQza6M
.NETの質問したいんですがここで大丈夫でしょうか?
とりあえずします。
PictureBoxのPaintイベントでImageプロパティを再設定する処理などをしてるんですが
どうもMessageBoxの挙動がおかしくなってます。
フォームより後ろに表示されてしまって操作不能になってます。
とりあえず通常のメッセージボックスの場合はパラメータを弄って強制的に全面に表示させてますが
困るがSaveFileDialogなどで上書き確認のメッセージボックスが表示された時です。
この場合も後ろに表示されてしまって操作できないのでどうしようもないです。
これを回避する方法はどうやればよいんでしょうか?
Paintイベントの中身を消去すれば普通に表示されますが出来ればそのままでメッセージボックスも前面に表示させたいです。

673 :デフォルトの名無しさん:2017/03/25(土) 09:57:11.64 ID:iGx2aDuI
Paintイベント内の処理がおかしいんだろ
俺たちはエスパーじゃないんだから、まずそれがどんなコードか教えてくれよ

674 :672:2017/03/25(土) 09:57:40.89 ID:QDpQza6M
すいません。自己解決しました。
Paintイベントで毎回PictureBoxのImageプロパティを再設定してるのが原因でした
下記のように条件を入れてやるだけで回避できました。
if(pic.Image != img){

}

675 :デフォルトの名無しさん:2017/03/25(土) 09:59:45.97 ID:swqPfyBg
だと思った

676 :デフォルトの名無しさん:2017/03/25(土) 10:45:00.80 ID:omxknQTj
DataReaderを使って
while(await ReadAsync().ConfigureAwait(false)) {
...
}
って書いてるライブラリがあるんだけど
件数が多くなりそうなループでasync/awaitするとタスク生成とコンテキスト切り替えのオーバーヘッドで逆にパフォーマンス悪くなったりしないもんなの?

677 :デフォルトの名無しさん:2017/03/25(土) 11:08:32.17 ID:oe75j5bC
>>676
ReadAsync使う時点でそれらよりデータソース読み取りの方がコスト大と作者が判断しているんじゃないかね
MemoryStreamに対してReadAsyncとか使っているなら知らんけど

678 :デフォルトの名無しさん:2017/03/25(土) 11:09:13.59 ID:kGpqWpaU
>>676
そりゃ呼び出しのオーバーヘッドは増えるだろうけど、それが問題になるかどうかは別だ
パフォーマンスという言葉を安易に使うのはやめよう
君はバッチ処理をしてるのかオンライン処理をしてるのかストリーミング処理をしてるのか、
そのライブラリの方はどういう使われ方を想定してるのか、
処理の規模はどれくらいか
パフォーマンスってのは結果的に目的をどれだけうまく達成できたかであり、一面だけを見て判断できるものじゃない

679 :デフォルトの名無しさん:2017/03/25(土) 11:11:43.78 ID:2T3avjLL
パフォーマンスって何を指してるんだ
処理速度出すためにasync/await使うわけじゃないのは理解しているよな?

680 :デフォルトの名無しさん:2017/03/25(土) 11:13:12.94 ID:2T3avjLL
具体的に何を指すんだと問い詰めたい単語
パフォーマンス
スマート

681 :デフォルトの名無しさん:2017/03/25(土) 12:12:06.97 ID:AJzcpICN
話題が長引いても安心な匿名掲示板「Anontown」 [無断転載禁止]?2ch.net
http://echo.2ch.net/test/read.cgi/tech/1490366833/

682 :デフォルトの名無しさん:2017/03/25(土) 13:35:04.97 ID:66tFvNtY
>>671
とりあえず動くもの作るからな、クリックして必要な事をかける構造になっている以上
次に起こる事は、必然的にスレッドプール爆発なんだわw

683 :デフォルトの名無しさん:2017/03/25(土) 14:21:07.83 ID:pA2Zx06R
馬鹿がプログラムを書かなければ解決

684 :デフォルトの名無しさん:2017/03/25(土) 14:49:04.12 ID:66tFvNtY
そういうヤツはHaskellでもやってろって話だよ
C#はそういう言語じゃない

685 :デフォルトの名無しさん:2017/03/25(土) 15:02:20.11 ID:OnvCww5G
勝手にそういう言語とか決めないで欲しいな
糞袋の観測範囲で

686 :デフォルトの名無しさん:2017/03/25(土) 17:12:28.65 ID:P4wL6N6L
webbrowserのdocumenttextでhtmlを文字列で直接埋め込みたいんですが
ローカルに設置したcssやjsファイルを読み込む方法がわかりません。
どこに配置してどのように読み込めば良いか
ご存じの方教えていただけますでしょうか?
どうぞよろしくお願いします。

687 :デフォルトの名無しさん:2017/03/25(土) 18:18:23.98 ID:gz8AHGhh
Data URIスキームで埋め込むとか

688 :デフォルトの名無しさん:2017/03/26(日) 00:26:03.65 ID:b1vqxh2T
HaskellといえばAI。つまりそういうこと。

689 :デフォルトの名無しさん:2017/03/26(日) 11:09:36.56 ID:WUrKAJma
こんな感じか?
http://livedoor.blogimg.jp/ladymatome/imgs/7/6/76ec3c1e.jpg

690 :デフォルトの名無しさん:2017/03/26(日) 12:41:56.97 ID:Uwt+/Suh
>>670-671
釣りか?マジで言ってるのなら
お前ら別の意味でのスタティックおじさんになってるぞ。
まあC#erなんてそんなもんだと今回思い知ったが。

691 :デフォルトの名無しさん:2017/03/26(日) 13:20:23.73 ID:x9SVAeuT
progressbarなど、多くても100回程度書き換えれば充分なわけで
たかが100回のUIスレッド切り替えでオーバーヘッドとか笑っちまうな
スレッドを無視するより書き換え回数減らしたほうが余程生産的だし簡単だ

692 :デフォルトの名無しさん:2017/03/26(日) 13:20:26.49 ID:hVl7ZVni
>>690
そもそも今時Windowsのデスクトップアプリなんか作ってる時点で
スタティックおじさんであることを自覚したほうがいいよ

693 :デフォルトの名無しさん:2017/03/26(日) 13:24:42.49 ID:TjDGXANh
暴論w

694 :デフォルトの名無しさん:2017/03/26(日) 13:28:02.28 ID:WQ8v1gdY
みんなコード書くよりレッテル貼りの方が得意なんだな

695 :デフォルトの名無しさん:2017/03/26(日) 13:48:27.23 ID:7xcWRiGy
プログレスバーはカウントアップが面倒なのかいつからかグルグルするモードがついたね
ハングアップしてないかわかればまぁいいんでそればかりつかってる

696 :デフォルトの名無しさん:2017/03/26(日) 13:59:10.19 ID:TjDGXANh
いつ終わるか分からない処理もあるから。

697 :デフォルトの名無しさん:2017/03/26(日) 14:02:35.77 ID:Lixhnbpu
>>695
それ追加されたの.Net2.0だから10年以上前だよ

698 :デフォルトの名無しさん:2017/03/26(日) 14:03:21.73 ID:xbLciI4B
鬱陶しいから来週まで続けるなよ
でないとこのスレ埋め立てるからな

699 :デフォルトの名無しさん:2017/03/26(日) 14:13:37.56 ID:Lixhnbpu
4月1日までか…長いな

700 :デフォルトの名無しさん:2017/03/26(日) 14:19:29.01 ID:Uwt+/Suh
つかお前ら落ち着けw

俺は>>650だよ。そして>>640含むお前ら大多数よりは賢いことはもう示したろ。
で、>>670-671も同様にアホっぽく見える。
しかしマジでそう思っているのなら、それを示せば多少は教えてやるよ、ということだ。
何か最近、煽ったりカニンガムの法則を試しているような奴も多いんでね。
それに付き合わされるのはウザイ。

俺の意見は ID:Un9Q+jtZ とは完全には一致はしないが、
6割くらいは一致するし、彼が何を言いたいのかは分かる。
既に言ったとおり、650も>>589の代弁に近い訳でね。
お前らは>>597(重ねて言うが俺ではない)の意味を理解出来ていないように見える。

そこでお題を出してやる。
これをお前ら流の「美しい実装」をする方法を述べてみろ。
駄目出ししてやるよ。

フーリエ変換をする関数 calc_FFT があって、
計算に時間がかかるので、プログレスバーに進捗状況を表示したい。

参加する人はどうぞ。

701 :デフォルトの名無しさん:2017/03/26(日) 14:24:02.60 ID:13fTqv5I
>>700
まだやる気かよ。
だからねえ、そういうのは>>670に書いた2つのやり方のどちらかを選択するのが普通。

どんな方法論を取るにしろ、モデル側から直接UI部品をいじるとかありえない。
依存方向は一方通行にするなんて基本中の基本だろ

702 :デフォルトの名無しさん:2017/03/26(日) 14:32:06.72 ID:13fTqv5I
この元の話題、つまりUI部品のメンバーがUIスレッドからしかアクセスできないように
なっているのは不合理かどうかって話も、はっきりいって問題提起した奴が何も分かってない馬鹿なだけ。

こういう仕様は十分に合理的。

703 :デフォルトの名無しさん:2017/03/26(日) 14:55:35.58 ID:V5FfYo93
だからVB上がりにモデルなんて概念はないって言ってんだろが
通じない話を繰り返すな
壊れて向きが変わらなくなったチョロQかテメー

704 :デフォルトの名無しさん:2017/03/26(日) 15:00:04.71 ID:7VPGG3Vy
モデル概念を知らないおじさんや初心者以前に
エキスパートからしてみてもC#を使いたい動機は素早く手軽に組みたいという動機にあるからね。
時間をかけてガチガチにやらないかぎり上手くいかないとか、それは勘弁願い下げたよな。

705 :デフォルトの名無しさん:2017/03/26(日) 15:09:11.18 ID:N/oWszN2
うぇーゴミ虫の狭い観測範囲で勝手にC#ユーザーの動機を定めちゃう?
いくら寛容な人間様でも下等生物と一緒にされるんでは不愉快ですわ

706 :デフォルトの名無しさん:2017/03/26(日) 15:14:26.60 ID:7VPGG3Vy
お気に召さなければC++でも使ってみたらどうよ?
templateメタプログラミングならなんでもお望みの書き方でできるよ。

707 :デフォルトの名無しさん:2017/03/26(日) 15:37:28.26 ID:Uwt+/Suh
ちなみに、回答は後日ね。
こういうのは急いで出来る必要はないから、じっくり考えてみてよ。
当たり前だが俺は>>670-671よりもマシな解決方法を持っている(つもり)


>>701
採点結果: スタティックゆとり乙

君はどういう依存が悪いのかを理解出来ていない。
そしておそらくUIはスタティックだと信じている。

ただしMSも同様に馬鹿だった。だからFormは糞なのも事実。
しかし世の中には他の実装方法もあるって事さ。
君達がロックフリーの世界を知らなかったようにね。

ヒントとしては、
> どちらかを選択する
ここが間違っている。
何通りも用意するとか、ラップして変換するとかは、明らかに無駄だよね。

708 :デフォルトの名無しさん:2017/03/26(日) 15:46:45.12 ID:bdiJ1zQR
>壊れて向きが変わらなくなったチョロQかテメー

斬新な煽り方だなw

709 :デフォルトの名無しさん:2017/03/26(日) 16:30:36.77 ID:E6fNHh8L
ネトウヨとかもそうだけど、頭悪い奴に限って、

「この俺だけが世の中の真実に覚醒した!!!この世は嘘と欺瞞にまみれていて(笑)
俺以外の連中は馬鹿ばかりだ!!!」

ってなるのは何なのかね。
まあ2chにはこういう単細胞で自分を客観的に見られない奴いっぱいいるけど、
>>707みたいにそういうタイプはプログラマとか知的な仕事についてはいけない人だよな本来

710 :デフォルトの名無しさん:2017/03/26(日) 16:33:32.75 ID:7VPGG3Vy
彼が相手している誰かさんの方がむしろヤバイという客観的印象ありなんですけどねw

711 :デフォルトの名無しさん:2017/03/26(日) 17:00:26.56 ID:nZrkbKSG
ロックフリーおじさんはスタティックおじさんを馬鹿にできんだろ
○○おじさんが馬鹿にされる本質は金のハンマー信仰にあるのだから

712 :デフォルトの名無しさん:2017/03/26(日) 17:09:41.70 ID:E6fNHh8L
銀の弾丸を求める者は少なくとも倒すべき「怪物」の存在には気が付いているが、
彼はそのレベルにすら達してないよたぶん。

背後にあるトレードオフに気が付かないから不条理でないものが不条理に見えてしまう
自分の馬鹿さ加減を自覚できないだけ

713 :デフォルトの名無しさん:2017/03/26(日) 18:57:25.59 ID:iTS+fWTZ
>>700
ダメ出しなんて要らん
どや顔で語りたいならぐうの音もでない実装を晒しやがれ

714 :デフォルトの名無しさん:2017/03/26(日) 19:11:26.31 ID:iZtP8D0n
初歩的な内容ですが。
RxのISchedulerインターフェースを実装したいのですが、ScheduleメソッドのDateTimeOffsetを引数にとるオーバーロードとTimeSpanを引数にとるオーバーロードって
どのように実装すればいいのですか。
本家Rx.NETのリポジトリにあるコードをいくつか見ましたが、
なんとなく、指定された時間の分だけ遅延させて
デリゲートをInvokeさせるというのは分かりましたが、この2つのオーバーロードの具体的な実装方法を文章で書いてあるところを教えてください。
あと、戻り値がIDisposableなんですけど、これはスケジュールの解除を行うDisposableでいいですよね。

715 :デフォルトの名無しさん:2017/03/26(日) 20:02:08.99 ID:YTmW3NMW
>>707
利根川さんきたーーーーw

716 :デフォルトの名無しさん:2017/03/26(日) 20:06:43.37 ID:Uwt+/Suh
>>713
俺は語りたいわけじゃない。
だから君の意見を尊重して、俺の答えは書かないことにするよ。

君らは一生馬鹿なままで過ごせばいい。
C#にとどまっている限り、回りもみんな馬鹿だから、ばれないで済むだろう。

ただ、知っている奴が見たら、お前らは本当に間抜けなことをしている。
だけど、そういうのは自分でいろいろ考えないと身につかないんだよ。
だから自助努力する奴に対してはサポートしてやろうとしただけ。
とはいえ、俺の案も他言語では普通に使われる手だから、探せば出てくるはず。
それは君たちで探すんだね。

俺はくだらない煽りには本当に辟易している。
そのエネルギーは正しくプラスの方向に使うべきだよ。
マイナス方向に使って煽るのではなくてね。

君は何がしたかったんだ?
俺の面目を潰したかったのなら、俺より素晴らしい実装を先に言ってしまえばよかっただろ?
或いは他の人から、もっと素晴らしい実装が出てきたら、君にも糧になっただろ?
そうやってプラスの方向にお互いに高めていくべきなんだよ。
それを、「じゃあ教えてやらない」と言われる話の振り方をしてしまうから、
ゆとりはゆとりのままなんだよ。

聞くは一時の恥、聞かぬは一生の恥、だよ。
こんな匿名のところですら面子を重視しているうちは一生ゆとりだよ。

717 :デフォルトの名無しさん:2017/03/26(日) 20:09:36.55 ID:XWnO8Cg2
めっちゃ早口で言ってそう

718 :デフォルトの名無しさん:2017/03/26(日) 20:52:30.96 ID:iTS+fWTZ
なぜかバカって無駄な長文書くんだよな
こういう奴が書くコードも推して知るべしなんだろうな w

719 :デフォルトの名無しさん:2017/03/26(日) 21:11:54.02 ID:DeCVSWGu
そういうのも馬鹿っぽいよ。中学生か。
問題なのは言ってることが正しいかどうか、それだけ。
長文かどうかなんてそれとまったく関係がない。
彼はトンチンカンな勘違いをしてるから馬鹿にされてるだけ。

720 :デフォルトの名無しさん:2017/03/27(月) 00:01:17.74 ID:rNkb8v7V
日本語理解できないアホ?
頓珍漢なこと書く奴ってたいてい長文だろって話だぞ

721 :デフォルトの名無しさん:2017/03/27(月) 00:14:45.53 ID:qUMQbQ0X
馬鹿な奴だ。
馬鹿の世界ではきっとすべての事柄が三行以内の短文で表現できることになってるんだろうね。
己の無学を語るに落ちてるな

722 :デフォルトの名無しさん:2017/03/27(月) 00:18:01.70 ID:rNkb8v7V
誰もまともなこと書く奴が長文ではないって言ってないんだが w
逆とか裏とかを理解してないのってプログラマーとして致命的じゃね?

723 :デフォルトの名無しさん:2017/03/27(月) 00:19:42.90 ID:wneB9bMR
じゃあ一行で。スレタイ読め。

724 :デフォルトの名無しさん:2017/03/27(月) 04:02:24.71 ID:UZsp8jX5
>>716
せっかくなので教えて欲しい
ちょっと考えたけど、やっぱりMaximumとMinimumがValueの変換中に変わるときとかが結構めんどくさい
あと、オーナードローや継承が安全にできることも必要か

プログレスバーのValueだけどかならともかく、コントロール全部をスレッドセーフにとかは非現実的なんじゃないか?
実際近年やってるところは少し調べた限り無いし

725 :デフォルトの名無しさん:2017/03/27(月) 04:51:00.01 ID:FSqhbRGK
>>714
誰も触れてくれなくて草

726 :デフォルトの名無しさん:2017/03/27(月) 05:02:30.31 ID:rNkb8v7V
>>723
>>700 に言えよ w

727 :デフォルトの名無しさん:2017/03/27(月) 14:11:21.66 ID:H4MLQPNT
>>725
まあ正直今時Rxかよwwwwww
と草生えるからな
保守案件かも知らんが御愁傷様だ

728 :デフォルトの名無しさん:2017/03/27(月) 15:09:08.98 ID:OggmZorO
そもそもRxって今は.NETの一部じゃなくてサード扱いだからな
知ってるのが当然みたいに言われても困る
.NET Fx以外の個別のライブラリについてはスレ違い

729 :デフォルトの名無しさん:2017/03/27(月) 22:59:41.60 ID:ty5ByWfa
>>690
スタティックおじさんって誰よ?

730 :デフォルトの名無しさん:2017/03/27(月) 23:14:42.86 ID:53TkDvRN
スタティックジジバンドのリーダーだよ
知らなかったのか

731 :デフォルトの名無しさん:2017/03/27(月) 23:28:21.19 ID:c1Kh3EUH
もう今ならスタティックの悪い使い方を知ってるほうがおじさんな気がする……

732 :デフォルトの名無しさん:2017/03/27(月) 23:52:27.87 ID:dYBhOZra
性的

733 :デフォルトの名無しさん:2017/03/28(火) 07:20:39.72 ID:1WRXezaS
>>712
不二痛のノンプログラミングツールの
販促で 銀の弾丸を求めて とか
書いてあったの思い出した

あんな大手企業がスゲー認識してるなと思った

734 :デフォルトの名無しさん:2017/03/28(火) 08:08:28.90 ID:W2JaqSVc
ラズパイでMVCのwebアプリって動かせますか?

735 :デフォルトの名無しさん:2017/03/28(火) 16:32:12.10 ID:WR7Bj+dr
Windowsがまともに動きゃ動くだろ

736 :デフォルトの名無しさん:2017/03/30(木) 00:54:43.35 ID:8DsEMtOy
.NET CoreならWindowsじゃなくても動くんじゃね

737 :デフォルトの名無しさん:2017/03/30(木) 01:35:10.25 ID:DtnWdi8P
ARMで動くのか?

738 :デフォルトの名無しさん:2017/03/30(木) 01:58:32.69 ID:Qg6ZUcGU
Formのコントロールのイベントに紐づけしたFormのメソッドって
Formが閉じられた後も紐づけしたままだとお漏らしになるんだっけ?

739 :デフォルトの名無しさん:2017/03/30(木) 02:50:16.54 ID:DVY8Bk9i
>>737
動くよ、ググってみ

740 :デフォルトの名無しさん:2017/03/30(木) 06:49:49.86 ID:U97Tvha+
>>738
ならない

741 :デフォルトの名無しさん:2017/03/31(金) 09:35:08.92 ID:YcsHI68o
UI AutomationでVB6で書かれたレガシーなアプリのUIテストをしたいのですが、
操作したいコントロールの多くに一意のAutomatinIDが割り当てられていません。多くのコントロールのIDが1や2になっています。
一応、コントロールの順番が変わらないものと決め打ちして操作したいコントロールを特定することは可能なのですが、不便です。
もっとうまいやり方ってありますか?
後は表示位置を元に特定するくらいしか思いつかないのですが。

AutomationIDって、少なくともVB6では自分で設定できないのでしょうか。
一応このレガシーアプリのソースコードはあり、編集も可能なのですが、
AutomationIDというのを設定するところは見当たりません。

742 :デフォルトの名無しさん:2017/03/31(金) 14:28:02.89 ID:gIiQslt6
スレチ

743 :デフォルトの名無しさん:2017/03/31(金) 19:34:04.77 ID:BtloYTx6
ASP.NET MVCなんですが

DBに処理対象データがあるか確認
__ある場合:メッセージボックス(*件処理します。処理を続けますか?)
____はいの場合:データ更新処理
____いいえの場合:なにもしない
__ない場合:メッセージボックス(データがありません)

こういう処理を非同期リクエストを使わずに実装したいのですがどうすればいいでしょうか
入力フォームの内容もクリアされないようにしたいです

744 :デフォルトの名無しさん:2017/03/31(金) 19:36:51.55 ID:kI20EOUu
簡単だよ

745 :デフォルトの名無しさん:2017/03/31(金) 20:45:16.64 ID:BtloYTx6
>>744
教えてください
お願いします!

746 :デフォルトの名無しさん:2017/03/31(金) 21:59:00.75 ID:wAJQEnGm
なぜそんなことを他人に聞かないとわからないのかわからない。

747 :デフォルトの名無しさん:2017/03/31(金) 22:08:53.88 ID:PPRsLJ2Y
>>740
遅くなったけどありがとう
やっぱりそうか

748 :デフォルトの名無しさん:2017/03/31(金) 22:10:11.37 ID:9w4qNkVe
>>743
正直おまえキモイ

749 :デフォルトの名無しさん:2017/03/31(金) 22:38:20.66 ID:BKtRT3pJ
>>743
フォームの入力内容を書き戻すのに加えて、確認中であることを示す値を入れたhiddenフィールドと
$(function() { if (confirm(msg)) $("#form").submit(); });
みたいなスタートアップのスクリプトを仕込んで返せばいいんじゃないの
俺ならこんな汚物を出してきたら差し戻してAJAXで書き直させるけど

750 :デフォルトの名無しさん:2017/04/01(土) 19:08:34.68 ID:iJwskPQ3
while(true)
{
Console.Out.WriteLine("氏ね");
}

751 :デフォルトの名無しさん:2017/04/01(土) 19:15:59.90 ID:4r7Zvrb2
標準出力とか久々に見たわ

752 :デフォルトの名無しさん:2017/04/03(月) 13:09:41.47 ID:sZC7W3vJ
aspでviewだけをデザイナーに触らせたいんだけどどうすればいいの?
view以外(controllerとか)のソースを弄られたくないし見せたくもない

753 :デフォルトの名無しさん:2017/04/03(月) 13:48:10.33 ID:YcnJ2dMt
フォルダにアクセス権限でも付けとけや
スレ違い

754 :デフォルトの名無しさん:2017/04/03(月) 14:12:13.73 ID:sZC7W3vJ
こういうプロジェクトの共有(共同開発)は出来ないのですか?

755 :デフォルトの名無しさん:2017/04/03(月) 14:18:51.99 ID:G0J69e58
普通にできるが

756 :デフォルトの名無しさん:2017/04/03(月) 15:39:57.58 ID:sZC7W3vJ
普通にはできませんでした

757 :デフォルトの名無しさん:2017/04/03(月) 19:12:16.74 ID:zJguOVHN
>>752
それならREST APIで良いんじゃないか
RazorというかサーバーサイドのHTMLテンプレートはもう時代遅れだから思い切って捨ててしまえ

758 :デフォルトの名無しさん:2017/04/03(月) 20:15:16.37 ID:YcnJ2dMt
WebAPIを使った動的ページの開発ができる有能なデザイナならソース隠す必要ないだろ
むしろバックエンドも含めて全部そいつ一人に作らせた方が早いんじゃないか

759 :デフォルトの名無しさん:2017/04/03(月) 20:38:02.81 ID:DvppQH2R
わろたw
ビューのソースファイルだけ渡してデバッグできない状態で作らせるか
テンプレート関連の読み込み処理を自前にするしかないだろうな
もともとc#のtemplate使ってるから自前もわりと簡単だよ

760 :デフォルトの名無しさん:2017/04/03(月) 22:10:44.51 ID:zJguOVHN
冷静になって考えるとモックコントローラー作るだけだったわ

761 :デフォルトの名無しさん:2017/04/11(火) 23:45:38.38 ID:f9LqqWjR
バイト配列を並列で0クリアしようと思ったんだが、なんかほぼ変わらない
なにか間違ってるんだろうか?

public static void Main()
{
var methods = new Action<byte[]>[] { ArrayClear, ConcurrentClear };
for (var i = 0; i < 5; i++)
foreach (var method in methods)
{
var sw = Stopwatch.StartNew();
var buffer = new byte[64 * 1024 * 1024];
var random = new Random(0);
random.NextBytes(buffer);
method(buffer);
Console.WriteLine(method.GetMethodInfo().Name + ": " + sw.ElapsedMilliseconds);
}
}

private static void ArrayClear(byte[] buffer)
{ Array.Clear(buffer, 0, buffer.Length); }

private static void ConcurrentClear(byte[] buffer)
{ var t0 = Task.Run(() => Array.Clear(buffer, 0, buffer.Length / 2));
var t1 = Task.Run(() => Array.Clear(buffer, buffer.Length / 2, buffer.Length / 2));
Task.WaitAll(t0, t1); }

762 :デフォルトの名無しさん:2017/04/11(火) 23:59:42.35 ID:WDRtNXIn
>>761
なんでそんなクソ遠回りなことやってんのか知らんが
Taskでパラレルやるなら引数渡せ

763 :デフォルトの名無しさん:2017/04/12(水) 00:22:54.01 ID:QhQPiH2H
>>761
少し考え違いをしていると思う、並列処理は分割すればするだけ速くなるような代物じゃないし
粒度が細かすぎる、Taskは並列というより並行処理向け。同配列に対する処理などはCPUよりGPGPU向き
―だがそれより何より、その計測された時間のほとんどは配列生成と乱数格納に費やした時間だ

764 :デフォルトの名無しさん:2017/04/12(水) 00:52:15.63 ID:PvBuykCK
毎度思うけど命令口調のバカ何なのかねw

765 :761:2017/04/12(水) 02:52:03.74 ID:E1U6B9R0
>>762
Parallel 使えってことかな?

>>763
あ、乱数生成の時間まで入れてたのか
でも乱数生成分入れないようにしても、どっちも同じような時間なのは変わらない

バイト配列キャッシュ作ってるんだけど、1GBぐらいの超巨大配列の初期化に
Task の生成や切り替えに数msec使っても、効果があると思ったんだ

分割すればするほど速くなるとは思ってないけど、
2分割程度なら速くなって当然と思ってるんだけど

766 :デフォルトの名無しさん:2017/04/12(水) 03:38:43.21 ID:QhQPiH2H
>>765
オーバーヘッドはご存じか、C#の場合はネイティブスレッドのそれほどでも無いだろうけど
ただ…結局この場合だと演算が皆無でメモリストアに割食って無意味って所だろうか(範囲が被るほど速い

767 :デフォルトの名無しさん:2017/04/12(水) 06:57:20.84 ID:uWep8obc
メモリーアクセスがボトルネックになってるだけじゃねーの?

768 :デフォルトの名無しさん:2017/04/12(水) 07:57:27.76 ID:A6XRqe5e
常識的に考えて、ボトルネックはNextBytesじゃないかなw

769 :デフォルトの名無しさん:2017/04/12(水) 11:23:50.73 ID:E1U6B9R0
>>766, 767
なるほどメモリアクセスかー

Taskの切り替えや待ち時間などのオーバーヘッドはご存知よ
書いたとおり、Taskをふたつ待つ程度のオーバーヘッドは数msec

NextBytesを計測から外し、1GBで0クリアを試してみたら、150msec前後かかった
レートだと 6700MB/sec ぐらい
実行環境は DDR3-1333 なんだけど、理論値 10667MB/sec
途中GC入ってたし、こんなもんかー

770 :デフォルトの名無しさん:2017/04/12(水) 11:40:08.42 ID:7YKbJJVc
byte(IntPtrじゃない)の配列のアクセスでそんなにHWの理論値に近い数字が
出る訳ないと思うよw

っていうか理論値はあくまで純粋にHWの転送能力であってCPUが介在する場合は
そんな値絶対出ないし

測定値、計算のどちらかまたは両方が間違いなく間違ってるw

771 :デフォルトの名無しさん:2017/04/12(水) 12:09:07.27 ID:E1U6B9R0
>> 770
Array.Clear() って .NET Core の内部ではポインタ幅(64bit?)で0クリアしてたよ
端っこはバイト単位での0クリアだったけど

// now write pointer sized pieces
size_t nPtrs = (endBytes - memBytes) / sizeof(PTR_PTR_VOID);
PTR_PTR_VOID memPtr = (PTR_PTR_VOID) memBytes;
for (size_t i = 0; i < nPtrs; i++)
*memPtr++ = 0;

GC発生しないようにバッファ使い回してみたら、7000〜8000MB/sec くらいだった
理論値でるとも言ってないし、7〜8割なら測定値、計算ともに妥当じゃない?

772 :デフォルトの名無しさん:2017/04/12(水) 13:46:41.47 ID:PeioJu3J
(byte配列ならnewした時点で既定値(則ち0)で埋められてるだろ、と言ったらあかんのか?)

773 :デフォルトの名無しさん:2017/04/12(水) 14:05:20.61 ID:OIzgc8H/
>>772
そりゃ実験のためのコードだからね
何のためにこんなこと試すのかわかんないけど

774 :デフォルトの名無しさん:2017/04/12(水) 14:11:16.09 ID:E1U6B9R0
>>772
LOH(約85000バイト以上のオブジェクト)は仮想メモリ空間のフラグメンテーションを発生させるので、
OutOfMemoryException が発生しやすくなる

巨大バッファをガンガン使いまわすアプリは OOMを防ぐため、
バッファをキャッシュして使いまわす必要があったのね

んで、キャッシュしてたバッファを使うときに高速に0クリアしたいってのが、今回の大元でした

775 :デフォルトの名無しさん:2017/04/12(水) 18:50:16.39 ID:IE9Tc5o9
配列のメモリークリアみたいな物はマルチスレッド化しても高速化しないだろうね
原理的にサイズが大きくても高速化しないと思われる

776 :デフォルトの名無しさん:2017/04/12(水) 19:03:44.50 ID:0XMPUeTg
15年前のシングルコアのプロセッサーが当たり前の時代ならその通りだけど、
今日的にはそんなこともないんじゃないの?

たとえ物理メモリーは排他的にしかアクセスできない制約があるにしろ、
並列化の効用がまったくないとも思えん

777 :デフォルトの名無しさん:2017/04/12(水) 19:08:41.74 ID:giyYheDf
むしろCPUキャッシュに左右されんじゃねのか
環境でばらつきまくって計測の意味もなさげ

778 :デフォルトの名無しさん:2017/04/12(水) 19:51:51.86 ID:QhQPiH2H
とりあえずWindowsマシン@4.6.2で色々試してみたら

[SuppressUnmanagedCodeSecurity, DllImport("kernel32")]
extern static void ZeroMemory(byte[] Destination, IntPtr Length);

[SuppressUnmanagedCodeSecurity, DllImport("msvcrt", CallingConvention = CallingConvention.Cdecl)]
extern static void memset(byte[] _Dst, int _Val, IntPtr _Size);

とかした方が雀の涙ほど速かった、CILだと

ldarg.0
ldc.i4.0
ldelema uint8
ldc.i4.0
ldarg.0
ldlen
initblk

あたりで漸く同等、しかも64bitに限った話、32bitだとどれも誤差レベル

779 :デフォルトの名無しさん:2017/04/12(水) 21:18:24.58 ID:u533e0uw
>>776
ほとんどメモリーアクセスしかないのに高速化できるわけないだろ

780 :デフォルトの名無しさん:2017/04/12(水) 21:45:31.51 ID:0XMPUeTg
>>779
高級言語のコード上はそうでもCPUの実際の動作はそうじゃないよw

781 :デフォルトの名無しさん:2017/04/12(水) 21:56:27.84 ID:5KMe1hi6
どう動いてるんだ?

782 :デフォルトの名無しさん:2017/04/12(水) 23:32:44.30 ID:7AJloho+
>>780
はあ?
メモリーアクセス以外のどんな動作があるんだよ w

783 :デフォルトの名無しさん:2017/04/12(水) 23:49:21.06 ID:fn4L3E2o
仕組み判らないけどメモリをキャッシュしてる場合
同じキャッシュ単位内に同時に書き込みできるものなのか?

784 :デフォルトの名無しさん:2017/04/13(木) 00:14:45.08 ID:Vv6BlwOK
使うときに必要な分だけ0クリアじゃだめなんか?大量にバッファを0クリアする場面が思い付かん。

785 :デフォルトの名無しさん:2017/04/13(木) 00:38:14.37 ID:px7lD0L1
>>782
DMAでも使ってない限り、少なくともポインタのインクリメントとループの終了条件のチェックは入る

786 :デフォルトの名無しさん:2017/04/13(木) 00:57:14.48 ID:G9tlFT6D
>>785
x86にはストリング命令というチートが有ってだな

787 :デフォルトの名無しさん:2017/04/13(木) 01:07:16.95 ID:px7lD0L1
あ、ポインタは自動インクリメント付きの命令が使えるかも

788 :デフォルトの名無しさん:2017/04/13(木) 01:22:49.09 ID:sVC5qkLg
>>784
つ GC

>>783
Core i7 2600 4Core Sandy Bridge とかだと、CPU-Z とかのツールで見てみると
L3 キャッシュまで搭載していて、
・L2 は 256KB が 4コア分
・L3 は 8MBひとつ
なので、L2間でコア間のキャッシュコヒーレンシ(一貫性)を解決してるはず
キャッシュライン(64Byte)ごとに他のコアで書き込みがあるかとかをチェックしてる

同時の書き込みもちゃんと検知されている
キャッシュラインで競合すると書き戻しとかが発生するので、
重ならないようにするのがいいらしい

789 :デフォルトの名無しさん:2017/04/13(木) 01:23:52.75 ID:DHabuNl5
そもそもrep stosb云々とか以前に、命令のクロックサイクルなんかより
メモリレイテンシがデカすぎて取るに足らないって事よ、コヒーレンシの実装にも左右されそうだし
1つのバカでかいバッファより、バッファ自体を分割したほうが良いんでないか

790 :デフォルトの名無しさん:2017/04/13(木) 01:44:29.44 ID:G9tlFT6D
スレッドをいくつ作ろうが、単純な0クリアだからキャッシュ内のメモリーを処理する速度がキャッシュとメモリーの転送速度より早くなり
CPUはキャッシュが満たされるのを待つ必要があるから頭打ちになるってことかね

791 :デフォルトの名無しさん:2017/04/13(木) 03:28:18.29 ID:NHsAQDrp
WinFormsはif文やっと覚えましたってレベルでも
有名なサイトのコピペで目的のもの作れたが
WPFはデリゲートや非同期を熟知してないと一歩も進めない感じ
コピペしたくても自由度が高く手法が多すぎて無理

792 :デフォルトの名無しさん:2017/04/13(木) 05:44:30.50 ID:FNNFGlTu
今のCPUなら1CPUでも、連続0書き込みなんかしたらメモリーの速度を圧倒してしまうからな
マルチスレッドなんかにしたら、そのオーバーヘッドが邪魔してかえって遅くなるだろう

793 :デフォルトの名無しさん:2017/04/13(木) 06:14:59.28 ID:wfOumNdE
CPUの実際の動作がさっぱりわからん

794 :デフォルトの名無しさん:2017/04/13(木) 06:22:05.68 ID:vvMMmk8r
気にしなくていい

795 :デフォルトの名無しさん:2017/04/13(木) 06:53:09.50 ID:DSZn496T
>>785
おっさんいつの知識で語ってるんだよ w
そんなもん主記憶への書き込みに比べたらゴミにしかならんぞ

796 :デフォルトの名無しさん:2017/04/13(木) 07:19:52.20 ID:FNNFGlTu
>>793
CPUというよりも、CPUとメモリーのスピード差が決定的すぎるんだよ
メモリーにアクセスするとCPU命令で数千命令程度の待ちが入る
余りに待ちが長いので、その間に色々計算ができるようにCPUには工夫が入っていたり
マルチCPUにして、別のCPUが計算している間に書き込んでしまえといった方面で創意工夫がされているんだ。
境界チェックくらいなら、書き込み待ち時間で十分にできるから他のCPUにまで影響を与えないようにして
書き込みスレッドは一本にして、他のCPUは別のメモリーアクセス以外の仕事ができるように開けておいた方がトータル良い結果を出すって事。

797 :デフォルトの名無しさん:2017/04/13(木) 08:39:19.14 ID:2TLG8dmE
どうでも良いが、メモリーに書き込まないスレッドとかありえないと思うんだ・・・

798 :デフォルトの名無しさん:2017/04/13(木) 10:17:04.48 ID:xhr4sxE5
本当に小規模な計算ら、レジスタだけで解決できるだろう

799 :デフォルトの名無しさん:2017/04/13(木) 13:14:58.98 ID:mVrmFNTT
C++ならともかくC#で気にする必要のあることなんだろうか

800 :デフォルトの名無しさん:2017/04/13(木) 13:31:22.91 ID:FNNFGlTu
>>799
知っていれば無意味な並列化とかしなくて済むだろ
そうすればソースも分かりやすくすっきりするし
0フィル処理なんて詰まらない処理なら、効果はてきめんだ。

801 :デフォルトの名無しさん:2017/04/13(木) 13:43:29.67 ID:xhr4sxE5
無意味な並列化にかかる工数と、無意味な並列化は逆効果ということを検証する工数
どちらがよりコストがかかるんだろうか。

802 :デフォルトの名無しさん:2017/04/13(木) 13:49:55.01 ID:FNNFGlTu
高速化目的で並列化しなきゃならない程の状況なら、検証はするだろ。
で、並列化するときにどういう方向性が効果的かってのを知っておくことは
コードを手早く書く上での基本テクニックだよ
無意味なコードは、そもそも書かないし試さないというショートカットができるからね。
将棋の名人でもすべての手を読んでいる訳じゃない、効果的な枝だけを深読みしているみたいなもんだ。

803 :デフォルトの名無しさん:2017/04/13(木) 14:09:41.46 ID:xhr4sxE5
並列化をしたくなるのは、代替がそういう状況に陥る前の段階での思いつきなんだよねたとえば今回の0フィルとか。

804 :デフォルトの名無しさん:2017/04/13(木) 16:09:48.66 ID:aK+zC0HQ
並列化の基本はいかに粒度を上げるかだよ
極端な話、プロセスを2つに増やして2倍速くなるならそれでいい
ミクロな視点で考えるのはほとんどのケースにおいて時間の無駄

805 :デフォルトの名無しさん:2017/04/13(木) 16:28:44.49 ID:FNNFGlTu
>>803
こういうのってコンピュータの仕組みが分かってしまえば、高速化手法として頭に浮かぶことすらないですから。
考えるまでもなく除外なんですよ、脊髄反射。
よく似た物にページングのチューンなんかがあるね。
並列化したら、ずっと仮想メモリにページアウトページインばっかりするようになってしまうのが見え見えのコードとかね。
こういうケースが見えて居る時にマクロ視点でプロセス増やして・・・と考えることは無いねw

806 :デフォルトの名無しさん:2017/04/13(木) 18:05:14.12 ID:sVC5qkLg
>>805
コンピュータの仕組みなんて常に変わっていくもの
脊髄反射で手法を除外するのはよくない

あと一レス目で指摘するならともかく、問題点が整理されてから
後出しで手法をダメ出しするのはカッコ悪い

807 :デフォルトの名無しさん:2017/04/13(木) 18:18:41.10 ID:xmE6C1ua
>>796
それってCPUの実際の動作じゃなくて単なる考え方だよね・・・

808 :デフォルトの名無しさん:2017/04/13(木) 18:34:37.22 ID:2TLG8dmE
と、言うより>>796は思いっきり出鱈目ですわ
境界チェック云々はマルチCPUじゃなくてパイプラインで解決されるからプログラミング要らずだし

809 :デフォルトの名無しさん:2017/04/13(木) 19:49:41.71 ID:woBc/tdN
>>79
> メモリーにアクセスするとCPU命令で数千命令程度の待ちが入る
今時のメモリー(主記憶)のレイテンシーって10ns以下だと思うが10nsで1,000命令も実行できるCPU教えてくれ

810 :デフォルトの名無しさん:2017/04/13(木) 20:53:44.12 ID:FNNFGlTu
>>808
まぁ、その手の事を指摘したつもりだけれどそう読んではくれないみたいだね。
あと、最近のはパイプライン以外にも命令の並べ替えやら入っているからw

ホコポコ無意味に返信している内容は、多分自演なんだろうけど、そろそろやめたら。
こういうのはゲーム作ったことあるような人間なら常識の範囲なので、考えるまでもないような話の類。
俺以外のヤツもたくさん指摘しているが、それだけ普通に知っている人は多い話なのだよ。

811 :デフォルトの名無しさん:2017/04/13(木) 21:04:00.56 ID:1tPgrneG
いつの時代のどのハードのゲームだよ
アセンブラのバイトコード気にするとか20年前の話だろ

いっぽかたが計算してる間に他のCPUで書き込みするのは
同時にメモリに書き込もうとして競合するのを避けるためじゃないん

812 :デフォルトの名無しさん:2017/04/13(木) 21:15:04.20 ID:FNNFGlTu
しつこいねぇ
この手の話をゲーム屋が知ってるのは、何かの本で読んだとかではなくて
ソニーとか任天堂とかマイクロソフトとか今は逝ってしまっているセガとかハード屋が
セミナーで現在のハードの状況と止めた方が良いコードなんかのヒントとして教えてくれるからなんだよ。
その知識を持って、インテルの資料とかを読めば大体の事は分かるんよ。
もちろん素から勉強している人も居るだろうけどね。

今回の話はマシン語ではなく、最近のメモリー事情の話なんだよ。
連続アドレスの書き込みor読み出しには強いが、飛び飛びのアドレスにアクセスすると弱いダイナミックメモリー事情とかの話。
メモリフィルとか連続アドレスをアクセスしているのに、わざわざ壊すようなマルチスレッドはそういう点でも駄目なんだな。
決定的にはメモリーが遅いという点に尽きるが。
こんな風に駄目な理由に一つ以上のネタがあるんだよ、だからやるまでもないの。

813 :デフォルトの名無しさん:2017/04/13(木) 21:29:31.37 ID:1tPgrneG
ほんとに理解してるか?
パイプラインで境界チェックを解決って意味が分からん
どうやってんの

814 :デフォルトの名無しさん:2017/04/13(木) 21:32:07.91 ID:3oML3qao
そろそろ死ねよチンカス勢
これ以上口を聞くとスレを埋めるぞ

815 :デフォルトの名無しさん:2017/04/13(木) 21:46:56.27 ID:2TLG8dmE
>>813
パイプラインがRISC時代に進化して、レジスタが干渉しなければインストラクションを同時実行するようになったから
件の例だとメモリクリアと境界チェックを同時にヤるんだわ
だから一つのCPUは見かけ上メモリクリアを境界チェックの時間0で延々と実行する

コレを実行するのは一つのCPUだし、同時実行に人が介在すること無いのでプログラマーは何もヤることはありません
ホント>>796は酷い出鱈目ですわ

816 :デフォルトの名無しさん:2017/04/13(木) 22:00:11.37 ID:oixKZUzL
何を争ってるのかさっぱりわからんw
ただ昨日書いた>>776が間違ってることはよくわかった。
よく考えればこれ486の時代とかでも当たり前だw
すまんかった

817 :デフォルトの名無しさん:2017/04/13(木) 22:00:58.20 ID:FNNFGlTu
>>815
>境界チェックくらいなら、書き込み待ち時間で十分にできるから他のCPUにまで影響を与えないようにして
これがパイプラインやらディレイスロットに相当する話として描いたんだよ
計算時間隠ぺいはパイプラインだけじゃないからな、不正確になるだろ。

818 :デフォルトの名無しさん:2017/04/13(木) 22:08:08.05 ID:FNNFGlTu
ちなみに昨今のCPUは、機械語命令を別の内部用の命令に一旦変換することで互換を取っている
この変換で色々な隠ぺい処理がされる。
パイプラインの直接関与は無い。

819 :デフォルトの名無しさん:2017/04/13(木) 22:55:07.48 ID:UJp3daw4
そういうのはC++使いにやらせとけ

820 :デフォルトの名無しさん:2017/04/13(木) 23:32:52.23 ID:ZueE7S//
CPUの種類もいっぱいあるし実装すらmonoとかあるんだから考えても無駄だよ
ふつーにヤレ

821 :デフォルトの名無しさん:2017/04/13(木) 23:35:00.21 ID:8HEXXOrW
.NET 4.7でTupleも標準で使えるようになったと思ったら
Windows Server 2016でまだ使えない

822 :デフォルトの名無しさん:2017/04/13(木) 23:51:42.17 ID:qn5HP47l
>>821
4.7がまだインストールできないってこと?

823 :デフォルトの名無しさん:2017/04/14(金) 00:17:56.85 ID:SWEjH6Xz
>>788
GCってガベージコレクタか?
メモリを回収するときにゼロクリアする必要はないんじゃね。痕跡を残したくないとかなら分からないでもないが。。

824 :デフォルトの名無しさん:2017/04/14(金) 07:19:22.25 ID:KckXzUzz
>>822
4。7って自動で入るのか?

825 :デフォルトの名無しさん:2017/04/14(金) 08:29:17.03 ID:pJlkTYEJ
.NET Framework 4.7 is part of Windows 10 Creators Update. What about other Windows versions?
You can start using .NET Framework 4.7 today on Creators Update. It will be available on other Windows versions soon. .
NET Framework 4.7 will support the same Windows versions as .NET Framework 4.6.2. It is an in-place update.

Windows10だけらしい

826 :デフォルトの名無しさん:2017/04/14(金) 19:41:38.09 ID:zACr9/Dt
4.7なんて何に使う気なんだ

827 :デフォルトの名無しさん:2017/04/14(金) 19:57:13.78 ID:vwaM1ek4
NuGetで取ってこなくても最新の機能が使えるとか
ValueTupleとかValueTaskとか

自分も試しにアップデートしてみたがまだ使えないみたいだね
もうちょっと纏めてからアップデートしてくれた方がいいんだけど
アップデートが細かすぎる

828 :デフォルトの名無しさん:2017/04/14(金) 20:03:25.72 ID:znF0F+kk
>>826
何に使うのかは知らんけどtupleを使いたいんだろ

829 :デフォルトの名無しさん:2017/04/14(金) 20:10:48.82 ID:pJlkTYEJ
知っていると思うけど、VSインストーラ立ち上げて4.7を追加インストールします
Windows10をCreatorsUpdateしてから処理したから、必須なのか不明ですが
多分それも必要です

830 :デフォルトの名無しさん:2017/04/14(金) 20:19:05.97 ID:bLw6Whqv
Tuple<T>ってC#4.0からあったと思ったがそれじゃなく?

831 :デフォルトの名無しさん:2017/04/15(土) 02:12:01.30 ID:aGMB9daN
>>830
それとは違う

832 :デフォルトの名無しさん:2017/04/15(土) 10:12:37.06 ID:iCdjVYwG
>>818
ペンティアム2を昨今のCPUって言う人初めて見たw
てか、それらはx86のRISC化なんだが、
RISCってものはパイプラインを高度に利用してトランジスタを増やさずに多重実行する技術だよ
パイプラインの関与と言うか、要です

833 :デフォルトの名無しさん:2017/04/15(土) 10:16:28.45 ID:C33P0hB8
アセンブラできない奴はまともに最適化はできない。これだけ。

834 :デフォルトの名無しさん:2017/04/15(土) 10:18:54.18 ID:3qBkA9st
アセンブラとか老ガイジかな?

835 :デフォルトの名無しさん:2017/04/15(土) 10:23:22.48 ID:C33P0hB8
c#のデバッグでなんで機械語が表示できるようになってると思ってんだ? 低脳馬鹿デジタルネイティブさん >>834

836 :デフォルトの名無しさん:2017/04/15(土) 10:35:26.60 ID:QicJR8ZP
ValueTupleって最初はワクワクしたけど使い所あんましないな
どういう時に使うんだこれ

837 :デフォルトの名無しさん:2017/04/15(土) 10:36:36.36 ID:qt9qpnGQ
うわあ

838 :デフォルトの名無しさん:2017/04/15(土) 10:43:55.01 ID:iCdjVYwG
>>836
out 使って値を返しているやつを素直に書けるだろ

839 :デフォルトの名無しさん:2017/04/15(土) 10:49:59.89 ID:3WGNKYp+
>>832
まてまて、SIMDとパイプラインと並列処理は意味が違うぞ。

言いたいことはわかるけどなw

840 :デフォルトの名無しさん:2017/04/15(土) 10:50:24.08 ID:iCdjVYwG
>>835
C#のILをJITがマシン語に変換して、更にCPU内部でRISC形式の命令に変換
更に命令の順番を最適化して多重実行をするわけで、ILを見たところでどれが効率高いかなど判断するのは人間業じゃないな
せいぜいキャッシュサイズを意識する程度だろうが、2つのループを同時実行されることまで考慮したらどうすれば良いのやら・・・

841 :デフォルトの名無しさん:2017/04/15(土) 10:57:05.83 ID:iCdjVYwG
>>839
SIMDじゃなくて、通常のオペコードをRISC的な内部オペコードに変換するんだよ
で、10段とか15段に細分化されたパイプラインを使って、パイプラインに繋がった演算装置を
複数の実行ユニットが使いまわしをしてトランジスタ増やさずに見かけの同時実行数を5とかに増やす

まあ、それをどうやって実現しているのかさっぱり分からんけどな

842 ::2017/04/15(土) 10:57:43.50 ID:4VXj2s/u
>>840
どこが効率悪いかはわからんか?
あー、アンボクシングかかっとるわ、とか、
これのせいでストールしよるな、とか。

843 :デフォルトの名無しさん:2017/04/15(土) 11:00:42.88 ID:iCdjVYwG
>>842
デバッグに使うのは当然なんだが、通常のソースレベルの効率以上の情報をILから探し出すのは至難の業です
最終的な実行環境は俺を含めてハードの素人には手を出せない神の領域かと

844 :デフォルトの名無しさん:2017/04/15(土) 11:34:57.52 ID:QicJR8ZP
>>838
outはそもそも使わないし
TryXxx系はValueTupleよりout varの方がスマート

845 ::2017/04/15(土) 11:39:27.67 ID:4VXj2s/u
>>843
コーディング中はそりゃ、あんまりそこに固執すると目的地にたどり着きさえしなくなっちゃうもんな。
コンパイラが賢かったり、JITが地味に賢くなって要らない小技になったのも沢山あるし。
たまに見ると面白いよ。あ、これメモ化しちゃうんだ、とか。

846 :デフォルトの名無しさん:2017/04/15(土) 11:39:28.67 ID:UPL5S+RA
そうそう

pythonでやってたことをc#でもできるようになったものって
実際使ってみてもいまいちなんだよな
めんどくさいから欲しかった機能だけどc#流になるとそれ以上にめんどくさいしスマートじゃない

847 :デフォルトの名無しさん:2017/04/15(土) 11:44:51.81 ID:eeh5f4V4
>>832
ペン2には一言も言及してないのに勝手にそうするキチガイさんですか? >>839 これも自演でしょ
多分10年以上も前からここで、板が白けきるまで偉そうな事いいながら荒らしまくっていた人なんでしょうけれど。
そろそろ死んでください。

848 :デフォルトの名無しさん:2017/04/15(土) 11:49:23.70 ID:iCdjVYwG
今回の拡張の中で
ref var a = hoge();
と言う、参照戻り値ってのの使い方が難しいわ

849 :デフォルトの名無しさん:2017/04/15(土) 11:51:55.21 ID:iCdjVYwG
>>847
>、機械語命令を別の内部用の命令に一旦変換することで互換を取っている
コレはPen2とかK6辺りから始まりました
20年前の技術ですね

850 :デフォルトの名無しさん:2017/04/15(土) 11:52:06.28 ID:mE+AhP/n
初心者です

C#はメモリ管理を気にしなくて良いと聞きました
本当でしょうか?

851 :デフォルトの名無しさん:2017/04/15(土) 11:54:00.80 ID:eeh5f4V4
たしかCore2以降は、VILW命令に変換していたと思った。
命令ストリームからVILW命令6スロット分に変換して
6命令ずつ同時実行する事で低クロックでも高速に動作とか。
x86系以外では、スーパースカラの採用も多いみたいだね。

852 :デフォルトの名無しさん:2017/04/15(土) 11:55:39.30 ID:P11oDSMM
本当だよ
2人くらい何か囀ってるように見えるけど、キチガイだから気にしてはいけないよ

853 :デフォルトの名無しさん:2017/04/15(土) 12:00:32.47 ID:3WGNKYp+
>>847
俺、死ぬんか?

854 :デフォルトの名無しさん:2017/04/15(土) 13:12:21.09 ID:7hkWD0i5
>>850
メモリ解放なんかは自動ってことになってるけど
メモリ確保やら初期化やらは気にしないとだめだし「メモリ管理」の内容による

855 :デフォルトの名無しさん:2017/04/15(土) 13:18:16.99 ID:GC6K0tB8
>>823
これ、まともに回答しようと思うとひどく大変なんだが……
823がGCの内部実装を把握しているうえでの指摘にも見えるし、
初心者の思いつきの質問にも見えるし……

初心者向け:
ヒープ確保したら0にクリアされてる
メモリを回収後、再利用されるまでに0クリアする必要があるってこと

把握してる人向け:
メモリコンパクション時にページングの機構使って0クリアしてるのかってことなら、
.NET Core のソースで確認しようと思ったけど
gc.cpp だけでも1.2MBあって挫折した

>>850
初心者のうちは気にしなくていいよ

856 :デフォルトの名無しさん:2017/04/15(土) 13:43:04.38 ID:5VFPMUgC
>>846
C#は式指向のシンタックスを目指してるから、あくまでステートメントに拘るPythonとはだいぶ方向性が違うよ
可能な限り全てのメソッドを式形式で定義する縛りでコーディングしてみたらいい
そうすればC#7の仕様の意図するところは簡単に理解できる

857 :デフォルトの名無しさん:2017/04/15(土) 14:29:19.96 ID:56TRC7nM
みんな詳しすぎ
頭いいんだな

858 :デフォルトの名無しさん:2017/04/15(土) 14:40:07.25 ID:3WGNKYp+
>>842
>>843
思ったけど、あのVTuneってそんな機能あるんかな?

859 :デフォルトの名無しさん:2017/04/15(土) 15:19:31.88 ID:A0YDVHHt
昔Excelを弄ってた時、Excelのオブジェクト解放したはずなのに
単体テストし終わってからタスクマネージャー見るとExcelが一杯残ってた(通称ゾンビ)。
シートやらブックやら解放してから最後にExcel本体解放してってやってたけど
今は一発で解放できるんだよね?
メモリ管理とか気にしないけど、こういうのは気になる。

860 :デフォルトの名無しさん:2017/04/15(土) 15:29:43.17 ID:8JN0d/j3
所謂アンマネージリソースを閉じてないとC#であってもゾンビ化することはたまにある

861 :デフォルトの名無しさん:2017/04/15(土) 15:39:12.33 ID:eeh5f4V4
>>859
Excelは無理だよ、細かくReleaseComObjectしなきゃ駄目だし、しても残る時は残る。
残ってしまう事を前提に組むしかない

862 :デフォルトの名無しさん:2017/04/15(土) 15:41:12.30 ID:aGMB9daN
>>861
しても残る時は残る、はし足りないだけでは。

863 :デフォルトの名無しさん:2017/04/15(土) 15:43:39.01 ID:eeh5f4V4
>>857
自分の書いた内容が正しいという流れになるまでしつこく続ける自演キチガイが一匹いるだけ。
もう相当昔から粘着しているからいい年だと思うんだが、よく生活できてるなって感じだな。
それ以外の人は普通だよ。

864 :デフォルトの名無しさん:2017/04/15(土) 15:58:16.95 ID:3WGNKYp+
ちなみに俺は違うからな

865 :デフォルトの名無しさん:2017/04/15(土) 16:02:07.82 ID:eeh5f4V4
自分が得意じゃないと思う領域は黙っておけ、そして誰か詳しい人がレスするまで
その質問を流すなキチガイ
あと、自分の得意な領域に引き込もうと変な流れに作り替えるな。
掲示板が機能しなくなる
どうせなら死ね

とまあそんな所ですな

866 :デフォルトの名無しさん:2017/04/15(土) 16:06:10.39 ID:OxStzCoo
>>863
気づいてないみたいだけど、悪いけど君の態度も相当エキセントリックに見えるよww

少なくとも>>832は文脈的に妥当な反論をしているようにしか見えんけど、
「俺にたてつく奴はいつものキチガイ(って誰だよw)だ!!」って感じでかなり普通じゃない。

余計なお世話だろうけど、いい歳こいてるんだろうからもうちょっと自分を客観的かつ批判的に
見ることを覚えた方がいいんじゃないんだろうか。

867 :デフォルトの名無しさん:2017/04/15(土) 16:07:40.04 ID:lvAT8XK9
>>859
> 昔Excelを弄ってた時、Excelのオブジェクト解放したはずなのに
> 単体テストし終わってからタスクマネージャー見るとExcelが一杯残ってた(通称ゾンビ)。
ちゃんと ReleaseComObject(comObject) 呼んでないだけだろ
なんで IDisposable にして Dispose で解放するようにしなかったのか謎

868 :デフォルトの名無しさん:2017/04/15(土) 16:09:12.98 ID:eeh5f4V4
駄目だな、このキチガイ・・・
はよ死ね

869 :デフォルトの名無しさん:2017/04/15(土) 16:13:19.25 ID:C33P0hB8
デストラクタの動作タイミングが制御できない時点で逆にいろいろ管理できなくなってトラブルの元になってる。

結局のところ欠陥言語なのだ。

870 :デフォルトの名無しさん:2017/04/15(土) 16:16:13.49 ID:OxStzCoo
>>867
根拠があるのかと言われれば正直ないけど、ぶっちゃけ全部のオブジェクトを
いちいちReleaseComObject呼ぶなんてやってられないし、やらなくてもそれで
「ゾンビ」が残ることはないようだから、必要ないんじゃないのかな。

そんなことよりプロパティが返すオブジェクトをメソッドチェーン的に使わない(面倒でもいちいち変数に
入れてから使う)とか、その手の基本が大事だね

871 :デフォルトの名無しさん:2017/04/15(土) 16:18:04.02 ID:eeh5f4V4
Excelのケースは多分デストラクタというより、Excelのスレッドモデルに問題があるんだと思う。
lock方式でもInvoke方式でもない、少々行き当たりばったりな排他制御をしてるようだ。
古いアプリなので今更改められないのだろうね。

872 :デフォルトの名無しさん:2017/04/15(土) 16:31:33.32 ID:OxStzCoo
エンゼルハートって映画あったな

探偵がロバートデニーロに殺人鬼を探すように依頼されるが、探していた
殺人鬼は探偵自身だったってオチ

「いつものキチガイ」も実は言ってる本人自(w

873 :デフォルトの名無しさん:2017/04/15(土) 16:33:19.87 ID:3WGNKYp+
はいはい、俺が悪かったってことで仲直り。
今後はこのスレ貢献に頑張ろう…でいいやん。



874 :デフォルトの名無しさん:2017/04/15(土) 16:33:31.45 ID:nXYdKgHp
ExcelCreatorが楽すぎて戻れない

875 :デフォルトの名無しさん:2017/04/15(土) 16:36:28.32 ID:eeh5f4V4
>>873
普通なら、それでOKなんだけどね
この人2000年頃にやってきて、際限なく荒らしまくって誰もいない状態にしやがったから。
たまーに戻って死んだかなとか見ているんだが、ご健在のようです。(はよ死ね

876 :デフォルトの名無しさん:2017/04/15(土) 16:57:08.88 ID:aGMB9daN
>>870
そんな基本は聞いたことが無いのだけど、
プロパティが返すオブジェクトをメソッドチェーン的に使うと、どういう問題があるの。

877 :デフォルトの名無しさん:2017/04/15(土) 17:07:01.27 ID:mW9XRjOW
Disposeされないオブジェクトが量産されてリソースリークするに決まってんだろ
一つプロパティにアクセスしたら結果を変数に入れて礼儀正しくDisposeする
これをすべてのメソッド呼び出しとプロパティ・インデクサーアクセスについて行う

878 :デフォルトの名無しさん:2017/04/15(土) 17:09:24.07 ID:nXYdKgHp
>>877
おもしろい冗談だな

879 :デフォルトの名無しさん:2017/04/15(土) 17:16:22.23 ID:UPL5S+RA
return a,b;で返したのを

こんな感じで受け取れれば楽なんだけどな
a,b=method(c);

880 :デフォルトの名無しさん:2017/04/15(土) 17:31:49.05 ID:OxStzCoo
>>876
ゾンビ

なんだかVBerチックなおまじないのように聞こえるけどそうじゃない。
もっとも、どうしてそうする必要があるのか、詳しい理屈は忘れちゃったけどw
明示的に変数で参照されてないCOMオブジェクトは相互運用アセンブリが適切に破棄できないとかなんとか

まあ、変数に入れなきゃReleaseComObjectを呼ぶこともできないよね

881 :デフォルトの名無しさん:2017/04/15(土) 17:33:16.72 ID:7hkWD0i5
excelはC++から使ってもゾンビるよ

882 :デフォルトの名無しさん:2017/04/15(土) 17:38:17.93 ID:A0YDVHHt
>>867
昔の話だよ。

883 :デフォルトの名無しさん:2017/04/15(土) 17:41:04.42 ID:aGMB9daN
>>880
結局ReleaseComObjectは必要なのね。

884 :デフォルトの名無しさん:2017/04/15(土) 17:47:17.96 ID:jssTx07C
>>859
昔のプログラムメンテする必要が有って、丁度それに出くわして同じ方法で対応したわ
結局そのロジック切り捨ててOpenXMLで読み書きしちゃったけど

885 :デフォルトの名無しさん:2017/04/15(土) 17:54:59.95 ID:OxStzCoo
>>883
いやいらんと思うよ
https://web-beta.archive.org/web/20080306103320/http://jeanne.wankuma.com/tips/programing/releasecom.html
↑によるとReleaseComObjectは「保険」らしい

オブジェクトをちゃんと変数につっこんでから使えは一応ソースあった。
「仕様」の一言で、どうしてそうしなきゃらなんのかの理屈は書いてないが
https://support.microsoft.com/ja-jp/help/317109/office-application-does-not-quit-after-automation-from-visual-studio-.net-client

886 :デフォルトの名無しさん:2017/04/15(土) 18:00:32.55 ID:OxStzCoo
まあVB6みたいに参照カウント見てラッパーオブジェクトの破棄をやってるからってことなのかな
こま切れのレスで申し訳ない

887 :デフォルトの名無しさん:2017/04/15(土) 18:14:19.64 ID:eeh5f4V4
>>885
>ガベージ コレクションを実行して解放することができますが、こちらはあくまでも保険です
読んでみた限り、GCが保険でReleaseComObjectでやれという事に読めますね。

マイクロソフト公式も保証されるわけではないという感じですね。
実際、これはやってみたが上手くいかないケースはちょくちょく発生します。
次善策以上の対策は取れないと思われます。以前サポートに質問した時もそんな感じの回答でした。

888 :デフォルトの名無しさん:2017/04/15(土) 18:33:54.48 ID:OxStzCoo
>>887
あー確かにその通りだねw
適当なこと言ってごめん

889 :デフォルトの名無しさん:2017/04/15(土) 22:36:26.65 ID:tyUWSBTM
>>879
タプルに括弧が必要なのはやむを得ないかな。変数宣言の文法変えるわけにもいかないし。

890 :デフォルトの名無しさん:2017/04/15(土) 22:56:40.40 ID:lvAT8XK9
>>881
ちゃんと作ればゾンビったりしないよ
デストラクタで確実に解放できるからその点だけで言えば C# よりむしろ楽

>>885
> ↑によるとReleaseComObjectは「保険」らしい
それ、それページ書いた人がちゃんと理解してないだけ
そもそもGCはCOMなんて意識してないからCOMの解放なんてしないし
詳しくはここら辺を見て
https://blogs.msdn.microsoft.com/office_client_development_support_blog/2012/02/09/office-5/

891 :デフォルトの名無しさん:2017/04/15(土) 23:54:44.22 ID:X3IC3wwW
ググってもよくわからんのだけど
GetType()+typeof()で型判定と
isでやるのはどっちが速い?

892 :デフォルトの名無しさん:2017/04/16(日) 00:20:09.43 ID:SqhlDt4o
>>891
一時変数に入れたりしないで単純な GetType == typeof の形に限り前者
JITレベルで最適化がかかるみたい

893 :デフォルトの名無しさん:2017/04/16(日) 01:16:43.35 ID:dwmihMuF
>>855
GCのソースを見る気はしないけど0クリアはやってないと思う。
どう考えても時間の無駄。
変数を使用するタイミングで初期化が行われて、ものによってゼロクリアが行われるってだけじゃないんかね。
だから大量な領域をゼロクリアすることはそうそうないと思ってるんだけど。
例えばintの長い配列を確保したときとかくらい。

894 :デフォルトの名無しさん:2017/04/16(日) 02:15:50.20 ID:UDjczAnn
>>893
ヒープのオブジェクトは new した時点で内容が0クリアされてることは仕様

895 :デフォルトの名無しさん:2017/04/16(日) 06:55:53.07 ID:dwmihMuF
>>894
それはメモリ確保後に初期値で初期化されたってことででしょ。どっちにしろGCで大量にゼロクリアが必要にはならないよね。

896 :デフォルトの名無しさん:2017/04/16(日) 08:00:22.29 ID:uS8rD07o
どーせ、一番下でVirtualAlloc走ってんでしょ。そこで0クリアなんじゃね?

897 :デフォルトの名無しさん:2017/04/16(日) 08:43:50.68 ID:dr2cdwts
0クリアをどのタイミングでしているかは知らないが
早めの0クリアがセキュリティーに貢献するであろう事は予想できる。
今そうでなくても、そのうちに使用しなくなったタイミングで可能なら0クリアという形になったとしても驚かない。

898 :デフォルトの名無しさん:2017/04/16(日) 08:49:20.74 ID:dr2cdwts
ちなみに自分はガベコレが効率よく機能してくれるよう、使用しなくなったら0クリアはしている。
巨大なツリー構造を作って大量のヒープを使い始めると、参照を移動するだけでも結構なCPU時間を取られるようなので。

899 :デフォルトの名無しさん:2017/04/16(日) 09:00:30.49 ID:nOhMz2bP
破棄されるメモリへの(読まれない)書き込みを省略する最適化を行うコンパイラもあるし、
一律0クリアって方向にはならないだろうねぇ。
セキュリティ確保のためにわざわざ省略されない0クリアなんて機能を用意するくらいだし。

900 :デフォルトの名無しさん:2017/04/16(日) 09:02:08.11 ID:H6tmXYoH
0クリアとnull代入は別物だぞ

901 :デフォルトの名無しさん:2017/04/16(日) 10:39:40.78 ID:yhNZe4vR
>>897
> 0クリアをどのタイミングでしているかは知らないが

何のためにデバッガがついてると思ってんだ。

902 :デフォルトの名無しさん:2017/04/16(日) 11:27:43.64 ID:UDjczAnn
>>896
あー、それそれ
.NET Core の gc フォルダ内のコードに VirtualAlloc の RESET_MEM で
ゼロクリアしてる箇所がいくつかあった

たぶん、コンパクションした後に残ったゴミ領域を VirtualAlloc で
ゼロクリアしてると思うんだが、そこは探しきれなかった

>>895
初期値(0)で初期化されたってのはゼロクリアなんだが……
ttp://ufcpp.net/study/csharp/rm_default.html

お前の言う初期値は別のことを指してるのか?

> どっちにしろGCで大量にゼロクリアが必要にはならないよね。
メモリ確保時のゼロクリアってのはヒープ管理の行うこと
ヒープ管理はGCとは切り離せないの
だから .NET Core のゼロクリアのコードだって gc フォルダ内に配置されてるんだし

903 :デフォルトの名無しさん:2017/04/16(日) 11:44:56.24 ID:EJt90aDw
>>902
横からごめん。無知なので教えて。

・GC って概要として不要になったメモリを解放する機能って理解はあってる?
・メモリ確保時に初期化が実行されるとの理解はあってる?
・一般的な挙動として、メモリ確保と GC は別物との理解に誤りはある?
 ※実装が GC 時に初期化しているかどうかではなく、GC と言う言葉の定義に初期化が含まれるかと言うこと

自分は上記が正しいと思ってるから、 >>895 の内容に違和感を感じなかったんだ。

904 :デフォルトの名無しさん:2017/04/16(日) 12:08:09.86 ID:uS8rD07o
>>903
君は正しい

905 :デフォルトの名無しさん:2017/04/16(日) 12:11:25.63 ID:SqhlDt4o
>>903
CLRの構造としては、GCはメモリ管理一般を担うコンポーネントである
だからメモリ確保も初期化するのもGC
GCってメモリの使用状況に応じてオブジェクトを動的に再配置したりとか色々裏で頑張ってるから、
単純に 確保/解放 と割り切れるもんじゃないんだよ

906 :デフォルトの名無しさん:2017/04/16(日) 12:21:18.23 ID:qeC+G70E
>>891
前者でもいいけどtypeof(シールクラス)にしないとダメだよ

907 :デフォルトの名無しさん:2017/04/16(日) 13:21:57.61 ID:UDjczAnn
>>903
>・GC って概要として不要になったメモリを解放する機能って理解はあってる?
はい

>・メモリ確保時に初期化が実行されるとの理解はあってる?
正確ではない
ヒープからオブジェクトを確保したら初期化されていることが決まっているだけで、
初期化のタイミングは決まってない
既に初期化済みの領域から割り当ててるはず

>・一般的な挙動として、メモリ確保と GC は別物との理解に誤りはある?
> ※実装が GC 時に初期化しているかどうかではなく、GC と言う言葉の定義に初期化が含まれるかと言うこと
誤りはない
ただし片方だけではメモリのシステムとして機能しない

>自分は上記が正しいと思ってるから、 >>895 の内容に違和感を感じなかったんだ。
.NET の実装によるので
「GCで大量にゼロクリアが必要にはならない」 は誤り
.NET Core の実装ではページングの機構を使って大量にゼロクリアしてる(と思う)

オレオレCLR実装でGC時ではなく、オブジェクト確保時にゼロクリアする実装というのはあり得る

908 :デフォルトの名無しさん:2017/04/16(日) 14:12:52.31 ID:0ImhO/qF
>>903
> GC と言う言葉の定義に初期化が含まれるかと言うこと
含まれていないけど、実質同じ。

GCってプログラマの負担を減らす為の物なのに、
いちいちゼロ初期化必要だとコンセプトとしておかしいでしょ。
まともなGCならゼロクリアされている。CLRもそう。

仕様としては、
△ > ・メモリ確保時に初期化が実行されるとの理解はあってる?
○ ・メモリ確保時には初期化済み
であって、どのタイミングで初期化するかはGCの実装による。
同じ事はOSでも行われていて、以下ページのZeroed参照。
http://nyaruru.hatenablog.com/entry/20080430/p2

909 :デフォルトの名無しさん:2017/04/16(日) 15:02:23.81 ID:79m5iU1q
なんかすごい重箱モードの議論だねw
いや批判はしてないですよ別に

910 :デフォルトの名無しさん:2017/04/16(日) 18:44:26.20 ID:dr2cdwts
粘着質な人が居ると困りますねw

911 :デフォルトの名無しさん:2017/04/16(日) 18:59:23.11 ID:I10lJTDS
>>892,906
そうかTHX.
isの方がなんとなく速そうだと思ってたが案外そうでもないんだな

912 :903:2017/04/16(日) 20:38:49.89 ID:EJt90aDw
>>904,905,907,908
教えてくれて、ありがとう。
自分も MSDN の文章を読んだりしてみました。
斜め読みだから読み落としてる可能性も高くそうしたらごめんなさい。

[一般的定義]
・GC は概要として不要になったメモリを解放する機能のこと
・一般的な挙動として、メモリ確保と GC は別物

[CLRの仕様]
・メモリの確保も解放も GC の機能の内
・確保されたメモリは初期化されている

[CLRの実装]
・GC 時にメモリを初期化してるっぽい


ふつう、挙動を考える際には仕様を元にすると思うから
「GC時(正確にはメモリの解放時)にはメモリの 0 クリアは期待しない/できない」と理解してよさそうな気がする。
>>895 の「GCで大量にゼロクリアが必要にはならない」が「GC時に 0 クリアしている訳ではない」との意味であれば
仕様としては正しいことから一般論としても正しい。
ただ、実際にはやってくれているけど、それは仕様に基づいているわけではないからいつ改変されるか分からないアテには出来ないもの、と理解しました。
自分もよくやるんですけどね。仕様にはないけど自分が考える安全のための後始末とか。

913 :デフォルトの名無しさん:2017/04/16(日) 20:52:22.64 ID:3ec5aaGF
勝手に0クリアしてもいいけどGCはそれがわからないから
またGCが0クリアするよ
つまり二度手間

高速化なんてのたまてってるけど馬鹿ばっか

914 :デフォルトの名無しさん:2017/04/16(日) 20:53:23.50 ID:3ec5aaGF
無能の馬鹿の議論は飽きたわ
どこか別でやってくれよ
個人のブログとか

915 :デフォルトの名無しさん:2017/04/16(日) 20:55:58.52 ID:dr2cdwts
正直議論に見えない、自演に見えてきた。

916 :デフォルトの名無しさん:2017/04/16(日) 21:04:46.71 ID:wSkKKBMW
>>912
もともとのガベコレの意味はざっくり言えば「確保/解放によって断片化したメモリのデフラグ」
だったはず

知らんけど

917 :デフォルトの名無しさん:2017/04/16(日) 21:22:51.36 ID:0ImhO/qF
>>912
GCは「アイドル時にやれ」というのは分かるよな?
実際はとりあえずこれを目指しているはず。

メモリ確保時にゼロ初期化するのはユーザ時間に直接影響する。
(メモリ確保のレイテンシが著しく増大する)
GC時に初期化するのはGC時間が長くなる。
CLRの場合は確かGC時にはユーザスレッドを凍結していたはずだから、
これもユーザに見えることになる。

だから、普通に考えて、
一旦GCした後、(ユーザスレッドと並行可能な)別スレッドでゼロ初期化だよ。

918 :デフォルトの名無しさん:2017/04/16(日) 23:10:52.00 ID:rt4ZW9V3
基本型の配列は0クリアされるのは仕様で決まっとる
どこのどいつが実際にやろうが関係ないだろ

919 :デフォルトの名無しさん:2017/04/17(月) 21:40:45.89 ID:3B2OvgTj
でも初期化するクセは付けた方がいいぞ
プログラマとして
そういう意味でゼロクリアされている事がわかっていても
明示的にやっておくのも間違いじゃない

920 :デフォルトの名無しさん:2017/04/17(月) 21:53:33.58 ID:DRWzf9HM
いいぞ

誰に向かって威張ってるのかね
そんな威張っていうような話か?w

921 :デフォルトの名無しさん:2017/04/17(月) 21:59:35.59 ID:FPOa41qy
一週間も馬鹿な話続けてる奴にそんな嫌み通じるかよ
お前も馬鹿か

922 :デフォルトの名無しさん:2017/04/17(月) 22:28:28.26 ID:0+0M+jw7
じゃぁ配列は、こう初期化すんの?

byte[] buff = (byte[])Enumerable.Empty<byte>();

923 :デフォルトの名無しさん:2017/04/17(月) 22:37:56.61 ID:sNToWnIL
自分のブログでヤレ

924 :デフォルトの名無しさん:2017/04/17(月) 22:40:07.22 ID:sNToWnIL
わかってないようだから書くけど

こいつがまず重度の馬鹿
>>919

925 :デフォルトの名無しさん:2017/04/17(月) 23:18:50.28 ID:pEHnUlca
924 はキチガイの類

926 :デフォルトの名無しさん:2017/04/17(月) 23:22:01.64 ID:pEHnUlca
これがキチガイの末路w
これこそが本物だ
http://www.int2.info/news1.htm

927 :デフォルトの名無しさん:2017/04/17(月) 23:38:40.81 ID:YebzKHR/
ここまで基地外だけ

928 :デフォルトの名無しさん:2017/04/18(火) 00:27:01.11 ID:0Yq9p2Hl
>>926
Microsoft相手に訴訟すると
こういう目に会うのか

929 :デフォルトの名無しさん:2017/04/18(火) 00:36:27.92 ID:gic2i7xr
んな訳ねぇだろ、てかお前本人だなw
そんな予感はしてたんだ、文体似てるし60代臭していたし
Delphi板荒らしていたヤツとよく似てたし、お前Delphiやってたし
もうじき親の財産次るんだろ?もう終わりだろ、はよ死ね

930 :デフォルトの名無しさん:2017/04/18(火) 01:34:33.30 ID:4m6dsFPX
client sideのvalidationがめんどくさすぎるのだけどVMからvalidator.jsを生成するサービスないのか?

931 :デフォルトの名無しさん:2017/04/18(火) 06:15:21.44 ID:dwhcaFAX
それは頭悪いだろ
サーバーサイドでやってるバリデーションと同じことがしたいならAPI作ってajaxが筋

932 :デフォルトの名無しさん:2017/04/18(火) 06:39:33.82 ID:RUjuZHo6
そのAPIとそれを使ったクライアントコードの生成サービスないかってことでしょ

933 :デフォルトの名無しさん:2017/04/18(火) 07:40:17.90 ID:4m6dsFPX
>>931
不要な通信を避けるためにclient side validationするわけでしょ
そのために通信をしてたら意味ないじゃん

934 :デフォルトの名無しさん:2017/04/18(火) 07:51:25.03 ID:Su4pCCia
あるわけねえだろ夢見んな

935 :デフォルトの名無しさん:2017/04/18(火) 18:30:31.09 ID:dwhcaFAX
>>933
client side validationの目的は一般的には通信を避けることではなくフィードバックの即時化によるUXの改善でしょ
よほどレイテンシの大きい糞NWを想定してるとか、サーバーに頻繁にリクエストが来るのがキャパシティ的に許容できないとかでない限りは
ajaxによるバリデーションは十分有効

936 :デフォルトの名無しさん:2017/04/18(火) 18:34:28.24 ID:b4tf0yLR
クライアントにidとパスハッシュのリスト送信しておけばおk

937 :デフォルトの名無しさん:2017/04/18(火) 19:24:13.68 ID:T0vdTXyx
>>935
なるほど
でもその説明じゃうちのロートル達が納得しないよ
もっと素人が喜びそうな説明はできないの?

938 :デフォルトの名無しさん:2017/04/18(火) 19:34:36.94 ID:qpdySibv
死ね

939 :デフォルトの名無しさん:2017/04/20(木) 14:46:51.02 ID:ofUg/eB0
EntityFramework で System.Data.SQLite 使ってるんだけど、
SaveChanges() が遅すぎるので、
CQRS( ttps://msdn.microsoft.com/magazine/mt788619 )をやってみようと思った

クエリ用にデータベースファースト、コマンド用にコードファーストで
DbContext を作ってみたんだけど、モデルファーストの DbContext を new すると
コマンド用の POCO と競合して曖昧と言われる

まだ試してないけど解決方法がなんか汚い
ttp://entityframework.codeplex.com/workitem/483

クエリ用、コマンド用ともにコードファーストにするのが普通なんだろうか?
SQLite はマイグレーションサポートしてないようなのでコードファーストはメジャーじゃない?

940 :デフォルトの名無しさん:2017/04/20(木) 18:34:56.61 ID:9NLTwIyk
>>939
DBからコードファーストじゃだめなん?

941 :デフォルトの名無しさん:2017/04/20(木) 19:09:00.01 ID:ofUg/eB0
>>940
そうね
データベース(モデル)ファーストにしてるのは、
ER図を見るために使ってるだけだからそれでもいいかぁ

クエリ用(Read)とコマンド用(Write)双方ともDBからコードファーストで作って
DB変更時には再度作り直す方法でやってみるかなー
(どこらへんがコードファースト? って使い方になっちゃうなw)

942 :デフォルトの名無しさん:2017/04/21(金) 00:34:55.91 ID:IVDQeFzJ
毎回迷うんだけど
VS2017ではどのデータベースを使うべき?
そしてEFはどのバージョンを使うことになって参考になるサイトはどこにあるんだ?

それそろ安定してほしいんだけど

943 :デフォルトの名無しさん:2017/04/21(金) 01:26:41.50 ID:72Ff37pO
>>942
MSDN: Introduction to Entity Framework
ttps://msdn.microsoft.com/en-us/library/aa937723(v=vs.113).aspx

上記ページは、なんか日本語表示にはできるけどインデックスやら、
ページのリンクが英語になってたりして、チグハグ

和書では、EFについて書かれた本がほとんどない
書いてあっても一章分でさらっと流す程度だし、
ネット上の情報だと EF を使うための VisualStudio の操作方法とか、
いくつかの落とし穴の回避方法がパラパラ載ってる程度なので、
英語の MSDN をブラウザの翻訳機能で読んだほうがいいと思う

EF Core (EF7として開発されてたらしい) ではクロスプラットフォームの
ための軽量化で一部の機能を削いでるらしい(モデルファーストとかはできなくなる)
EF6 は EF Core が出てからもしばらくはサポートされるので、
今入門するなら EF6 を使うのがいいと思う
(というか、必要でない限り移行はお勧めされていない)

944 :デフォルトの名無しさん:2017/04/21(金) 06:35:38.36 ID:h0UgT1Ml
EFはWeb系のノリで作られてるから安定することはないよ

945 :デフォルトの名無しさん:2017/04/21(金) 07:48:39.88 ID:XjCRa8hg
業務とデータベースに精通していて
全てを自由に弄れる立場にいて
時間をかけて生成されるデータ構造まで意識した精緻なモデル設計ができて
その案件の寿命までずっと面倒をみれるか同レベルの後継者を育てられる
そんな人がチームにいればモデルファーストは有りじゃないかな
そうでなければ使い捨てアプリぐらいにしか使えないよ

946 :デフォルトの名無しさん:2017/04/21(金) 08:13:05.97 ID:dQDWETdW
>Web系のノリ
どういうこと?

947 :デフォルトの名無しさん:2017/04/21(金) 08:17:36.55 ID:lbMf26rv
>>942
安定って具体的に何のことを言ってんの?とっくに枯れた技術だけど

948 :デフォルトの名無しさん:2017/04/21(金) 09:12:06.55 ID:LWRI+6r2
>>946
ヤマトのりかと

949 :デフォルトの名無しさん:2017/04/21(金) 11:08:44.37 ID:U4JkC8YI
EFとLinqのせいで生のSQL文が書けなくなっている。

950 :デフォルトの名無しさん:2017/04/21(金) 11:45:09.91 ID:72Ff37pO
まだサポートが十分でないDBとかあるし、ガンガン開発されてるのに枯れたとか言っちゃうんだ
Web系の人なんだろうなー

ttps://docs.microsoft.com/en-us/ef/efcore-and-ef6/features

EF1 2008/8 バージョン4.0までは ObjectContext を使ったプログラミング、データベースファースト
EF4.0 2010/4 セカンドリリース、POCOサポート、モデルファーストサポート
EF4.1 2011/4 DbContext が導入される、コードファーストサポート、NuGet配布
EF4.3.1 2012/2 マイグレーションのサポート
EF5.0 2012/8 .NET4.5 が対象、enum
EF6.0 2013/10 オープンソース化、async対応、細かな改善多数
EF6.1 2014/3 DBからコードファーストするウィザード
EF6.1.3 2015/3 EF6系の最新(EF6.2 が出る?)
EF Core 1.0(EF7) 2016/6 コードベースが新たになる、ObjectContext 非推奨
EF Core 1.1
EF Core 2.0 2017/Q3予定 準備中

GitHub のフォルダ構成見て初めて気づいたんだけど、
EF ってASP.NET の1モジュール扱いなんだな
964 の言ってるWeb系のノリ、納得

951 :デフォルトの名無しさん:2017/04/21(金) 11:56:05.07 ID:8CN2PrPc
開発されてないのが枯れてるのか。そりゃ確かに枯れてるなww

952 :デフォルトの名無しさん:2017/04/21(金) 12:40:19.25 ID:dpyapAzz
>>946
あくまでもイメージだが品質とか安定性より開発速度とかリリースを優先するって感じ

>>947
腐ったまま枯れてるってことはいくらでもあるし

953 :デフォルトの名無しさん:2017/04/21(金) 17:42:09.62 ID:MpBIOwvX
そういえば前から疑問なんだけど、フォームのイベント伝搬ってどう組むべきなんだ?

状況としてはよくある波形ビューワーで、表示先頭位置と倍率が変えられて、
カーソルが2つあって、フィットボタンを押すと画面にフィットするもの。
(カーソル0が画面の左端、カーソル1が画面の右端になるように、
自動的に表示先頭位置と倍率が調整され、再描画される)

(A) 表示先頭位置の変更→画面再描画
(B) 倍率の変更→画面再描画

とした場合、
フィットボタンを押す→
 表示先頭位置と倍率が自動的に変更される=普通は上記(A)または(B)に当たる
 →自動的に再描画される
となるのだが、ほとんどのケースで2回描画されてしまう。
そこで今は、倍率変更側はフォーカスを確認して

(B') 倍率の変更→(フォーカスがある時のみ)→画面再描画

として1回描画にしているが、
これだとフィットボタンを押したとき、結果的に倍率のみの変更の場合は再描画されない
(同じ値を上書きしてもChangedが発火しない)ので、フィットボタンのイベントの最後に
if (!changed_start_pos) redraw();
を付けている。
ただしこれはリファクタ時に久々に見たら「はて?」と思ってしまった。
この場合って、どう組むべきなんだ?

ちなみにJavaScriptの場合は、プログラムによる変更の場合はイベントが発火しないので、
全てのイベントの最後に redraw(); が必要になるが、全部書けば全く問題ない。
フォームの場合はプログラムによる変更でもイベントが発火するので、この問題が起きる。
ただ、特にレアケースでもないし、一般的なうまいやり方があるとは思うのだけど。
上手く繋げられれば記述が少なくて済むからこの仕様なんだろうし。

954 :デフォルトの名無しさん:2017/04/21(金) 17:42:43.14 ID:MpBIOwvX
なお、今のコードのイメージは以下。(CLIだけど)

void numericUpDown_fitButton_Clicked(Object^ sender, EventArgs^ e) { // フィットボタンクリック
// 倍率と表示先頭位置の再計算
numericUpDown_magnitude->Value = XXXX;
numericUpDown_startPos->Value = YYYY;
if (!changed_start_pos) redraw();
}
void numericUpDown_magnitude_ValueChanged(Object^ sender, EventArgs^ e){ // 倍率変更
// スクロールバー等の増減量等、他機能の整備もここでやっている
if (((NumericUpDown^)sender)->Focused) redraw();
}
void numericUpDown_startPos_ValueChanged(Object^ sender, EventArgs^ e){ // 表示先頭位置変更
redraw();
}

void redraw(); // 再描画

ぱっと思いつくのは全部 Focused を確認して redraw() だが、
それだとこの仕様(=フォームのイベントはプログラムによっても発火する)にした意味無いよね?
(その場合は明らかにJavaScriptの仕様の方がマシって事になってしまう)
多分何らかの上手いやり方があると思うのだが。
色々奇妙なのは後付でごちゃごちゃやっているから勘弁で。
今までは問題なく動作していたから放置していたが、ついでなのでリファクタしようとしている。

955 :デフォルトの名無しさん:2017/04/21(金) 18:12:04.32 ID:FFGpioc0
>>953-954
そもそもコントロールのイベントで再描画ってのはちょっとw

表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティになってるはずで、それらのプロパティの変更痔に
再描画されるようにしないと

無駄な再描画を避ける方法だけど、一番いいのは余程重いのでなければ
気にしないことだと思うw

どうしてもこだわるなら、直接再描画するんじゃなくて
タイマーのイベントに再描画を紐づけしてタイマーをスタートさせるだけにするか、
Application.Idleイベントをうまく使うかするとか

956 ::2017/04/21(金) 18:18:11.06 ID:KFYgHFHL
>>953
リドローが必要だとキューイングするかと。
どうせインプットのリフレッシュレートやら画面のリフレッシュレート越えてリフレッシュしても無駄なんだし、リフレッシュ時には再描画するんだし。
WindowsならWM_PAINTでやるとかが歴史的にいわゆる普通の方法では?

957 :デフォルトの名無しさん:2017/04/21(金) 18:23:10.98 ID:YZVNImgq
>>950
EntityFrameworkとEntityFramework Coreを同一視してるおバカさん

958 :デフォルトの名無しさん:2017/04/21(金) 18:35:37.53 ID:RSu3z+zM
フォームのように、SuspendLayout, ResumeLayoutみたいな設計もあるけどね

959 :デフォルトの名無しさん:2017/04/21(金) 18:51:51.53 ID:xzjZrHPt
イベント毎にRedraw要求を行うのではなく、
イベント毎にRedrawイベントをどこかのキューにぶち込んで、タイマーや別スレッドで監視し、
描画時に複数のRedrawイベントがあれば最新の物を一度で済ませるようにすればいい。

960 :デフォルトの名無しさん:2017/04/21(金) 18:55:13.11 ID:MpBIOwvX
>>955
別クラスのプロパティに分離しても本質的には同じだよね?
複数のプロパティが、
・どれかは変更される
・全てが変更されるとは限らない
・必ず変更される物があるわけではない
状況においては、内部的にOR取ることが必要で、一番単純なのはキューで上書きしてしまう方法。
つまりそちらのようにタイマーに要求を出して、
timer->start()は何度打っても同じだからそこでOR取ってしまうとか。
しかしこれだと余分にこの構造が必要なんだよね。
(ただし他の部分ではこの方法も使っている)

UIから変更された場合、60fpsとかにするくらいなら直接イベントで描画してもほぼ同じでしょ。
波形はwaveファイルで数百メガとかの場合もあり、このときは明らかにもたつくので2度描画はNG。

あるいは、独立クラスにフラグを持ってそこで上書き、
独立クラスのeventをサブスクライブしろ、ということ?
それは理想的な構造なのだろうけど、話が膨らみすぎて面倒だ。

Application.Idleは初耳だが素晴らしい。(JavaScriptではアイドルが取れない)
これってUIスレッドが、ってことで良いのか?
(ただしこれは今回は使えそうにはないが)

>>956
WM_PAINT見たがよく分からん。
システム側が再描画タイミング(おそらく60fps)を通知してくれるので、
それをサブスクライブして、そこで溜まっている再描画を掃くのか?
それはゲームみたいに常に再描画する用で、
今回みたいにUIで変更された時のみの場合は常にイベントが呼ばれる分ウザくなる気が。
あるいは、自分で何かを再描画した時だけ、
システム側で60fps同期でWM_PAINTを打ってくるのなら、今回には使えない。

961 :デフォルトの名無しさん:2017/04/21(金) 18:57:50.94 ID:MpBIOwvX
>>959
サンクス。まあみんな意見は同じか。

他に何か、「プログラムによる変更であってもイベントが発火する」という、
フォームの仕様を上手く使った方法はないかねえ?

962 :デフォルトの名無しさん:2017/04/21(金) 19:08:46.15 ID:xzjZrHPt
>>961
>>958みたいな感じじゃないか。
WindowsのListViewとかも、大量のデータ挿入を想定してBeginUpdate/EndUpdateと言った手段を用意しているし、一般的な手法かと。

963 :デフォルトの名無しさん:2017/04/21(金) 19:19:20.39 ID:72Ff37pO
>>957
違いを比較しているURL貼ってるのにレスを読みもしないで小馬鹿にする馬鹿

>>953
瑣末なことで悪いんだけど、どうしても気持ちがざわつくので指摘する
「リファクタする」は日本語としてあまり使われていない
refactor の訳としては「リファクタリングする」が使われている印象

どう間違っているのかはうまく説明できん
refactoring は造語で、それを元に refactor という動詞が造語として作られている
一般的な動詞ではないので注意

964 :デフォルトの名無しさん:2017/04/21(金) 19:50:01.08 ID:MpBIOwvX
>>962
BeginUpdate/EndUpdateはいいとして、
SuspendLayout, ResumeLayoutは反応しなくないか?
(というか>>958は俺宛ではなくEFの件なのか?と思っていた)

俺の理解ではSuspendLayoutはレイアウト時、つまり、Control.AddRangeを止めるもので、
Graphics.DrawLinesとかを止めるものではないと思っているのだが。

>>963
了解。

965 :デフォルトの名無しさん:2017/04/21(金) 19:56:01.47 ID:FFGpioc0
>>960
コントロールのイベント使うな、っていうのは無駄な再描画対策じゃなくて設計論ね
そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
まあ余計なお世話だよねw

Application.Idleは例えばこうやって使う

bool DrawOnIdle {get; set;}

void Application_Idle(object sender, EventArgs e}
{
  if (DrawOnIdle) redraw();
  DrawOnIdle = false;
}

966 :デフォルトの名無しさん:2017/04/21(金) 20:10:34.38 ID:Cei54Lla
VS2017でどのデータベースとEFを使うべきか質問したものです
レスありがとう

完全に浦島太郎状態でした
こんなことになってるとは思っても見ませんでした
.net.core の方の知識もなくてググってみたらマニュフェストらしき設定ファイルが
xmlからjsonになってるんですね...

967 :デフォルトの名無しさん:2017/04/21(金) 20:16:45.24 ID:TbfEGS8v
MSに関わると2,3年であっという間に浦島になるからな

968 :デフォルトの名無しさん:2017/04/21(金) 20:28:06.75 ID:MpBIOwvX
>>965
ちょっと話が噛み合って無い感があるから整理すると、

JavaScript:
プログラムからの変更ではイベントが発火しないから、
全てのイベントハンドラは redraw(); で締めないといけないが、
イベントハンドラ内で他コントロールをどれだけ触ろうと何も考える必要なし。

.NET:
プログラムからの変更でもイベントが発火するから、
関連しているコントロールのイベント先をすべて redraw() にしておけば再描画される。
だから単純な再描画についてはこっちの方が記述はすっきりする。
ただし、今回のように複数コントロールを触るイベントハンドラがあった場合、
その回数だけ再描画される可能性がでてくるからそこを対策しようとすると、途端に汚くなる。
(JavaScriptのコードは redraw(); を書くしかないし、再描画だとはっきり分かるが、
.NET のコードは俺が今やっている妙な対策法だと???なコードになる)

再描画されればいいのなら、.NETの方が良いけど、
2度描画禁止とかにしたい場合、.NETの方が記述が余計に必要になる。←これって俺の勘違いか?
というのが今回の疑問。

> そういう設計だと、例えばプログラムで倍率を変更しても再描画されないよね。
違う。プログラムから各コントロールのValueを変更することによって、自動的に再描画させてる。
というか、波形表示画面内容と表示開始位置と倍率は当然同期してないといけなくて、
逆に、表示開始位置と倍率が変わらないのなら再描画の必要がない。
それはコントロールの値を変更する構造によって自動的に達成される。
(.NETは同じValueを上書きしてもイベントが発火しない為)
だからFitボタン連打とかの場合の無駄な再描画はここで止められる。
多分.NETの仕様だとこういう事だと思うんだよ。(これがMVC的に云々というのはまた別の話)
それで、2度描画禁止の場合はどう実装するべきだという想定なのだろう?という疑問なんだ。
普通はキューイングするから問題ない、ってことなのかな?
(なお、明示的に再描画したい場合は redraw() を呼ぶだけだから問題ない)

969 :デフォルトの名無しさん:2017/04/21(金) 20:42:28.79 ID:MpBIOwvX
ちなみにMVCの場合はモデルがイベントソースで、
コントロールの値を変更→モデルの値を変更→再描画
という流れになるけど、モデルの値をプログラムから変更する場合、
コントロールの値の表示を手動で合わせてやる必要がでてくる。
これが面倒だから、WPFではバインディングってことで自動化してる。

これはこれで良いとして、
.NET作った時に今回のようなケースが想定されていないはずもなく、
彼等の想定実装があるはずで、
その通り実装すれば綺麗に実装出来るはずなんだが、というのが俺の疑問。

970 :デフォルトの名無しさん:2017/04/21(金) 20:43:34.30 ID:FFGpioc0
>>968
勘違いではないよね。
その認識であってると思う。

コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
コントロールはあくまでUI(表示と入力)に徹するべきで、
表示先頭位置とか表示倍率とかの値はFormなりUseControlなり
独立したクラスなりのプロパティにするべきだというか、普通はすると思う。

で、再描画はコントロールのプロパティが変更されたタイミングではなく、
表示先頭位置なり表示倍率なりのプロパティが変更されたタイミングで行う。

当然、この場合も一度に複数のプロパティが変更されたときに
不要な再描画を回避する方法は考える必要がある

971 :デフォルトの名無しさん:2017/04/21(金) 21:04:34.72 ID:rPWpf+kQ
n秒に1回描画フラグを監視する仕組みのが楽だなw
コントロールの挙動全部把握してるやつが触らないとぶっ壊れるって
モノ作ってんだろ?
それって設計悪くない?

972 :デフォルトの名無しさん:2017/04/21(金) 21:07:01.51 ID:MpBIOwvX
>>970
> コントロールのプロパティを値の入れ物として利用するのは普通はよくない作法だと思う。
MVC的にはそうだね。ただ、この部分のUIなんて変更はないからどっちでもいいのも事実。
ところでその場合、バインディングはどう実現する?

(C) numericUpDownのValueChanged→モデルの値を変更

これはいい。ただFormの場合、

(D) モデルの値が変更された→イベント発火でnumericUpDownの表示値を変更

とすると、当然(D)の直後に(C)が発火して、
モデルの値を再度「同じ値」で上書きして、そこでイベントが止まる。
これって全くの無駄でしょ。

.NETの仕様を決めた時、これらが想定されていないはずもなく、
彼等なりの上手い使い方があったと思うんだよね。
(今現在それが良いとされる手法かどうかはともかく)

今のところ、表示とモデルの内容を同期するのに一番簡単な方法は、
「numericUpDownのValueをモデルの値として扱うこと」なんだよ。
そしてこれだと他クラスから見えないので、コピーを持ってる。
これは後付でこうなった、というのもある。
実装は、イベントハンドラに何個でも関連づけさせられるからそこでさせてる。

973 :デフォルトの名無しさん:2017/04/21(金) 21:13:36.92 ID:MpBIOwvX
>>971
モデルをどこに置くか、という話なんだよ。
Formの仕様だと、numericUpDownのValueプロパティを「モデルの値」として扱えば
すべてすっきり行く仕様になってる。だからそうしてる。
ところが2度描画禁止だとすっきり行かない。だからこれが疑問。
それならJavaScriptみたいに、最初から
「必ず1回redraw()を書かないとダメだけど、1回書けばいいだけです」の方が良かった。
だから、彼等なりの想定実装があったはずで、それを考えてる。

974 :デフォルトの名無しさん:2017/04/21(金) 21:15:27.48 ID:rPWpf+kQ
使って問題がある場面のバインディングなんて使わなきゃいーじゃん

マイクロソフトお作法病って損だと思う

975 :デフォルトの名無しさん:2017/04/21(金) 21:15:53.73 ID:Re4upQlq
>>963
EntityFrameworkはもう十分枯れてるだろバカ
Coreは確かに発展途上だけどね
元のレスを読まないからこんな的はずれなURLを貼っちゃう

976 :デフォルトの名無しさん:2017/04/21(金) 21:18:21.74 ID:lnct7jOB
イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
>>970の2段落目に賛成だな
見なおしたり他に移植するときにそっちの方が分かりやすいし

977 :デフォルトの名無しさん:2017/04/21(金) 21:33:34.84 ID:MpBIOwvX
>>974
バインディングといったから分かりにくいが、放置した場合は表示が間違ってるんだよ。
これは完全にアウト。

Fitボタンが押された→
モデルの値が変更された→
再描画された

これで「波形表示」は最新になるけど、
「表示開始位置」と「倍率」の表示されている値が古いままでしょ。
そしてFormのイベントはそれ用になってないんだよ。

>>976
> イベントがダブりそうなときはイベントを-して値代入後+しなおしているなあ
これってかなり面倒でしょ。

今のところタイマで遅らせるのが一番すっきりするからそうしようかと思っている。
(これは他部分で既に実装済みなのを流用出来るというのが大きいが)
redraw()を呼んだら16ms後にredraw_implement()が呼ばれて実際に再描画とか。
ただこんなの.NET作った頃から想定してたのかな?という疑問はある。

978 :デフォルトの名無しさん:2017/04/21(金) 21:34:54.35 ID:h0UgT1Ml
>>966
来年にはYAMLになってると思うよ

979 :デフォルトの名無しさん:2017/04/21(金) 21:37:01.31 ID:72Ff37pO
>>975
なんだ、枯れてるとか言ってボコボコ叩かれて悔しかった奴か
「Coreは確かに発展途上だけどね」
Core の前になんかつくだろカス

980 :デフォルトの名無しさん:2017/04/21(金) 21:49:04.78 ID:rPWpf+kQ
>>977
意味わからん
画面は自分が必要なときにデータを見て勝手に描画するじゃん
フォームはコントロールの操作によってデータを書き換えるじゃん
バインディングなんて使わなきゃ悩む要素皆無だったんでしょ?

981 :デフォルトの名無しさん:2017/04/21(金) 22:08:05.95 ID:Re4upQlq
>>979
おや、ようやくCoreを認識できたんだね

982 :デフォルトの名無しさん:2017/04/21(金) 22:08:53.85 ID:1MuUAA6h
>>979
自分が叩かれていることに気づいていないのは見苦しい

983 :デフォルトの名無しさん:2017/04/21(金) 22:09:14.20 ID:k73pGP5K
>>977
そのへんはレンダリングスレッドがUIスレッドと分かれてるWPFでやろうとしてたと思われ。

984 :デフォルトの名無しさん:2017/04/21(金) 22:29:56.50 ID:MpBIOwvX
>>983
え?WFPって描画はUIスレッドじゃなくていいのか?
それはすごくいい。
それだとスピンコントロールのボタン連打で描画が追いつかない時にも、
イベントが溜まることなく最新が常に表示されるね。
何もしなくても。

まあ何だかんだで新しい物は改良されてるってことだね。

985 :デフォルトの名無しさん:2017/04/21(金) 22:29:56.87 ID:Cei54Lla
かずきが日本マイクロソフトに入社してる!
本当に浦島状態

986 :デフォルトの名無しさん:2017/04/21(金) 22:34:32.90 ID:baDy0zQG
>>985
誰だよ?

987 :デフォルトの名無しさん:2017/04/21(金) 22:37:38.47 ID:k73pGP5K
>>984
描画はUIスレッドなのは変わらない。
UIスレッドで同じところにポンポン書き込んでも適当に間引かれる。

988 :デフォルトの名無しさん:2017/04/21(金) 22:37:41.43 ID:h0UgT1Ml
>>984
クソ重いから結果的にはWinFormsの方が遥かにレスポンス早いんだけどね

989 :デフォルトの名無しさん:2017/04/21(金) 23:07:08.58 ID:MpBIOwvX
>>987-988
うーむ、やはりイマイチか。

回答くれた皆さんありがとう。
俺は>>970ではないけど、次スレ俺が立ててもいいけど。(>>1)

990 :デフォルトの名無しさん:2017/04/22(土) 01:19:50.97 ID:Af8PazvW
>>954
なんか無茶苦茶だな。
クリックイベントの最中に描画処理を実行してるのか?
再描画させたいならInvalidateRectとかでWM_PAINTを発生させてそこでまとめて描画するのが作法だぞ

991 :デフォルトの名無しさん:2017/04/22(土) 03:39:27.34 ID:BJdj4TZ/
>>990
御説ごもっともだけど、そんな偉そうに言うほどのことでもないよ

992 :デフォルトの名無しさん:2017/04/22(土) 04:54:36.82 ID:y5zvwDCw
偉そうかどうかは関係なくない?w

993 :デフォルトの名無しさん:2017/04/22(土) 06:10:42.01 ID:4+2xx2Ut
>>992
発言の正当性より自己満足度で正当性を確保しているので重要です

994 :デフォルトの名無しさん:2017/04/22(土) 06:23:09.19 ID:9wvnPEyC
>>990
InvalidateRect発生させてもRect無視して全画面更新しちゃうよ。ふざけんな!
みたいな話だからな。ちょっと方向性が違うw

995 :デフォルトの名無しさん:2017/04/22(土) 06:45:50.45 ID:+hjaOcO8
>>991
2ch初めてか? w

996 :デフォルトの名無しさん:2017/04/22(土) 08:50:41.11 ID:iVvswOrb
次スレ立ててくる

997 :デフォルトの名無しさん:2017/04/22(土) 08:52:51.85 ID:iVvswOrb

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

998 :デフォルトの名無しさん:2017/04/22(土) 09:05:33.60 ID:/oxuzvQq
ワッチョイなしで立て直して

999 :デフォルトの名無しさん:2017/04/22(土) 09:09:40.54 ID:AhKt2WIP
やなこった

1000 :デフォルトの名無しさん:2017/04/22(土) 13:34:52.68 ID:3nsKygnV
1000

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 83日 20時間 48分 0秒

1002 :1002:Over 1000 Thread
2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/

▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php

290 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)