プレーンなDelegateパラメーターとして提供されたときにラムダ式をキャストする必要がある理由

StackOverflow https://stackoverflow.com/questions/411579

  •  03-07-2019
  •  | 
  •  

質問

System.Windows.Forms.Control.Invoke（Delegate method）メソッドを取得します

これによりコンパイル時エラーが発生する理由：

string str = "woop";
Invoke(() => this.Text = str);
// Error: Cannot convert lambda expression to type 'System.Delegate'
// because it is not a delegate type

それでも問題なく動作します：

string str = "woop";
Invoke((Action)(() => this.Text = str));

メソッドがプレーンなデリゲートを期待するのはいつですか？

役に立ちましたか？

解決

ラムダ式は、デリゲート型または式ツリーのいずれかに変換できますが、どのデリゲート型を知っている必要があります。署名を知るだけでは十分ではありません。例えば、私が持っていると仮定します：

public delegate void Action1();
public delegate void Action2();

...

Delegate x = () => Console.WriteLine("hi");

xで参照されるオブジェクトの具体的なタイプはどうなると思いますか？はい、コンパイラは適切な署名を使用して新しいデリゲート型を生成できますが、それはほとんど有用ではなく、エラーチェックの機会が少なくなります。

Control.InvokeでActionを簡単に呼び出せるようにする場合、最も簡単な方法は、コントロールに拡張メソッドを追加することです：

public static void Invoke(this Control control, Action action)
{
    control.Invoke((Delegate) action);
}

他のヒント

ラムダを何度もキャストするのはうんざりですか？

public sealed class Lambda<T>
{
    public static Func<T, T> Cast = x => x;
}

public class Example
{
    public void Run()
    {
        // Declare
        var c = Lambda<Func<int, string>>.Cast;
        // Use
        var f1 = c(x => x.ToString());
        var f2 = c(x => "Hello!");
        var f3 = c(x => (x + x).ToString());
    }
}

ユーザーがUIスレッドにマーシャリングしようとしているため、これを取得するのは10分の9です。怠zyな方法は次のとおりです。

static void UI(Action action) 
{ 
  System.Windows.Threading.Dispatcher.CurrentDispatcher.BeginInvoke(action); 
}

入力されたので、問題はなくなり（qv Skeetの答え）、この非常に簡潔な構文があります：

int foo = 5;
public void SomeMethod()
{
  var bar = "a string";
  UI(() =>
  {
    //lifting is marvellous, anything in scope where the lambda
    //expression is defined is available to the asynch code
    someTextBlock.Text = string.Format("{0} = {1}", foo, bar);        
  });
}

ボーナスポイントについては、別のヒントがあります。 UIの場合はこれを行いませんが、SomeMethodが完了するまでブロックする必要がある場合（要求/応答I / O、応答の待機など）は、 WaitHandle （qv msdn WaitAll、WaitAny、WaitOne）。

AutoResetEventはWaitHandleの派生物であることに注意してください。

public void BlockingMethod()
{
  AutoResetEvent are = new AutoResetEvent(false);
  ThreadPool.QueueUserWorkItem ((state) =>
  {
    //do asynch stuff        
    are.Set();
  });      
  are.WaitOne(); //don't exit till asynch stuff finishes
}

そして、物事が絡まる可能性があるため、最後のヒント：WaitHandlesがスレッドを停止させます。これが彼らのやるべきことです。 UIスレッドが停止している間にUIスレッドにマーシャリングしようとすると、アプリがハングします。この場合、（a）いくつかの深刻なリファクタリングが適切に行われ、（b）一時的なハックとして次のように待つことができます：

  bool wait = true;
  ThreadPool.QueueUserWorkItem ((state) =>
  {
    //do asynch stuff        
    wait = false;
  });
  while (wait) Thread.Sleep(100);

ピーター・ウォン。あなたはダマンです。 あなたのコンセプトをもう少し進めて、私はこれら2つの機能を思いつきました。

private void UIA(Action action) {this.Invoke(action);}
private T UIF<T>(Func<T> func) {return (T)this.Invoke(func);}

これら2つの関数をフォームアプリに配置し、このようなバックグラウンドワーカーから呼び出しを行うことができます

int row = 5;
string ip = UIF<string>(() => this.GetIp(row));
bool r = GoPingIt(ip);
UIA(() => this.SetPing(i, r));

