Является ли глубокое знание ИЛ важным для разработки .net

Когда я делал в основном С++, мне было очень важно знать сборку и написали какой-то не-пробный код asm, чтобы я мог действительно понять, что происходит. Я теперь делаю в основном .net, и хотя у меня есть некоторое понимание ИЛ, я отнюдь не профессионал.

Является ли ИЛ навыком, который должен иметь знание или будет изучать IL более подробно, чтобы сообщить, как я использую и пишу код .net?

Ответ 1

Обучение IL полностью похоже на сборку обучения во многих отношениях.

Понимание IL может помочь вам понять, что происходит, когда вы на самом деле компилируете свой код .NET. Это может быть очень полезно, особенно если вы столкнулись с критическими ситуациями с критическими характеристиками производительности (где вы нашли настоящую проблему и вам нужно ее оптимизировать).

Однако для большинства "повседневных" задач программирования я не думаю, что действительно нужно понимать ИЛ, так же как большинство программистов на C++ действительно не знают, как писать сборку.

Если сказать, что если вы понимаете ассемблерный код на фоне С++, получение общей идеи IL будет очень-очень простым...

Ответ 2

Если вы просто пытаетесь написать приложение .NET, вам не нужны какие-либо знания IL-кода. Большинство разработчиков .NET не знают, как писать в IL-код.

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

Ответ 3

Помимо очевидной (реализации виртуальной машины), некоторые типы задач требовали довольно полного понимания ИЛ.

  • Написание динамического кода. Это было довольно хорошо заменено API System.Linq.Expressions, особенно учитывая его возможности в .NET 4.
  • Написание компилятора для нового языка для таргетинга на CLI. Проекты, такие как Common Compiler Infrastructure, направлены на уменьшение количества реальных CIL-компиляторов, которые должны писать записи компилятора.

Один из самых интересных аспектов для меня лично - это изучение влияния языка IL на компилятор "точно в срок". Одним из примечательных примеров, сравнивающих JVM и CLI, является то, что CLI имеет представление о не виртуальных методах и прямой отправке, что позволяет эффективно использовать вызовы, которые могут быть выбраны не оптимизирующим (базовым) компилятором. Этот анализ более дорогой в JVM, поэтому базовый компилятор не может оптимизировать столько случаев.

В ответ на исходный вопрос:

В целом разработчикам .NET не нужно беспокоиться об обучении CIL. Если ваша работа связана с методами времени исполнения/динамической генерации, вы должны оценить способность API выражений удовлетворять ваши потребности, потому что они чрезвычайно удобны для использования/поддерживаются. Я провел несколько недель, выпустив CIL с ILGenerator. Мне потребовалось одно сидение, чтобы преобразовать в Expressions, сохранив более ста строк кода и исправляя старые ошибки, которые я просто не понял.

Подробное знание CIL очень важно для тех, кто внедряет виртуальную машину CLI или пишет компиляторы (AOT или JIT). Я нахожу это интересным и полезным, но в рамках "важных вещей, которые нужно знать, чтобы быть продуктивным разработчиком", он просто не так высок.

Ответ 4

В платформе .NET есть только одно место, где вам нужно знать IL, классы в пространстве имен System.Reflection.Emit. Он позволяет генерировать код "на лету", который может быть полезен в отдельных случаях.

Лучший способ получить доступ к IL - через инструмент Ildasm.exe, Reflector тоже может работать. Очень удобный способ запустить его - это добавить его в меню "Инструменты". Инструменты + Внешние инструменты, Добавить.

  • Заголовок = Ildasm
  • Command = c:\Program Files\Microsoft SDK\Windows\v6.0A\Bin\ildasm.exe
  • Аргументы = $(TargetPath)
  • Начальный каталог = $(TargetDir)

Теперь вы можете написать некоторый управляемый код, скомпилировать и быстро взглянуть на генерировать IL. Вы найдете это довольно легко, если раньше вы подвергались машинным кодам. Просто имейте в виду, что IL нетипизирован, тот же код операции используется для любого типа значения.

Следующий шаг - взглянуть на то, как IL переводится в машинный код. Начните отладку, щелкните правой кнопкой мыши код и выберите "Перейти к разборке". Помните, что вы не будете смотреть на настоящий машинный код, если не запустите сборку Release и не включите оптимизацию JIT. Tools + Options, Debugging, untick "Подавлять оптимизацию JIT при загрузке модуля".

Ответ 5

Зависит. Знание IL, вероятно, поможет вам понять, в чем состоит ваш код. Если у вас есть хорошие знания, если IL, вы даже можете создавать новые компоненты во время выполнения (если вам нужно). Это важно? Наверное, нет.

Ответ 6

Знание сборки было очень хорошо для C/С++ в Visual Studio. Вы всегда можете пойти на разборку, чтобы посмотреть, что происходит.

Если вы попробуете то же самое в С#, то есть "Перейдите к разборке", вы по-прежнему переходите к собственному коду, а не к IL. В этом смысле IL не так полезен, как реальная сборка.

Но ИЛ хорош для просмотра внутри сборок, что у вас тоже нет исходного кода. (Но вы можете использовать reflector для этого)

Ответ 7

Нет, как сказал большинство. Кроме того, чтобы добавить к их комментариям, посмотрите, почему вы используете C/С++ и почему вы используете .NET и его языки (liek С#):

C/С++ был сделан для того, чтобы дать вам власть над компьютером красивым абстрактным способом. Он преобразуется ALMOST непосредственно на язык ассемблера и дает вам большую силу для хорошего (и злого). Такие вещи, как указатели, поощряются, и нет сбора мусора. Следовательно, вы должны знать, что делает код языка ассемблера из-за того, что вы можете сделать.


Языки .NET были сделаны, чтобы быстро создавать отличные приложения и ограничивать ущерб, который вы можете сделать для этих приложений. Это препятствует вам использовать реальную власть над процессором (например, указатели обескуражены, и вам больше не нужно беспокоиться о сборке мусора). В принципе, ущерб, который вы можете сделать, ограничен приложением; и мало что связано с процессором (если вы не ошибаетесь с небезопасным кодом, который используется только в редких случаях [по моему опыту]). Кроме того,.NET-код преобразуется в IL, тогда IL преобразуется в сборку и так далее... вы все равно не имеете прямого отношения к ассемблеру.


Они сказали, что хорошо знать ИЛ для начальных знаний и могут немного помочь вам. Но зная, что это не поможет вам создать отличное приложение, которое является точкой для языков .NET, для большинства разработчиков, не работающих в Microsoft.