Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Eltaron]

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Там инкрементальные улучшения. Основная масса библиотек неизменна со времен 2.0. 3.0 принес WCF, WPF и WWF, все в отдельных либах. 3.5 - LINQ, Linq2Sql, Linq2Xml, это всё тоже отдельные либы. 4.0 - дал Entity Framework, 4.5 - пространство System.Task для асинхронного выполнения. И то, и то - тоже отдельные либы. Плюс постоянно развивается язык, но там хранится обратная совместимость, и 2.0 проект собирается без проблем 4.5 компилятором.

Это так же можно сказать, что ты наращиваешь снежный ком, когда делаешь очередную новую либу для ZXDev. И что он тоже рухнет под собственной тяжестью.

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

Зачем тут unchecked, я не понял. Там действительно постоянные переполнения при работе с короткими числами, но для их обхода достаточно простого приведения типа.

const ushort A = 0x2312;
const ushort B = 0x2014;
ushort C = (ushort)(A + B);

А за первую строку нужно убивать. Отсутствие средств языка не повод плодить потенциальное Runtime exception.
Все разы, когда мне нужна была двоичная константа, я писал так и не парился:

const byte mask = 0x30; // 00110000

Можно ещё более безопасно

[Binary("00110000")]
const byte mask = 0x30;

Плюс написать тест, который будет парсить всю ассемблю, находить константы, помеченные атрибутом Binary, проверять, что двоичный вид совпадает с шестнадцатеричным числом, и валить билд, если не так. Это несложно, минут пять работы и лишняя доля секунды при сборке.