Comments 15
Ох как красиво! Ну все, с выходных ищу время для «вкуривания» MONO.
Или все таки ждать C#4.0 — 5.0?
Или все таки ждать C#4.0 — 5.0?
+1
Если целевая платформа у вас .net, то имеет смысл использовать nemerle. А у моно сейчас есть проблемы, например, в сборке под windows nunit 2.4.8 падает с ошибками.
0
А в шарпе это DynamicExpression.ParseLambda() :)
+2
Что-то я не нашел такого. Это откуда? Какая версия C#? Какая сборка?
Или же это пока еще мечты? )
Или же это пока еще мечты? )
0
Это отсюда:
code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=csharpsamples&ReleaseId=8
LinqSamples\DynamicQuery
code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=csharpsamples&ReleaseId=8
LinqSamples\DynamicQuery
+2
привет javascript, flash и expression injection=)
+2
Присоединяюсь к вопросу — создается впечатление, будто бы eval в C# не такое уж и абсолютное зло.
Мне кажется, если безопасность/надежность какая-либо нужна, то лучше всё-таки хотя бы проконтролировать формальной грамматикой выражение перед eval-ом (тогда не надо писать полноценный «интерпретатор» выражения).
Мне кажется, если безопасность/надежность какая-либо нужна, то лучше всё-таки хотя бы проконтролировать формальной грамматикой выражение перед eval-ом (тогда не надо писать полноценный «интерпретатор» выражения).
0
Это точно, кроме того вы сами контролируете сборки, к которым имеет доступ этот опасный код, я еще до конца не разобрался, но думаю, что можно ограничить классы, к которым имеет доступ этот код, а если нельзя, то скорее всего в будущих версиях это ограничение появится.
0
ну это не интересно, так и на питоне нетрудно
>>> add5 = eval('lambda a: a+5')
>>> add5(2)
7
то же самое на руби, джаваскрипте, смолтолке,… (подставьте свой любимый язык).
Проблема такого подхода — мы завязаны на синтаксисе конкретного языка => не гибко
>>> add5 = eval('lambda a: a+5')
>>> add5(2)
7
то же самое на руби, джаваскрипте, смолтолке,… (подставьте свой любимый язык).
Проблема такого подхода — мы завязаны на синтаксисе конкретного языка => не гибко
+3
Спасибо за интересный способ, позволяет несколько по-новому взглянуть на наш инструментарий ) Однако классические алгоритмы и умение их применять никто не отменял ) Тем более, если своя реализация может обеспечить более гибкий механизм для контроля каждой стадии анализа / вычисления. К примеру, в собственном парсере-велосипеде можно рулить как выражением в целом, так и отдельными его частями (например, оптимизировать выражение за счет предвычисления констант). В общем, проблема выбора между своей собственной разработкой и использованием готовых решений как всегда актуальна.
0
Only those users with full accounts are able to leave comments. Log in, please.
Вычисление выражений на Nemerle и Mono.