Dans les cadres .NET 2.0-3.5, LCG (AKA La classe DynamicMethod) était un moyen décent d'émettre des méthodes légères à l'exécution lorsqu'aucune structure de classe n'était nécessaire pour les supporter.
in .NET 4.0, les arbres d'expression prennent désormais des relevés et des blocs, et comme tels semblent fournir une fonctionnalité suffisante à la construction de toutes les fonctionnalités que vous pouvez exiger à partir d'une telle méthode et peuvent être construites de manière beaucoup plus facile et plus sûre que Émettre directement CIL OP-CODES. (Cette déclaration est supportée à partir de l'expérimentation d'aujourd'hui de convertir une partie de notre code LCG le plus complexe pour utiliser à la place du bâtiment et de la compilation des arbres d'expression.)
Voilà donc une raison pour laquelle on utiliserait LCG dans un nouveau code? Y a-t-il quelque chose qu'il peut faire cet expression arbres ne peut pas? Ou est-ce maintenant un morceau de fonctionnalité «mort»?
4 Réponses :
Eh bien, cette question est jolie ancienne maintenant, et j'attends un Oui, LCG est mort dans la plupart Cas. P> Nous utilisions un peu d'utilisation de LCG et il a maintenant été converti pour utiliser des arbres d'expression à la place. Ils sont beaucoup plus faciles à créer, le code est nettement plus facile de maintenir et de déboguer, et les messages d'erreur sont généralement plus informatifs que «l'opération pouvant déstabiliser le temps d'exécution» lorsque vous obtenez des choses en difficulté pendant le développement. P> Mais, peut-être plus important encore, les arbres d'expression sont composables d'une manière que la réflexion. Cela signifie que l'architecture des composants utilisés pour la génération de code d'exécution peut être plus modulaire et permettre même aux plugins d'étendre le cadre de génération de code. P> La seule chose que j'ai trouvée qui est supportée par la réflexion. Il est directement pris en charge dans les arbres d'expression, définit les champs tf obtenir code> pour compléter ... donc je vais y répondre moi-même. .Intimy code>. Ceci, cependant, peut être obtenu en utilisant une petite classe d'assistance et en l'appelant dans l'arborescence d'expression, par exemple celui que j'ai utilisé est ci-dessous: P> internal static class FieldHelper
{
public static TTarget AssignInitOnlyField<TTarget, TField>(
TTarget target, string fieldName, TField value)
{
var field = target.GetType().GetField(
fieldName,
BindingFlags.Instance|BindingFlags.Public|BindingFlags.NonPublic);
var boxed = (object)target; // required for value type support
field.SetValue(boxed, value);
return (TTarget)boxed;
}
}
La réponse est claire no. LCG est précisément utile car elle permet de compiler IL en runtime, ce qui en fait beaucoup plus performant. Si vous n'avez pas besoin du code bâti pour être rapide, vous n'en avez pas besoin. Donc, fondamentalement, les LCG ont toujours une niche.
Il n'ya pas de point dans la construction directement sans aucune étape intermédiaire. Mais il convient parfaitement à utiliser vos propres langages intermédiaires ciblant IL à la fin. Les arbres d'expression, etc., ne sont pas suffisants - ce n'est qu'une langue, alors que lors de la mise en œuvre de DSLS, vous auriez besoin de nombreuses sémantiques différentes.
Vous pouvez émettre un code facilement dangereux (avec beaucoup de LDFTNS et As-même), vous pouvez émettre des appels quotidiens (pas sûr si cela est possible avec des expressions), des appels non objectifs vers des méthodes virtuelles, vous pouvez construire efficacement des automates d'état de grandes étapes avec des étiquettes et sauts, etc. Les arbres d'expressions sont tellement limitatifs que je ne peux tout simplement pas comprendre comment peuvent-ils être comparés à un CIL cru.
Le LCG fait référence aux méthodes pouvant être collectées après leur démodage. LINQ Expressions utilise un EMIT LCG ou une réflexion normale ... de sorte que LCG n'est donc pas mort. Les expressions LINQ ne prennent également pas en charge tout comme les paramètres Réf, les méthodes d'instance, les propriétés, etc.
Les arbres d'expression sont certainement un moyen d'aller pour le plus grand nombre de code générés par le temps d'exécution. Cependant, vous devriez comprendre clairement qu'il est limité et ne vous fournit pas un accès à l'ensemble de la langue du msil. Ainsi, LGC et ILGenerator sont certainement de rester pour les tâches les plus exigeantes.