Компилятор C#
Но выходным кодом является MSIL и формат файла PE CLR. Никакой Native-код компилить этот компилятор не может. Вопрос эквивалентен такому: "Есть ли такой компилятор для языка Java чтоб приложения работали без JVM???"
Сам по себе язык не накладывает ограничение на компилятор и то, во что он компилится.
Что мешает компилить C# не в MSIL, а в двоичный код?
Конечным итогом все равно становится именно он,даже при стандартной схеме.
VS позволяет компилить в двоичный код, но он хранится вместе с MSIL.
Киньте ссылку на него и на инфу о нем.
Конечным итогом все равно становится именно он,даже при стандартной схеме.
VS позволяет компилить в двоичный код, но он хранится вместе с MSIL.
Мешает компилировать идеология дотНЕТа об управляемом коде - это раз.
Компилирование в машинный код может лишить возможности использовать "отражение" - это два.
C#2.0 содержит генерики - они компилируются в высокоуровневый генерик-код MSILа.
C#3.0 уж точно не получится компилировать сразу в машинный код. Оптимизация и выполнение сиквел-запросов (построение и интерпретация дерева лямбда-выражения запроса) - это уж совсем позднее связывание.
А свободный компилятор C# входит в состав любого фреймворка. Они доступны для скачивания на сайте Майкрософта (C#3.0 LINQ-компилятор тоже там есть).
Ну и бред! А зачем можно узнать? Тебе че не хватает языков которые компилируются в машинный код?
P.S. Зарегистрировался только для того, чтобы ответить на этот пост.
Языкам компилящимся в некоторый промежуточный код никогда не достичь производительности языков, компилящихся в машинный напрямую. Например, технология java сможет соперничать с++, не раньше, чем будет аппаратно реализована JRE в серийных процессорах. Я говорю про общую технологию. Конкретное приложение на яве, скажем, может работать быстрей чем аналогичное по функциональности на С++, но из-за лучшей архотектуры и / или реализации.
Ты хочешь сказать, что грамотно написанное приложение скомпилированное для конкретного процессора, будет работать медленнее чем код, скомпилированный для выполнения на любой машине? И код, скомпилированный при запуске программы и находящийся в памяти, будет работать медленнее чем код скомпилированный на месяц раньше?
Конечно, если вообще отказаться от ООП, то работать будет быстрее. Но разве это выход? :)
Почти все .NET приложения компилируются в MSIL. Производительность их нисколько от этого не страдает.
[QUOTE=Kanary]И код, скомпилированный при запуске программы и находящийся в памяти, будет работать медленнее чем код скомпилированный на месяц раньше?[/QUOTE]
Происходит двойная оптимизация кода: при транстировании в универсальный MSIL с языка выского уровня, и при транслирование MSIL кода в набор инструкций процессора, на коротом происходит выполнение приложения. Потому для разных процессоров машинный код будет отличаться, хотя я сомневаюсь, что это приведёт к заметному ускорению вычислений, исключением может быть 64-разрядная арифметика.
"Преждевременная оптимизация - корень всех бед в программировании". Компиляция в MSIL не есть оптимизация.
Конечно нет, где ты такое нашел в моем посте???:eek: Обратное утверждение верно.
И код, скомпилированный при запуске программы и находящийся в памяти, будет работать медленнее чем код скомпилированный на месяц раньше? )
Ты вообще о чем говоришь, сам понимаешь? Как влияет дата компиляции на работу кода? Или есть "магические дни", когда код компилится хуже?;)
Конечно, если вообще отказаться от ООП, то работать будет быстрее. Но разве это выход? :)
Я никогда не предлагад отказаться от ООП и вообще пропоганды не веду.
Я сравнивал производительность явы / шарпа с С++, и только.
Ты считаешь, что приложение написанное на С++, будет работать медленнее чем на C#?
Потому для разных процессоров машинный код будет отличаться, хотя я сомневаюсь, что это приведёт к заметному ускорению вычислений, исключением может быть 64-разрядная арифметика.
А мне кажется, приведет.
Да. Такое возможно.
Возможно, я это и оговорил. Потому что в некоторых библиотеках, например, явы (извиняюсь, что в теме про .NET говорю про яву, но мы обсуждаем достаточно абстрактные вопросы, а я ее знаю лучше чем шарп:)) есть функции, которых нет у С++ ( в распространенных либах). За счет этого возможен выигрыш. Я не говорю, что нельзя написать, как ты сказал, а что в общем это будет намного тормознее.
Ты вообще о чем говоришь, сам понимаешь? Как влияет дата компиляции на работу кода? Или есть "магические дни", когда код компилится хуже?;)
[QUOTE]
ЖЖЕШЬ!!! )))
ЖЖЕШЬ!!! )))
Извиняюсь, если кому слишком резко ответил, просто уж как-то пост тот ошарашил:)
Я писал не о "магических днях", как ты предположил (хотя идея прикольная :)), а о том, что С++ код компилируется в машинные команды сразу после написания кода (ну почти всегда), а С# код компилируется в машинные команды непосредственно перед выполнением и, что логично, компилируется именно для процессора на котором он будет выполняться. Иначе говоря, код, написанный на С#, будет работать не медленнее, чем код на С++.
Иначе - религиозной войны между программистами не избажать :-)
P.S. Компилится - это еще когда есть фреймы нужной версии;)
P.S. Компилится - это еще когда есть фреймы нужной версии;)
Для решения сей проблемы существует GAC = General Assemby Cache, который расположен в каталоге %SystemRoot%\assembly. Там содержатся часто используемые сборки.
Кроме того, крупное приложение проектируется так, чтобы оно компилировалось только при первом запуске, а мелкому без разницы.
Ты замечал, как VS2005 или C#Express тормозит при первом запуске после установки? Но после этого запуска она, как ни странно, больше не тормозит....
Просто я ей давно не пользовался, может и тормозит, поверю на слово.
Вообще, я не вдаюсь в тонкости проектирования приложений на .Net, т.к. его не слишком хорошо знаю, откровенно говоря.
NATIVE = TN1 + TN2 + ... + TNn
Где TNn - время выполнения одной инструкции.
Время выполнения MSIL инструкций равно
MSIL = TM1 + TM2 + ... TM3 + CLR + GC
Где TMn - время выполнения одной инструкции. CLR - суммарное среднее время на интерпретирование инструкции. GC - время на сборку мусора.
TM1 = TN1 + TN2 + ... TNn
Очевидно, что при если MSIL > NATIVE, то MSIL - NATIVE > 0:
TN1 + TN2 + CLR + GC -TN1 - TN2 = CLR + GC
Итого разница во времени при выполнении одинаковых задач - сумма времени работы GC (перемещение объектов) и суммарное время на интерпретирование MSIL инструкций в Native. А вот что касается использования памяти, то, безусловно .NET может иметь либо такую же оптимальность что и Native либо лучше. Что вобщем, тоже можно доказать.
Вот тут поподробнее. Я понимаю, что вручную писать нативную сборку мусора тяжело, но почему невозможно?
Элементарно. Это маркетинговая политика Microsoft. Если бы C# позволял создавать Native код, я предполагаю, что .NET загнулся бы :) Ну на самом деле - C# создан для программистов C/C++, чтобы привлечь их к использованию .NET. Была бы возможность писать Native программы, я уверен что все бы так и поступали (опять же из соображений производительности и отсутствии необходимости в установке Framework).
Кстати Оберон, насколько я знаю, использует автоматический сборщик мусора.
Кстати Оберон, насколько я знаю, использует автоматический сборщик мусора.
Ну и не только Oberon, ещё и LISP, Basic и др.. И сборку мусора для Native-приложений писать не сложно. Но в плане производительности она хоть и сравняется с .NET приложениями, но вряд ли опередит. Т.к. такие языки со сборкой мусора после компиляции хранят RTTI, и что хуже - runtime-библиотеки (отдельными файлами или скомпиленной вместе с приложением), в которых есть сборщик мусора.
Если бы C# позволял создавать Native код, я предполагаю, что .NET загнулся бы
Предположу, что подобные мысли появляются из-за плохого знания концепции .NET. C# не предназначен для компиллирования Native и никогда не будет этого делать. И дело не в маркетинге или в днях знойного солнцестояния. C# для .NET имеет такое же значение, что язык Java для J2ME/SE/EE. Почему же вы не задаёте вопрос "а почему ЖАВА не компилит Native-код"?? Потому что это просто смешной вопрос. Вот так же смешно и звучит вопрос про C# и Native. Если вам нужен Native, берите MFC и C++ и вперёд. Нужен Native и возможности .NET, берите MC++ и вперёд. Только тогда забудьте о КРОССПЛАТФОРМЕННОСТИ.
Предположение неверно. Да и причем здесь, собственно, концепция .NET?
C# - вполне самодостаточный язык, и сделать компилятор в Native - вполне посильная задача. Другой вопрос, что компилятор для C#
А думаешь, таких вопросов не задавали в свое время?
C# создан для .NET. И философия .NET никак не приветствует Native-код в managed приложение. А концепция .NET состоит в том, что есть .NET Framework, есть CLR, есть C# (VB.NET или RubyCLR) который компилит MSIL код. И место для Native во всей этой концепции отведено мизерное количество - PInvoke да RCW. И суть .NET - создание кроссплатформенных (и аппаратно-независимых) приложений. Попробуй-ка код на C++ под IBM PC пихнуть на PocketPC??
C# - вполне самодостаточный язык, и сделать компилятор в Native - вполне посильная задача. Другой вопрос, что компилятор для C#
Ну да, а всякие using System.Collections ты на что заменять будешь???
А думаешь, таких вопросов не задавали в свое время?
Задавали. И тех кто их задавал отправляли читать концепцию платформы Java. И это вопрос сам собой исчезал.
Повторю еще раз: причем здесь концепция .NET??? Разговор про сам язык.
Компилит код в MSIL не C# (VB.NET или RubyCLR), а соответствующий компилятор (csc.exe, vbc.exe и иже с ними), язык здесь не причем.
В чем проблема? Есть компилятор языка C++, который компилит код в набор команд PocketPC (и он уже реально есть, поскольку не думаю, что ОС для PocketPC написана на asm). .NET пришел намного позднее.
C++:
Между прочим - это стандарт C++ 99 года - .NET еще только придумывали.
using указывает на подключение пространства имен (по сути библиотеки). System.Collections - часть .NET Framework, и опять же никто не мешает создать такую же библиотеку, только в Native исполнении. Вопрос в том, кто этим будет заниматься?
Опять же за счет использования библиотек .NET Framework :)
RTTI - не проблема, опять же в Delphi тоже довольно мощный RTTI, как впрочем и в C++. Насчет генериков - я думаю ни для кого не секрет, что это пришло из шаблонов C++ (STL - яркий пример), а идея шаблонов по моему появилась еще где-то в 70х. Добавить поддержку "чисто .NET фичи" метаданных в сборках (те же атрибуты) - думаю тоже не проблема.
Вот Reflection - согласен, это чисто фича .NET, именно касаемо динамического генерирования инструкций (только не машинных, а IL).
А если разговор про сам язык то юзай C++ и радуся жизни, в спецификациях этих языком по моему отличй почти нет.
Компилит код в MSIL не C# (VB.NET или RubyCLR), а соответствующий компилятор (csc.exe, vbc.exe и иже с ними), язык здесь не причем.
C# - часть концепции .NET. Хм...интересно, путь проект на C# ссылается на Managed сборку, каким образом этот проект скомпилиться в Native????? Ну может Unmanaged Metadata API спасёт, только вот по производительности такое приложение просто с места не сдвинется. А как такой код работать будет:
Assembly.ReflectionOnlyLoad("Hello.dll");
как он из Native приложения метаданные возьмёт? Да и в случае Native довольно удручающе смотряться такие вещи как MethodBody, internalcall, cil managed, runtime managed и т.д..
using namespace std; // Ничего не напоминает?
Я не о языковой конструкции, а о наборе Managed классов которые там содержаться.
Между прочим - это стандарт C++ 99 года - .NET еще только придумывали.
using указывает на подключение пространства имен (по сути библиотеки). System.Collections - часть .NET Framework, и опять же никто не мешает создать такую же библиотеку, только в Native исполнении. Вопрос в том, кто этим будет заниматься?
Да уж действительно кто мешает??? Что-то Native компилятора для Java да и так что-бы он работал со всеми классами их JDK до сих пор нет. Это как в случае с анекдотом "почему Джо не уловим - да потому что нах..р ни кому не нужен". Так и эта ситуация с C# и Native - потому что это не нужно. Нужен Native и .NET - пожалуйста MC++.
Уважаемый, для начала Вы бы проследили ход дискуссии данного топика, прежде чем писать, ИМХО, откровенно бессмысленные посты. Я пользуюсь C# и .NET и радуюсь жизни. Автором был задан конкретный вопрос о возможности использования C# для создания Native приложений. Я пытаюсь доказать, что сам язык вполне пригоден для этого.
Теперь по теме... :)
Опять 25.. Ну где об этом сказано в спецификации языка?
Я в предыдущем посте об этом говорил: никто не мешает создать Native сборку с метаданными, с помощью соответствующих инструментов (компиляторов, компоновщиков), которые необходимо разработать. Это я к тому, чтобы не было вопросов "Как ты создашь Native сборку с помощью инструментов .NET?" :)
Этих понятий в спецификации C# нет.
А а в чем проблема создания такого же набора Unmanaged классов? Или тот же класс Console принципиально не реализуем? :) Только не надо меня опять тыкать в Reflection и Emit. Я согласился с тем, что это особенность CLR, и для Native не подойдет. Хотя частично Reflection реализуемо (информация о типе).
ВО-О-ОТ! О чем и речь-то. Хотя, судя по автору топика, "Джо неуловим" совсем по другой причине ;)
Этих понятий в спецификации C# нет.
В спецификации нет, но на C# пишуться .NET приложения и тогда нужно обеспечивать переносимость кода C# под .NET на код под Native. Тогда жду следующего кода в Native реализации:
[/SIZE][FONT=Courier New][SIZE=2][COLOR=#0000ff]if[/COLOR][/SIZE][SIZE=2] (mainMethod.GetMethodImplementationFlags() & [/SIZE][SIZE=2][COLOR=#008080]MethodImplAttributes[/COLOR][/SIZE][SIZE=2].IL & [/SIZE][SIZE=2][COLOR=#008080]MethodImplAttributes[/COLOR][/SIZE][/FONT][SIZE=2][FONT=Courier New].Managed)[/FONT]
[FONT=Courier New]{[/FONT]
[/SIZE][SIZE=2][COLOR=#008000][FONT=Courier New]//ToString is an MSIL managed method[/FONT]
[/COLOR][/SIZE][SIZE=2][/SIZE][FONT=Courier New][SIZE=2][COLOR=#008080] MethodBody[/COLOR][/SIZE][/FONT][SIZE=2][FONT=Courier New] mbody = mb.GetMethodBody();[/FONT]
[/SIZE][FONT=Courier New][SIZE=2][COLOR=#0000ff] byte[/COLOR][/SIZE][/FONT][SIZE=2][FONT=Courier New][] msil = mbody.GetILAsByteArray();[/FONT]
[/SIZE][FONT=Courier New][SIZE=2][COLOR=#0000ff] foreach[/COLOR][/SIZE][SIZE=2] ([/SIZE][SIZE=2][COLOR=#0000ff]byte[/COLOR][/SIZE][SIZE=2] b [/SIZE][SIZE=2][COLOR=#0000ff]in[/COLOR][/SIZE][/FONT][SIZE=2][FONT=Courier New] msil)[/FONT]
[FONT=Courier New] {[/FONT]
[/SIZE][SIZE=2][COLOR=#008000][FONT=Courier New] //Works directly with MSIL code[/FONT]
[/COLOR][/SIZE][SIZE=2][FONT=Courier New] }[/FONT]
[FONT=Courier New]}[/FONT]
[/SIZE]
Обратим внимание на ту строчку кода, где получаю MSIL-код. И где в случае с Native я его возьму?????????
И вы предлагаете содержать метаданные в исполняемом файле, так тогда какой толк от Native если он тоже использует метаданные????????
Это опять-таки конкретная реализация. Ничего не мешает её запретить в Native-компиляторе/библиотеках. И вообще, не уверен, что прямой доступ к коду - пример правильного программирования.
Принципиально создать компилятор с языка C# в родной код можно, только никто им заниматься не будет.
Принципиально создать компилятор с языка C# в родной код можно, только никто им заниматься не будет.
Я могу ещё с десяток примеров кода накидать, которые придётся запрещать в Native реализации, и тогда о переносимости программ на C# между компиляторами можно будет забыть. А прямой доступ коду - это абсолютно нормально, особенно когда требуется динамически генерировать код (System.CodeDom или System.Reflection.Emit), и иногда без этого приложения не построишь.
Ну говорилось же, что нельзя. Я с этим согласился :)
Еще добавлю, что с ходу даже не могу предположить, где именно понадобится такой код в реальных приложениях?
В общем выводы сделаны, засим предлагаю закончить дискуссию :)
ЗЫ: Автор топика, надеюсь, удовлетворен ответом? :)