VK
блин, рослин хотя бы понять можно кусками где что как, а тут неоч
Size: a a a
2018 August 06
VK
2018 August 23
VK
G
Выглядит очень интересно.
AS
Спасибо за ссылку, с удовольствием гляну
S
//boyaaan
S
ndc норм, у них много интересного
2018 August 24
VK
VK
Прикольная штука, ее R провайдер использует
2018 August 31
NK
В чём причина существования CIL?
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
AK
ID:531693057
В чём причина существования CIL?
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
Пожалуй, это был самый уместный спам на моей памяти
NK
Пожалуй, это был самый уместный спам на моей памяти
😁
S
Пожалуй, это был самый уместный спам на моей памяти
+
S
я бы даже не кикал за такое
VK
Пожалуй, это был самый уместный спам на моей памяти
Я его банил уже
Dv
Я нерелевантное от этого чувака удаляю, а если норм — оставляю.
2018 September 06
RG
Вот таким кодом сгенерировал dll с статическим классом Example и методом CallMe, олнако при использовании готовой dll в проекте получаю странный FileNotFoundException
RG
Не понимаю сути. Может я что-то делаю не так?