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

C#, C♯, C＃相談室 P ..

488:でもないし難しい話じゃないなとも。プログラムとは違うけれど 3Dモデラーでツリー構造とか法線とか難解な数学概念が見ての通りの操作で動かしたり創れたりするようになって門外漢の3Dデザイナーが普通に使えるようになったように一度概念をキッチリ整理する必要があるんだよ、あれは。そして言語の作りこみがあの頃から甘くなってき始めてたな、ちょっと残念な感じになっていった時代だね。とりあえず腐り過ぎのWin10をWin7の仕様に戻せや、ストアもユニバーサルアプリも使い物にならん、色使いも糞でUIが見ずらい＞ microsoft あと、WindowsUpdateのタイミングはユーザーの自由にさせよ、お前がお前のタイミングで勝手にやったら業務はむちゃくちゃになる。

489:デフォルトの名無しさん
17/03/11 22:05:54.03 h5T3JHpB.net
>>466
タプルなんて昔からあるだろ

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

491:デフォルトの名無しさん
17/03/11 22:40:13.41 7U1HyGmG.net
>>472
いつからここが初心者用になったんだ

492:デフォルトの名無しさん
17/03/12 01:14:05.08 +ulIycHH.net
>>469
URLﾘﾝｸ(github.com)
によると、.NET4.7に入れることにしたみたいだね
nugetで済むのに.NETのバージョンを上げるのは面倒が多いし、今後C#のリリース速度を早めるならある程度まとめて.NET4.7にしようって考えじゃないかなぁ
言語機能の小出しについても他の言語と比べれば遅いし、互換性と将来を考えて慎重に作ってるから完全な完成を待つと永遠にリリースできなくなっちゃうし、やむをえんだろ
CLRのバージョンを保ってくれれば文句は無い

493:デフォルトの名無しさん
17/03/12 02:13:23.38 lK2SBg8L.net
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()}";
こんな感じですけど短く綺麗にしたいのですが…

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

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

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

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

498:デフォルトの名無しさん
17/03/12 09:23:31.23 7tB+K/sW.net
何でこの人キレてんの？あの日？

499:デフォルトの名無しさん
17/03/12 10:01:53.12 RIOf9bqD.net
みるからに自演臭くてキモイからじゃねw

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

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

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

503:デフォルトの名無しさん
17/03/13 07:01:39.19 WHuP7MmV.net
フォームのKeyPreviewプロパティをTrueにすると、すべてのキーイベントをまずフォームが受け取り、処理が終了してからフォーカスのあるコントロールに渡されるようになります。
ってdobon.netで見つけた
やったことはない

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

505:デフォルトの名無しさん
17/03/15 09:07:02.25 k1u612YY.net
すみません、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);

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

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

508:デフォルトの名無しさん
17/03/16 03:52:05.80 l+qA2/0G.net
C#でwebBrowserを使ってるんですが
以下のｈｔｍｌをwebBrowser.DocumentTextに突っ込んで表示させたいんですが
何故かwebBrowserではそのままjqueryを読み込むことが
できないようでスクリプトエラーが発生してしまいました
対処方法のわかる方いたら教えていただけますでしょうか？
↓以下のhtml
<!DOCTYPE html>
<head>
<meta charset=""utf8"">
<script src=""URLﾘﾝｸ(code.jquery.com)

509:.min.js""></script> <script type=""text/javascript""> $(function() { alert(""test"") }); </script> </style> </head> <body>

510:デフォルトの名無しさん
17/03/16 11:36:09.87 oyR0ujl0.net
なんでダブルクォーテーション２つ続いてるの？

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

512:デフォルトの名無しさん
17/03/16 16:58:42.52 Qa1xgsfZ.net
<style>
<head>
<body>
</style>
</head>
</body>

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

513:デフォルトの名無しさん
17/03/16 17:03:26.21 RyFuDdep.net
>>493
君は冷静だな

