[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 09/03 07:28 / Filesize : 292 KB / Number-of Response : 1049
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


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

C#, C♯, C#相談室 Part92



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

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

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

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

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

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

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

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

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

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

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

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

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

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



561 名前:デフォルトの名無しさん mailto:sage [2017/03/21(火) 23:05:57.08 ID:UqOt5XZ1.net]
マンコリング?

562 名前:デフォルトの名無しさん mailto:sage [2017/03/22(水) 02:05:33.87 ID:Y ]
[ここ壊れてます]

563 名前:DOC/IGa.net mailto: オーバーロードがないのは多分キャプチャが原因だと思うよ
可能なら多分やってる、というかキャプチャ無しならオーバーロード可能にしてほしい感じ
さらにいうなら、キャプチャ無し指定をして普通のメソッドが単純に名前空間上に合わられないだけにして欲しい。
でもって、ローカル変数と被る名前OKにしてくれれば一番いい。
結局、ローカル関数にした理由はインテリセンスが機能不全になって欲しくないという話なだけだから。
[]
[ここ壊れてます]

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

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

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

567 名前:デフォルトの名無しさん mailto:sage [2017/03/22(水) 13:01:02.87 ID:+8Koiwe2.net]
基地外発想だな

568 名前:デフォルトの名無しさん mailto:sage [2017/03/22(水) 13:23:33.31 ID:6nIA/xoV.net]
フジテレビ的発想

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

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



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

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

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

574 名前:デフォルトの名無しさん mailto:sage [2017/03/22(水) 20:41:21.23 ID:qEl3ed9E.net]
だれよ

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

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

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

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

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

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



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

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

583 名前:っているのは年寄りだけだよw []
[ここ壊れてます]

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

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

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

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

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

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

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

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

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



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

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

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

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

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

596 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 02:30:27.90 ID:9gkqdxMB.net]
>>571
いるよね、こういう量的な進歩と質的な進歩の区別のつかない

597 名前:z
馬鹿な奴だ
[]
[ここ壊れてます]

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

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

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



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

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

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

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

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

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

606 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 04:45:12.92 ID:0wLqn0eU.net]
ATLがいつ滅んだんだよw

607 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 07:10:17.81 ID:UmFjwc/F.net]
昔の名残とかじゃなく、単にマルチスレッドで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ライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
>異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。
>これはソフトウェアが非常に複雑になる原因となってしまう。
>また、ロック順序のミスが引き起こすデッドロックは常にではなく
>たまに発生したりすることの多いバグ(時間的確率要因が関与する偶発性のあるバグ)であり、
>バグ取りが大変になるという問題があった[

608 名前:3]。
>
>そこで、1997年の Java の Swing からは、
>UI の操作は全てメインのUIスレッドであるイベントディスパッチスレッドから
>操作しなくてはならない、というルールを設けた。
[]
[ここ壊れてます]

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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



621 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 1 ]
[ここ壊れてます]

622 名前:9:28:24.32 ID:Un9Q+jtZ.net mailto: >>591
酷いやり方というのはある意味正しい
そもそもformsが腐っている以上綺麗な方法はハナから存在しない。
それでも誰にでもわかり、誰にでも修正可能なやり方っていうのが重要なんだよ。
それができなきゃ、一人で勝手にやっていろって話になる。
チームで作業は不可能だ。
[]
[ここ壊れてます]

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

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

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

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

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

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

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

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

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

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

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



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

632 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 20:26:39.42 ID:HovpjxiM.net]
>>598
GUI 組んだことないのか?
イベントってフレームワークからのアプリケーションの呼び出しだぞ
あとロックするのは GUI のフレームワークじゃなくてア

633 名前:vリケーションの方
マルチスレッド化したフレームワークだとイベントっていつ発生するかわからないのでお前みたいなよくわかってない奴が組むとデッドロックを引き起こしたりしやすいって話
[]
[ここ壊れてます]

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

645 名前:せることを考えたらわざわざそんな危険な構造にする意味がないってこと
前にも書いたけどUIなので超高速で画面のあちこちが更新できても意味ないしな
[]
[ここ壊れてます]

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

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

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

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

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



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

652 名前:デフォルトの名無しさん mailto:sage [2017/03/23(木) 23:47:48.47 ID:Ei+8urX3.net]
てす






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<292KB

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