少し怠け者かもしれませんが、ワーカーが実行する機能を設定する必要はありません。 このような場合に非常に便利です

private void Ping_DoWork(object sender, System.ComponentModel.DoWorkEventArgs e)
{
  int count = this.dg.Rows.Count;
  System.Threading.Tasks.Parallel.For(0, count, i => 
  {
    string ip = UIF<string>(() => this.GetIp(i));
    bool r = GoPingIt(ip);
    UIA(() => this.SetPing(i, r));
  });
  UIA(() => SetAllControlsEnabled(true));
}

本質的に、gui DataGridViewからいくつかのIPアドレスを取得し、pingを実行して、結果のアイコンを緑または赤に設定し、フォーム上のボタンを再度有効にします。はい、それは<！> quot; parallel.for <！> quot;です。バックグラウンドワーカーで。はい、それはオーバーヘッドの呼び出しがたくさんありますが、短いリストでは無視でき、よりコンパクトなコードです。

@Andrey Naumov の回答に基づいて、これを構築しようとしました。これはわずかな改善かもしれません。

public sealed class Lambda<S>
{
    public static Func<S, T> CreateFunc<T>(Func<S, T> func)
    {
        return func;
    }

    public static Expression<Func<S, T>> CreateExpression<T>(Expression<Func<S, T>> expression)
    {
        return expression;
    }

    public Func<S, T> Func<T>(Func<S, T> func)
    {
        return func;
    }

    public Expression<Func<S, T>> Expression<T>(Expression<Func<S, T>> expression)
    {
        return expression;
    }
}

タイプパラメーターSは、仮パラメーター（残りのタイプを推測するために最低限必要な入力パラメーター）です。次のように呼び出すことができます：

var l = new Lambda<int>();
var d1 = l.Func(x => x.ToString());
var e1 = l.Expression(x => "Hello!");
var d2 = l.Func(x => x + x);

//or if you have only one lambda, consider a static overload
var e2 = Lambda<int>.CreateExpression(x => "Hello!");

同じクラスで、同様にAction<S>とExpression<Action<S>>のオーバーロードを追加できます。デリゲートおよび式のタイプに組み込まれた other の場合、Lambda、Lambda<S, T>、Lambda<S, T, U>などの個別のクラスを記述する必要があります。

このアプローチの利点は、元のアプローチよりも優れています：

  1. 型指定が1つ少なくなりました（仮パラメータのみを指定する必要があります）。

  2. 例に示すように、Func<int, T>がたとえばTである場合だけでなく、どのstringに対しても自由に使用できます。

  3. 式をすぐにサポートします。以前のアプローチでは、次のようにタイプを再度指定する必要があります。

    var e = Lambda<Expression<Func<int, string>>>.Cast(x => "Hello!");

//or in case 'Cast' is an instance member on non-generic 'Lambda' class:
var e = lambda.Cast<Expression<Func<int, string>>>(x => "Hello!");

    式用。

  4. 他のデリゲート（および式）型のクラスを拡張することも、上記と同様に面倒です。

    var e = Lambda<Action<int>>.Cast(x => x.ToString());

//or for Expression<Action<T>> if 'Cast' is an instance member on non-generic 'Lambda' class:
var e = lambda.Cast<Expression<Action<int>>>(x => x.ToString());

私のアプローチでは、型を1回だけ宣言する必要があります（Func sでは1つ少なすぎる）。

Andreyの答えを実装するもう1つの方法は、完全に汎用的ではないようなものです

public sealed class Lambda<T>
{
    public static Func<Func<T, object>, Func<T, object>> Func = x => x;
    public static Func<Expression<Func<T, object>>, Expression<Func<T, object>>> Expression = x => x;
}

つまり、次のようになります：

var l = Lambda<int>.Expression;
var e1 = l(x => x.ToString());
var e2 = l(x => "Hello!");
var e3 = l(x => x + x);

入力はさらに少なくなりますが、特定のタイプセーフティが失われます。 imo、これは価値がありません。

パーティーに少し遅れましたが、このようにキャストすることもできます

this.BeginInvoke((Action)delegate {
    // do awesome stuff
});

 this.Dispatcher.Invoke((Action)(() => { textBox1.Text = "Test 123"; }));
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top