514:デフォルトの名無しさん
17/03/16 17:05:05.86 Qa1xgsfZ.net
HTMLソース
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>HTML5サンプル</title>
</head>
<body>
<p>HTML5で作成しました！</p>
</body>
</html>
連投ですまん
もっと解り易いサンプル

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

516:デフォルトの名無しさん
17/03/16 18:38:16.89 RyFuDdep.net
>>496
君は詳しいな

517:デフォルトの名無しさん
17/03/16 20:09:32.60 G/L2rMHg.net
簡単に単体テストできるのか知りたいです
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 を使ってますが、他のフレームワークでもいいです

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

519:デフォルトの名無しさん
17/03/17 07:37:50.30 gTyXrRTf.net
よく分からんな
Taskなんだから結果が出るのを待機すればいいだろ
Progressは呼ばれたらcalledフラグを立てるようにしてそいつでAssetする
タイムアウトが必要かどうかは状況次第
2つめは、内部でFileStreamを使っているならだが
Streamを受け取るインターフェースを追加する
クッソ遅いStreamは自由に再現できる

520:デフォルトの名無しさん
17/03/17 08:16:11.77 VDcrtJ6N.net
>>496
ありがとうございます！大変助かりました！

521:デフォルトの名無しさん
17/03/17 21:11:54.40 G6TjLWRU.net
>>499
やっぱり妥協かなー
>>500
(2) はなるほどね。作ってみる
(1) なんだけど、Progress.Report() での通知は、タスクを await で待機したとしても、
待機が終わった後でも Action<T> が呼ばれているとは限らない
巨大なタスクを

522:渡して、 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); }

523:デフォルトの名無しさん
17/03/18 00:00:39.16 3lIBsEeS.net
惜しいところまでは行ってるな
Progressのインスタンスを渡すのではなく
IProgressを継承し同期のReportを実装したクラスのインスタンスを渡す

524:デフォルトの名無しさん
17/03/18 10:58:29.15 UTVmwL6L.net
ふむー、こうか
確かに 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 にも貼っておく
URLﾘﾝｸ(pastebin.com)

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

526:デフォルトの名無しさん
17/03/19 00:19:27.37 8DI2TWvJ.net
>>505
FileInfo

527:デフォルトの名無しさん
17/03/19 00:30:52.74 VKtnwSVx.net
「ファイルのタイムスタンプ」でグーグル先生に聞けば
URLﾘﾝｸ(www.atmarkit.co.jp)
が一発で出てくるんだけど掲示板で聞く方が面倒じゃないの

528:デフォルトの名無しさん
17/03/19 06:34:49.31 bkt1N2YW.net
検索知らないんでしょ

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

530:デフォルトの名無しさん
17/03/19 14:33:00.16 DWsQT7k4.net
「お前ら、検索頼むわ（丸投げ）」

531:デフォルトの名無しさん
17/03/19 14:45:08.30 1DEeFth3.net
おまいらは回答する機械

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

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

534:デフォルトの名無しさん
17/03/19 15:04:25.29 1DEeFth3.net
それにしたって餌としてはしょぼすぎる

535:デフォルトの名無しさん
17/03/19 15:10:14.91 p4p+SSjy.net
ボランティアを馬鹿にすんじゃねーぞ、コラ！

536:デフォルトの名無しさん
17/03/19 16:02:53.06 T5IZ831S.net
人力検索

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

538:デフォルトの名無しさん
17/03/19 18:48:36.73 lJcyTqFl.net
>>517
でも質問してくれないと寂しいんだろ？

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

540:デフォルトの名無しさん
17/03/19 21:56:16.72 HC9gBYvT.net
マ板行けって思うスレ多いよな

541:デフォルトの名無しさん
17/03/20 01:44:39.35 SU/B8

542:MWa.net

543:デフォルトの名無しさん
17/03/20 10:11:03.85 Afs087wZ.net
>>520←コイツの馴れ合おうとするレスうざっ

544:デフォルトの名無しさん
17/03/20 12:24:29.57 y4a+UdUh.net
>>522
マ板行け

