Компиляция кода.NET или сложность?

Да, необходимо превратить массив байтов в шестнадцатеричный ряд.: -) Посмотрите на кодек Apache Commons , особенно класс Hex .

Ваша реализация верна. Нет «лучшего» способа сделать это (если есть такая вещь «лучше» в коде, что является другой проблемой..)

Незначительные исправления:

• < V расширяет Object > эквивалентно V , который является менее подробным
• Class эквивалентен Class , который является менее подробным
• Можно использовать аннотацию @ SuperverWarnings («unchecked») , чтобы сообщить компилятору, что приведение является безопасным

A1) JIT компилирует к коду собственного компьютера

A2). Вместо этого существует AppDomains. И они выполняются как часть CLR (т.е. как часть исполняемого процесса)

A3) Недостатки NGen от Джеффри Рихтера:

• файлы NGen 'd могут выйти из синхронизации. Когда CLR загружает файл NGen, он сравнивает количество характеристик о ранее скомпилированном коде и текущем выполнении окружающей среды. Если какая-либо из характеристик не совпадает, файл NGen не может быть используется, вместо этого используется обычный процесс компилятора JIT.

• Низкая производительность по времени загрузки (повторная настройка/привязка). Файлы сборки - это стандартные файлы Windows PE, каждый из которых содержит предпочтительный базовый адрес. Многие Windows разработчики знакомы с проблемами, касающимися базовых адресов и ребазинга. При компиляции кода JIT эти проблемы не вызывают опасений, поскольку во время выполнения вычисляются правильные ссылки на адреса памяти.

• Худшая производительность времени выполнения. При компиляции кода NGen не может сделать столько, сколько допущения относительно среды выполнения, как может компилятор JIT. Это вызывает NGen.exe для создания неполного кода. Например, NGen не оптимизирует использование определенные команды CPU; он добавляет косвенные значения для доступа к статическому полю, поскольку фактическое адрес статических полей неизвестен до времени выполнения. NGen вставляет код в класс вызовов конструкторы везде, потому что он не знает порядок, в котором будет выполняться код и если конструктор класса уже вызван.

IL - это JIT (JIT = Just In Time), скомпилированный в собственный машинный код при выполнении процесса.

Использование уровня виртуальной машины позволяет .NET вести себя в согласованном способе между платформами (например, int всегда 32 бит независимо от того, выполняется ли вы на 32-разрядной или 64-разрядной машине, это не так для C++).

JIT-компиляция позволяет оптимизаторам динамически подстраиваться под код по мере его выполнения (например, применять более агрессивные оптимизации к часто вызываемым битам кода или использовать аппаратные инструкции, доступные на конкретной машине, такой как SSE2), что невозможно сделать со статическим компилятором.

Вы можете получить его из MSDN, я просто посмотрел, что он там... см. снимок экрана ниже

1. C # компилируется в CIL (или IL), потому что он совместно использует платформу с остальными языками .NET (поэтому можно записать DLL на C # и использовать его в VB.NET или F # без проблем). Затем CLR компилирует код JIT в код собственного компьютера.

.NET также может выполняться на нескольких платформах (Mono на * NIX и OS X). Если бы C # скомпилировался в собственный код, это было бы не так просто.

2. Изолированная среда отсутствует.

3. В ответе # 1

A1) Таким образом, он не зависит от платформы (Windows, Linux, Mac), а также может использовать определенные оптимизации для вашего текущего оборудования. Когда он компилируется JIT, он превращается в машинный код.

A2) Вся структура (платформа .NET) представляет собой «песочницу», поэтому все вызовы, которые вы можете делать через свое приложение, будут проходить через изолированную программную среду .NET framework.

A3) Как и в ответе 1, он позволяет двоичному файлу .NET работать на разных платформах и на лету выполнять определенные оптимизации на клиентской машине.

Скомпилированный код .Net становится IL, который является промежуточным языком точно так же, как объектный код Javas. Да, можно сгенерировать собственный машинный код с помощью инструмента NGen . NGen связывает полученный образ в машинном коде с машиной, поэтому копирование двоичного файла ngen'd в другую систему не приведет к ожидаемым результатам. Компиляция в промежуточный код позволяет принимать решения во время выполнения, которые иначе (легко) не могут быть приняты с помощью языка со статической типизацией, такого как C ++, а также позволяет функционировать коду на различных аппаратных архитектурах, потому что затем код становится описательным в Смысл в том, что он также описывает намерение того, что должно произойти, с помощью битовой (например, 32- или 64-разрядной) диагностики, в отличие от машинно-зависимого кода, который работает только в 32-битных системах или 64-битных системах, но не в обоих одновременно.

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

Вы можете использовать NGEN для создания нативных версий ваших .NET сборок. Это означает, что JIT не должен делать это во время выполнения.

.NET сначала компилируется в IL, а затем в "родной", так как JIT был разработан для оптимизации кода IL для текущего процессора, на котором выполняется код.

.NET код компилируется на IL для совместимости. Так как вы можете создавать код, используя C#, VB.NET и т.д., то JIT нуждается в общем наборе инструкций (IL) для компиляции в родной код. Если бы JIT должен был знать языки, то JIT должен был бы обновляться при выпуске нового .NET-языка.

Я не уверен насчет вопроса с песочницей, лучше всего предположить, что .NET-приложение работает с 3 доменами приложений. Один домен содержит время выполнения .NET (mscorlib, system.dll и т.д.), другой домен содержит ваш .NET код, и я не могу вспомнить, для чего нужен другой домен. Посмотрите http://my.safaribooksonline.com/9780321584090