C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 >>
■6806 　Re[7]: 非同期TCP接続
□投稿者/ れい -(2007/08/24(Fri) 01:29:06)
    2007/08/24(Fri) 05:26:29 編集(投稿者)

    ■No6804 (なちゃ さん) に返信
    > CompleteSynchronouslyはチェックしとくにこしたことはないとは思いますが、
    > どっちにしてもIsCompleteの方は必須じゃないでしょうか？

    パフォーマンスだけの問題ですから、どうでもいいといえばいいですし、
    IAsyncResultの実装とかOSとかに依りますので確かなことはなんとも言えないのですが。

    ファイルやSocketなど、いろいろやってみましたが、
    IsCompleteをチェックしないほうがいい場合もありました。レアですが。
    チェック無しでAsyncWaitHandleを呼ぶのはやはりダメでした。
    CompleteSynchronouslyは呼んでも呼ばなくてもあまり変わりませんでした。
    そもそもtrueを返す実装は殆どないようです。

    ここから.Netでの実装とは別の話になります。
    処理にかかる時間のばらつきが大きいが、
    時間の予想が付く処理というのはよくあります。
    たとえばファイルに対するロックがあります。
    ロック要求は普通時間がかかりますが、
    同じファイルに対する2回目のロックは非常に高速にできます。
    データの読み込み操作も、何かキャッシュが介在するなら
    2回目は高速に処理できます。

    そういった場合、2回目の呼び出しは非同期呼び出しでも
    同期的に処理するのが有利です。

    こういった処理に対する非同期呼び出しを待つ場合、
    もしIsCompleteが重いのであれば
    CompleteSynchronouslyだけをチェックするほうが有利になります。
    処理が戻ったときにはCompleteSynchronouslyは確定してるので
    呼び出しコストはほぼ0ですから。

    IAsyncResultのような同期の方法は.Net以前からあって、
    応用が広いのでいろいろな処理系によるいろいろな実装があります。
    実装に応じてCompleteSynchronouslyとIsCompleteのどちらをチェックをするか、
    両方チェックするか考えて使うのがいい方法です。

    ですので、

    >※ああ、必須ってのは、CompleteSynchronously は IsComplete の代わりにはならないという意味です。

    処理系や実装によっては代わりになる場合もよくあります。

    CompleteSynchronouslyだけをチェックしたほうがいい場合が
    .Netであるかどうかは私は知りません。
    IAsyncResultのデザインでは、合ってもおかしくはないと思います。
    たぶんほとんどないので、私は普通はIsCompleteだけチェックしてます。
記事No.6782 のレス /過去ログ17より / 関連記事表示
削除チェック/

■7271 　Re[17]: MSDNの目次が欲しい
□投稿者/ れい -(2007/09/03(Mon) 12:04:45)
    ■No7265 (渋木宏明(ひどり) さん) に返信
    >>あとblogに対するコメントとかトラックバックみたいに、
    >>特定のページに自分のコメントを残したいですね。
    >
    > MSDN Wiki じゃ駄目なんです？
    >

    自分だけのメモ書きに使いたいので以下の点がだめです。
    ・サインインしなきゃいけない
    ・ローカルに保存できない
    ・他人に見えないモードがない
    ・遅い

    確認してみたら、
    YASさんのコードではダメでした。
    tocがうまく広がらなかったり、
    リンク先が違う階層に繋がってたりする場合があります。

    なので目次取得は失敗してました。
記事No.7227 のレス /過去ログ18より / 関連記事表示
削除チェック/

■29495 　Re[7]: dequeから文字列作成
□投稿者/ 渋木宏明(ひどり) -(2008/12/10(Wed) 12:14:22)
>
    > 実際にやってみたんですけど殆ど差はでなかったです。
    > まぁ、スレ主さんが2秒速くなったと言っているので流しましたが。。。

    Debug ビルドと Release ビルドの違いだったりしてｗ

    普通に考えて、連結するべき語が配列やコレクションの格納されているなら、その語の数分だけ誰かがどこかでループを回さにゃらなんでしょう。

    であるなら、処理を高速化するために「ループを除去する」って方向性は無いと思うんだけどなぁ？
    （見掛け上ループを除去する方法ならいくらでもあるでしょうけど）

    単純な連結であるなら、連結するべき語の数に比例した処理時間が必要なのもまた不可避。

    となると、あと出来ることつったら「連結という操作そのものの高速化」という方向で考えるべきなんじゃないかと。

    .NET だと、「string を + 演算子でつなぐよりも StringBuilder 使った方が速いよね」てのがまさにそのパターン。
