Re eficiencia - no está claro lo que quiere decir, pero se pueden utilizar para lograr eficiencia, evitando la reflexión costosa. Por ejemplo, al usar Delegate.CreateDelegate
para crear un delegado preestablecido (escrito a máquina) en un método dinámico/buscado, en lugar de usar el (más lento) MethodInfo.Invoke
.
Para obtener un ejemplo trivial (acceda al patrón estático T Parse(string)
para un tipo), consulte a continuación. Tenga en cuenta que solo utiliza la reflexión una vez (por tipo), en lugar de muchas veces. Esto debería superar el rendimiento de reflexión o bien típico de uso TypeConverter
:
using System;
using System.Reflection;
static class Program { // formatted for space
static void Main() {
// do this in a loop to see benefit...
int i = Test<int>.Parse("123");
float f = Test<float>.Parse("123.45");
}
}
static class Test<T> {
public static T Parse(string text) { return parse(text); }
static readonly Func<string, T> parse;
static Test() {
try {
MethodInfo method = typeof(T).GetMethod("Parse",
BindingFlags.Public | BindingFlags.Static,
null, new Type[] { typeof(string) }, null);
parse = (Func<string, T>) Delegate.CreateDelegate(
typeof(Func<string, T>), method);
} catch (Exception ex) {
string msg = ex.Message;
parse = delegate { throw new NotSupportedException(msg); };
}
}
}
serio? Almacenan punteros? Tenía la impresión de que los eventos lo hicieron, y que los delegados eran como un tipo de función fuertemente tipada. (Pero podría estar confundiendo las cosas allí.) – scraimer
scraimer: Los eventos usan delegados internamente. Además de eso, ofrecen una interfaz para un acceso más fácil. Debo aclarar esto. –
Sé todo sobre los indicadores de función, pero lo que me gustaría saber es cómo los implementa realmente el CLR y cómo puedo aprovechar el conocimiento sobre su implementación para utilizarlos de manera más eficiente en mi código – Lonzo