Это, ошибка ExpressionTrees?
Я думаю причина того, почему текстовые файлы используются в разработке, то, что они универсальны против различных средств разработки. Можно посмотреть внутри или даже зафиксировать некоторые ошибки с помощью простого текстового редактора (Вы не можете сделать этого в двоичном файле, потому что Вы никогда не знаете, как любой фиксирует, уничтожил бы другие данные). Это не означает, однако, что текстовые файлы являются лучшими во всех тех целях.
, Конечно, Вы можете разность и объединять их. Но это не означает, что инструмент разности/слияния понимает отличную структуру данных, закодированных этим текстовым файлом. Можно сделать разность/слияние, но (особенно замеченный в XML-файлах) различный инструмент не покажет Вам различия правильно, то есть, это покажет Вам, где файлы отличаются и какие части данных, инструмент "думает", являются тем же. Но это не покажет Вам различия в структуре XML-файла - это будет просто соответствовать строкам, которые выглядят одинаково.
Невнимательный, используем ли мы двоичные файлы или текстовые файлы, всегда лучше, что инструменты разности/слияния заботятся о структуре данных, которую этот файл представляет, а не строки и символы. Для C++ или файлов Java, например, сообщают, что некоторый идентификатор изменил свое имя, сообщите, что некоторый раздел был окружен дополнительным, если () {}, но, с другой стороны, игнорируют изменения в символах EOL или отступах. Лучший подход состоял бы в том, что файл читается во внутренние структуры и вывел использующие определенные правила формата. Таким образом, различный луг будет сделан через внутренние структуры, и результат слияния будет сгенерирован от объединенной внутренней структуры.
3 ответа
This is clearly a bug, and it reproduces in today's build of C# 4.0. Thank you for bringing it to our attention. Odds are good that this issue will not make the bar for fixing before the final release; at this late stage we are taking only very high-priority fixes that we have confidence will not destabilize the release. What's more likely is that a fix will make it into a future service release; but of course, no promises.
Я не уверен, ошибка это или нет, но могу указать, в чем разница:
Эти два метода построены по-разному. Выражение, скомпилированное в converter1, имеет целевой метод типа DynamicMethod . Лямбда-метод, назначенный преобразователю 2, имеет целевой метод RuntimeMethodInfo .
Оба скомпилировали JIT, но с использованием другого механизма. Как я уже сказал, не могу сказать, почему они ведут себя по-разному, но это, вероятно, причина разницы.
Править Это то, во что он компилируется (код с использованием Reflector).
ParameterExpression CS$0$0000;
Func<float, uint> converter1 = Expression.Lambda<Func<float, uint>>(Expression.Convert(CS$0$0000 = Expression.Parameter(typeof(float), "x"), typeof(uint)), new ParameterExpression[] { CS$0$0000 }).Compile();
Func<float, uint> converter2 = delegate (float x) { return (uint) x; };
uint aa = converter1(float.MaxValue);
uint bb = converter2(float.MaxValue);
Это имеет некоторый смысл почему результат другой.
Я не вижу здесь проблемы. В идеальном случае вы должны получить ошибку компиляции в обеих ситуациях. Потому что в результате получается тихое переполнение. Например, следующее просто не будет компилироваться:
var test = (uint)(float.MaxValue);
Действительно ли имеет значение, что вы получаете разные значения, когда делаете что-то неправильно? Если вы измените свой код для использования проверенного преобразования (x => checked ((uint) x)), вы получите тот же результат в обоих сценариях - исключение времени выполнения.