記事No.29439 のレス /過去ログ53より / 関連記事表示
削除チェック/

■31811 　Re[7]: DBデータ読み込み時のマルチスレッド処理について
□投稿者/ 倉田　有大 -(2009/01/29(Thu) 09:11:26)
    > ほほぅ。そうですか。
    > 御教示頂いた内容で修正すること自体は可能なのですが、
    > ひとつの命令文で30秒かかるとその30秒間は別スレッドで発生した
    > メッセージはデキューされないということなんでしょうか?
    > 後学のためにも教えて頂けないでしょうか?

    InvokeがそもそもGUIを作成したスレッドで処理させることですから、SELECTがGUIを動かすスレッド動いていますから、
    SELECT文を動かしているメソッド抜けた後に、Invokeさせたメソッドが動くんじゃないかな。
記事No.31744 のレス /過去ログ56より / 関連記事表示
削除チェック/

■69408 　DataGridView上のチェックボックス
□投稿者/ 長長 -(2013/12/24(Tue) 21:01:18)

    分類:[VB.NET/VB2005 以降]　

    Private Sub cmdCheck_Click(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles _cmdCheck_0.Click, _cmdCheck_1.Click, _cmdCheck_2.Click
    Dim Index As Short = GetIndex(eventSender)
    ' ■変数定義
    Dim wLP_CNT As Integer = 0

    For Each dgr As DataGridViewRow In DataGridView1.Rows

    ' ■押下されたボタンにより処理
    Select Case Index
    Case 0
    ' 全てチェック
    DataGridView1(0, wLP_CNT).Value = True
    Case 1
    ' 全て取消
    DataGridView1(0, wLP_CNT).Value = False
    Case 2
    ' チェック反転
    If CType(dgr.Cells("cCheck").Value, Boolean) Then
    DataGridView1(0, wLP_CNT).Value = False
    Else
    DataGridView1(0, wLP_CNT).Value = True
    End If
    End Select
    wLP_CNT += 1
    Next
    End Sub

    上記のコードで、全てチェック、全て取消はうまくいくのですが、
    チェック反転(チェックがある時は「False」チェックなしの時は「True」)の
    処理だけがうまく反転せず、全てにチェックが入ります。

    お解りの方、よろしくお願いします。

    前提条件
    ・環境：VB2008
    　OS：Win7








親記事 /過去ログ118より / 関連記事表示
削除チェック/

■87886 　Re[1]: 動的に作成した大量のボタンのイベント分岐について
□投稿者/ 774RR -(2018/07/11(Wed) 11:48:05) 
    普通に Designer で各ボタンを事前に生成しておき、各ボタンに別ハンドラを生成すればそれで済むわけですが、
そうしたくない理由がある？

private void button2_Click(object sender, EventArgs e) { Form2 を表示 }
private void button3_Click(object sender, EventArgs e) { Form3 を表示 }
private void button4_Click(object sender, EventArgs e) { Form4 を表示 }


Tag プロパティに格納しておいた値でほげほげするとか。
記事No.87881 のレス /過去ログ151より / 関連記事表示
削除チェック/

■87910 　Re[4]: 動的に作成した大量のボタンのイベント分岐について
□投稿者/ WebSurfer -(2018/07/12(Thu) 18:55:57)
    ■No87891 (なっとう さん) に返信

    一つ言い忘れました。

    switch 文を提案しておきながら何ですが、自分的にお勧めは 774RR さんが No87886
    に書かれたハンドラを別々に分ける案です。


    それ以外は「面倒」を避けようと思ってやった結果がかえって面倒になるという本末転倒
    な結果になるような気がします。

    特に保守を考えた場合。
記事No.87881 のレス /過去ログ151より / 関連記事表示
削除チェック/



<< 0 >>
パスワード/

- Child Tree -