545:デフォルトの名無しさん
17/03/20 14:10:48.91 pi/vFj6F.net
>>523お前が行け

546:デフォルトの名無しさん
17/03/20 14:57:32.61 98bjORSB.net
ここは幼稚園じゃないんだが。

547:デフォルトの名無しさん
17/03/20 15:41:51.51 4DDUMBY5.net
似たようなもんよ

548:デフォルトの名無しさん
17/03/20 15:48:57.55 LcNjV7jZ.net
言い争いを見てたら幼稚園児とたいして変わらん気がする

549:デフォルトの名無しさん
17/03/20 16:00:23.53 pi/vFj6F.net
↑
いい加減うざいって、お前らずっとスレちがい

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

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

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

553:デフォルトの名無しさん
17/03/21 19:18:26.99 bA9h/8/p.net
似たような処理するのにﾒｿｯﾄﾞ2つも要らない
中で分岐させて使え、その方が保守楽だから
↑
って言われたことある。
オマエラも結局中で分岐させてる？

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

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

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

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

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

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

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

561:デフォルトの名無しさん
17/03/21 23:05:57.08 UqOt5XZ1.net
マンコリング?

562:デフォルトの名無しさん
17/03/22 02:05:33.87 Y

563:DOC/IGa.net

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

565:デフォルトの名無しさん
17/03/22 11:28:29.87 hks7EAC1.net
C#の糞拡張はこれからが本番ですよ。

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

567:デフォルトの名無しさん
17/03/22 13:01:02.87 +8Koiwe2.net
基地外発想だな

568:デフォルトの名無しさん
17/03/22 13:23:33.31 6nIA/xoV.net
フジテレビ的発想

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

570:デフォルトの名無しさん
17/03/22 14:47:13.98 T50yqk9Q.net
>>544
できらぁ！

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

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

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

574:デフォルトの名無しさん
17/03/22 20:41:21.23 qEl3ed9E.net
だれよ

575:デフォルトの名無しさん
17/03/22 20:59:39.74 eP+YAd4z.net
>>549
それ、お前がメクラなだけじゃね？

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

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

578:デフォルトの名無しさん
17/03/22 22:28:00.53 MyrW3Mfd.net
>>555
どんどんお前が老いていってるだけ

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

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

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

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

583:っているのは年寄りだけだよw

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

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

586:デフォルトの名無しさん
17/03/23 02:04:38.43 VjAjr2s9.net
>>559
UI関連は、UIスレッドでのみ動作することを前提に設計することで、パフォーマンスを上げてる。
マルチスレッド対応にすると排他制御等が増えてしまい、パフォーマンスが下がる。
>>561
非同期処理とか書きやすくなったから、最近は割と楽だろ。
Invokeも使う必要ないし。

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

588:デフォルトの名無しさん
17/03/23 02:07:28.88 Un9Q+jtZ.net
>>563
Task作った奴はバカだと思うwww
Invokeの方がまだ誰にでも分かりやすい。
継続なにそれおいしいのwww
関数型言語面白いねって感じだね

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

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

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

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

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

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

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

596:デフォルトの名無しさん
17/03/23 02:30:27.90 9gkqdxMB.net
>>571
いるよね、こういう量的な進歩と質的な進歩の区別のつかない�

597:z 馬鹿な奴だ

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

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

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

601:デフォルトの名無しさん
17/03/23 02:36:32.46 9gkqdxMB.net
しかし、マルチコアっていうのは苦し紛れの「苦肉の策」であってポジティブな進歩じゃないって
パソヲタレベルでも知ってる常識だと思ったけどプログラマでもそういう認識がない奴がいるんだね。
そういう奴は「人月の神話」って言葉も聞いたことないんだろうな。
生産性は作業者の投入人数に比例しないのはコンピュータも同じだよ馬鹿

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

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

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

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

606:デフォルトの名無しさん
17/03/23 04:45:12.92 0wLqn0eU.net
ATLがいつ滅んだんだよw

607:デフォルトの名無しさん
17/03/23 07:10:17.81 UmFjwc/F.net
昔の名残とかじゃなく、単にマルチスレッドでUI部品を扱うのが大変だということだと思うんだが
ユーザーインターフェイススレッド - Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
>例えば、Java の AWT では、1996年の最初の時点では、
>単純にスレッド間でデータ共有型のマルチスレッドになっていた。
>しかし、データ共有するには、ロックをかけないといけないが、
＞親コンポーネントから子コンポーネントを呼んだり、
>コールバックで子から親を呼んだり、
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
>異なるスレッド間で双方向に呼び合うときは、ロックの順番に注意を払う必要がある。
>これはソフトウェアが非常に複雑になる原因となってしまう。
>また、ロック順序のミスが引き起こすデッドロックは常にではなく
>たまに発生したりすることの多いバグ（時間的確率要因が関与する偶発性のあるバグ）であり、
>バグ取りが大変になるという問題があった[

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

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

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

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

612:デフォルトの名無しさん
17/03/23 10:27:00.68 BTeOg9CT.net
>>564
COMのアパートメント問題を解決するためじゃないの？
厳密にはInvokeしなくて良いケースもあるけど、それを保証する方法が皆無に等しいという。
ウインドウメッセージ云々とか、本質とはかけ離れている気が。

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

614:デフォルトの名無しさん
17/03/23 12:53:23.45 Un9Q+jtZ.net
>>586
UI側がバージョン管理システムみたいな扱いをすればいいんだと思うけどね
非ロック型で同期をとる方法としては有効だと思う。
いわゆる
読み込んで、内容を変更して、読み込み時点データとともにUIに返す。
UI側は、ロックして読み込み時点と現状が一致しているなら置換してアンロックそして処理終了。
ロックオブジェクトが自分自身に限られるからデッドロックの可能性はない。
この方法の場合、読み出すだけならロック不要でいつでも読み込めるしね。
俺は、UIに関してはそういう設計にして自分のメソッドはすべてスレッドセーフだ。
長年の実績ある方法だし、このやり方は非常に優れていると思う。
更新失敗とリトライは発生するが、並列度はかなり高くなる。
デッドロックは皆無で、見通しも良い。

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

616:デフォルトの名無しさん
17/03/23 17:07:47.97 EtPn1ouj.net
なんか酷いやり取りだね
マルチスレッドを根本的に理解してないのが何人かいるねw
スレッドセーフに作ることは高コストだから特に理由がない限りそうしないのは
マルチスレッド理解の初歩の初歩だと思うんだけど。
あれだ、UIは別スレッドからのアクセスを検出して例外投げるようになってるわけだけど、
例外が投げられなければ何も問題ないはずだ、っていうVBerな発想なのかねw

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

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

619:デフォルトの名無しさん
17/03/23 18:15:58.21 ncdnXTN/.net
マルチスレッド動作のformにとは言ってないんだよ・・・

620:デフォルトの名無しさん
17/03/23 18:57:02.57 99dRkoLd.net
>>592
そこでwpfのバインディングですよ

621:デフォルトの名無しさん
17/03/23 1

622:9:28:24.32 ID:Un9Q+jtZ.net

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

624:デフォルトの名無しさん
17/03/23 19:32:40.10 Ei+8urX3.net
>>583
> GUIライブラリからアプリケーションをコールバックしたりと、
これってあるか？ピンとこない。
そもそも、UIってロックする必要があるか？
現状、UIスレッドとタスクスレッドは別で、結果的にプログレスバー等の更新にはinvokeを使うしかない。
これがウザイから「直に書き込みさせてくれ」というのが俺の希望。
そもそも、排他的な実装をしなければならない理由がないだろ。
プログレスバーなんて普通は共有しないし、
してたらしてたで「どちらの内容が表示されてもいい」が仕様になるのだから、
レーシングしたところで問題ない。
結果、リクエストがあったらただ更新すればいいだけ、それを表示すればいいだけ、で終わりじゃないか？
ファイルみたいにロックありきの物ではないと思うんだが。

625:デフォルトの名無しさん
17/03/23 19:35:54.46 g/kXmQSp.net
マルチスレッドアクセス可能なGUI採用してるシステムなんてあったっけ
UIスレッドモデルが遺産だというのなら
新しいシステム(Windowsに限らんぞ)ほど「そうなってはいない」はずだが
実際は最近のOS(やはりWindowsに限らない)でもUIスレッドモデルだ
何故だろうなあ
下手の考えなんぞ大抵は
「先人が思いついたけどあえてやらなかった」か「すでに失敗した」か

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

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

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

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

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

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

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

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

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

635:デフォルトの名無しさん
17/03/23 20:48:03.89 Ei+8urX3.net
>>606
今時GUIしかやらんだろ。
が、まあこっちの認識がずれていたのは分かった。
>アプリケーションからGUIライブラリを呼んだり、
>GUIライブラリからアプリケーションをコールバックしたりと、
>双方向に呼び出すことが多く、
前者が「プログレスバーの更新」で、
後者が「 XXX.click += YYYY;」か。
確かに双方向だ。
で、ロックは必要か？
プログレスバーの更新なんて、ロックする必要ないだろ。
他もそうだと思うが。

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

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

638:デフォルトの名無しさん
17/03/23 21:00:57.40 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:デフォルトの名無しさん
17/03/23 21:14:48.29 Ei+8urX3.net
>>610
いや、ロックの必要はないだろ。
正確に言えば、外部からの明示的なロックが必要無いように作れば作れるだろ。
今そうなってないだけで。
要するにプログレスバーを UI, Task_thread_A, Task_thread_B の
どこからも更新出来るようにしたいとして、
全部、 progressBar.value = x; と書かせろ、と言いたいだけで。
内部的に細かくロックして、順に処理するのはCLRが勝手にすればいい。
その結果、それぞれのスレッドが微妙にロックするのも仕方ない。
ただ、循環ロックにならない限り、デッドロックにはならないだろ。
そして普通に書けば、循環ロックにはならないだろ。

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

641:デフォルトの名無しさん
17/03/23 21:24:07.98 NnBP2eXC.net
>>608
GUIしかやらない？どこの世界の話だよ

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

643:デフォルトの名無しさん
17/03/23 21:30:44.46 5A+rvbXC.net
生兵法はケガの元だな
毛がなくて良かったね～

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

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

646:デフォルトの名無しさん
17/03/23 21:33:06.10 0wLqn0eU.net
>>588
寝ぼけるのはいいかげんにしろ。

647:デフォルトの名無しさん
17/03/23 21:34:23.52 5A+rvbXC.net
3行以上はキチガイ

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

649:デフォルトの名無しさん
17/03/23 23:30:21.13 u0oYY3Ci.net
>>620
で、お前はどうやるんだい？

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

651:デフォルトの名無しさん
17/03/23 23:39:06.22 uQaoHdGv.net
っていうか、何でこんなマルチスレッドの初歩みたいな話になってるの？w

652:デフォルトの名無しさん
17/03/23 23:47:48.47 Ei+8urX3.net
てす

653:デフォルトの名無しさん
17/03/23 23:50:59.28 Ei+8urX3.net
>>617
ちげーよ。まあ結論としては、簡単に出来るけどC#はやらなかった、というだけだ。
そして俺はこの選択は間違いだったと見るね。
実装例としては以下。(C#の文法は知らないので真似てみた。適宜脳内修正よろしく）
//ここにコードを書いたのだが、403 Forbidden になるぜorz
mutexを使う場合、mutex確保中に他ロックを取りに行かなければデッドロックはしない。
或いはthread_IDを付けておいて、UIなら直接変更、その他ならinvokeにしてもいい。
いずれにしても、ユーザー側にはinvokeが見えなくなる（隠蔽される）
これの方が良かったと思うよ。いちいち混乱しなかった。
そちらの例は、2人のユーザ間でのデッドロックであって、
俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
なお、解法は、普通に「両方取れなかった場合は一旦全部リリースしてリトライ」でいい。
ただし今時はそれはDB任せで、ユーザ側でのロック管理なんてしない（はず）

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

655:デフォルトの名無しさん
17/03/23 23:53:41.78 u0oYY3Ci.net
>>622
ケースバイケースだろ
そもそも >>617 は説明のためのサンプルだから不満なら両方書き込みのケースを考えればいいだけ
>>623
マルチスレッドGUIフレームワークに夢見てる奴がいるからでしょ w

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

657:デフォルトの名無しさん
17/03/23 23:57:20.64 u0oYY3Ci.net
>>625
> 俺が今話しているUI/タスクスレッド間の例じゃないじゃん。
そんなことを言ってるのお前だけ
>>583 をちゃんと読み返せよ

658:デフォルトの名無しさん
17/03/24 00:00:02.01 Lq7k+m1v.net
>>622
そんな力業してないでリーダー/ライターロック使いなよ。
比較のループとかデータ量次第ではCPUパワーの無駄遣いだろ。

659:デフォルトの名無しさん
17/03/24 00:07:18.67 P/PrHj1p.net
既製品に文句があるなら自分で作ってgithub
これができないプログラマはいつまでも三流のまま
コードを書き使ってもらい持論を証明するんだよ

660:デフォルトの名無しさん
17/03/24 00:13:35.16 OAgok+ci.net
Windows Formsの場合は、単純にFormがActiveXコンテナになり得るから、
アパートメントの制限に対応するために用意された、実装上の都合による物だよ
おそらく、ロックの問題ではなく
リソースリークを根本的に解決する方法がないから用意された手続きなんだよ。
ラップして

661:解決できると思うなら、それで良いんじゃないか

662:デフォルトの名無しさん
17/03/24 00:14:57.73 gW3AbLz/.net
だからUIスレッドが気になるなら、wpfでMVVMやれば解決でしょうに

663:デフォルトの名無しさん
17/03/24 00:38:36.13 9w5lj4S/.net
UWPで非同期メソッドとかTask使ってるけどすごい不毛。
非同期メソッドの完了を基本的にはawaitで待つから
非同期メソッドを複数回実行するような場合だと
全部同期呼び出しにして全部まとめてTask.Runしたい。

664:デフォルトの名無しさん
17/03/24 00:50:30.06 RtKD05ZR.net
>>630
俺は622じゃないけど。
従来型のロック機構だとコストが高すぎる場合もあるんだよ。
俺は詳しくないけど、多分Erlangとかの世界で。
mutex等は共有メモリへの書き込みが生じるから実はかなり重い。

665:デフォルトの名無しさん
17/03/24 02:13:48.63 5bMFJR3b.net
馬鹿にマルチスレッド。

666:デフォルトの名無しさん
17/03/24 02:33:18.25 99176uAd.net
結局少しでも重たい処理は全部ワーカーにしなけりゃならないから
UI弄る時だけInvokeした方が見通しすっきりするんだよねw
async/awaitとか使うよりは
ここがUIスレッドですってはっきりわかる。

667:デフォルトの名無しさん
17/03/24 02:44:50.15 7cONiVN5.net
ここはまだWinFormsの時代かｗ

668:デフォルトの名無しさん
17/03/24 02:50:50.13 99176uAd.net
WPF？誰が使うか
そんなもんが必要なモバイルなら普通にJavaScriptにWebアプリで行くわって感じだねw

669:デフォルトの名無しさん
17/03/24 03:11:50.24 m/Lurhmo.net
>>612
progressBar.Value+=1
としたときに
1.読み込み
2.加算して書き込み
の処理が必要とすると、1と2の間に別スレッドが書き換えを行うことで結果が矛盾する
Interlocked命令を使えばそれは防げるけど、MaxValueを超えないかとかの判定が入るので結局ロックが必要
この程度ならまだしも、裏でWin32やCOMを叩いてるコントロールはさらにややこしい

次ページ