Компилятор C#
А кто говорил о переносимости??
Регулярные выражения обычно компилируются в исполняемую форму.
hardcase, чече?
hardcase, чече?
Изучай МСДН.
Конструктор Regex:
Среди возможных значений RegexOptions:
Compiled Specifies that the regular expression is compiled to an assembly. This yields faster execution but increases startup time.
Значит мало приложений делал на .NET. Такой код необходимо использовать не в прикладных приложениях, а в таких как обфускаторы, оптимизаторы, компиляторы. Да и к примеру, Platform Invoke из Native DLL, месторасположение которой неизвестно. Такое можно реализовать 100% managed только через System.Reflection.Emit или Microsoft.CSharp.
Как раньше писали на империалистическом Западе: "коммунисты успешно решают проблемы, которые сами себе создают".
Перечисленные тобой примеры - недостатки платформы .NET, успешно решённые микрочленами традиционным для них способом. Созданы тоже традиционным. Первое, что бросилось в глаза при чтении Троелсена - расположение сборок отдано на откуп системе. И кто дурак?
А... вот про них я забыл. Может потому, что особой нужды в их использовании не испытывал.
По поводу переносимости...
Ну что это за пугало такое??? Как будто в реальности обычного программиста хлебом не корми - дай написать переносимое между компиляторами (языками???) приложение (причем, чем больше языков используется, тем лучше :) ). К тому же в .NET с этим не фонтан - есть такая штука, как CTS - а ограничений там... (взять хотя-бы uint, несовместимый с VB). К тому же, давайте вспомним борландовскую VCL - вполне таки совместимая между компиляторами (Pascal/C++) библиотека.
Что касается переносимости между платформами - тут все намного веселее. Сказал майкрософт: "вот вам концепция для переносимого между платформами кода!" и все просветлели... только вот незадача-то - нужен еще отдельный Framework для каждой платформы. Тут майкрософт как всегда в своем стиле: под винду все есть, а с остальным - сами разбирайтесь. И слава богу, что хоть для Linux нашелся проект Mono. (Мне в этом смысле очень нравится подход Sun - там хоть JRE есть для всех платформ, более-менее востребованных. Хотя технологии уже 15 лет, всетаки срок.)
Ну вот пример: есть нестандартная железяка, подрубленная к USB или COM порту. Производитель впридачу дал dll, функции в которой хитро с оной работают. Нужно добавить поддержку этой железяки в свою прогу. Что делать? Правильно использовать эту dll с помощью P/Invoke. И... все, переносимость нервно курит в сторонке. (Может все это надуманно, но тем не менее вполне реальный случай).
...и еще много, много страшных слов. :) Ключевые слова здесь - прикладные приложения, ибо на просторах нашей Родины не очень много контор, которые занимаются обфускаторами, компиляторами и иже с ними. Посему, примерчики надо бы поближе к реальности приводить.
Ну это все оффтоп...
+1, no comments :)
ЗЫ: Чувствую таки опять все катится к религиозным войнам...
MSDN читаю регулярно, там негде не написано, что
"регулярные выражения обычно компилируются в исполняемую форму". (знать бы чет эт ещё за форма такая... :D )
Никому не кажется, что тема исчерпала себя? :rolleyes:
-Добавлено:
сорри, наверно это новое определение сборки..
И вообще если вспомнить историю создания языка C#, то здесь все просто - язык C# создавался для наиболее эффективного программирования под .Net и придумывать непонятно что тут не стоит.
Я вот в инете полазил и почитал тесты производительности...
Случаем на сайте ли Microsoft? Ссылки в студию, pls...
Компиляция в MSIL и управление со стороны .Net напротив призванно ускорить работу и без того жирного, зачастую перегруженного ненужной объектностью приложения. А .Net это как раз хороший выход из сложившейся ситуаци (благо подсмотрен он у JVM=) ).
Видишь ли какое дело... Размер приложения действительно намного меньше. Но ты забываешь, что managed код (кстати, managed как раз таки и переводится как "управляемый") требует среду выполнения, которая должна быть установлена целиком на машине. А это еще порядка 30 - 70 мегабайт (в случае .NET 3.0) против 2-5 мегабайт Native приложения (Я беру примерные размеры исполнимого файла более менее функционального приложения в Native исполнении. А если не пользоваться VCL, MFC и т.д. - то еще меньше. Некоторые пишут с использованием прямых вызовов WinAPI функций). Все бы ничего, если бы .NET поставлялся вместе с ОС (как в WinXP SP2 и выше). Но, к сожалению, у нас все еще преобладают Win2k и даже win98, поэтому дистр приложения автоматически увеличивается на размер .NET Framework. Моя мысль, я думаю, ясна. В случае с JVM - та же ситуация...
Что касается производительности - ну ни за что не поверю, что производительность managed приложений выше, чем native. Могу только сказать, что она может по крайней мере быть одинаковой. Здесь уже большу роль играет оптимизация кода компиляторами (native и JIT).
И вообще если вспомнить историю создания языка C#, то здесь все просто - язык C# создавался для наиболее эффективного программирования под .Net и придумывать непонятно что тут не стоит.
Все таки перечитай эту ветку обсуждения повнимательней...
Не знаю, у кого там "у вас". На западе разработчики прикладного софта под Windows в своём большинстве перешли на .NET (о чём свидетельствует растущая популярность данной плафтормы). А то что у нас, извиняюсь, "IT-темнота", так это не Microsoft или .NET виноваты, а сами отечественные программисты (некоторые до сих пор на Паскале сидят, а ещё некоторые - до сих пор про это книги выпускают).
Видишь ли какое дело... Размер приложения действительно намного меньше. Но ты забываешь, что managed код (кстати, managed как раз таки и переводится как "управляемый") требует среду выполнения, которая должна быть установлена целиком на машине. А это еще порядка 30 - 70 мегабайт (в случае .NET 3.0) против 2-5 мегабайт Native приложения (Я беру примерные размеры исполнимого файла более менее функционального приложения в Native исполнении
Лично мне не жалко 30 Мб за отличную среду выполнения, при том что на современных компах десятки и сотни гигабайт на HDD. Производительность?? На Intel Core Duo или AMD 64, да даже на P-IV HT потеря производительности в .NET-приложениях по сравнению с Native не заметна абсолютно. Так что это не аргумент. И главное в .NET - это кроссплатформенность, чего нет в Native (ну если есть желающие, которые могут без портирования кода C++ под Win32 перенести приложение с IBM PC на PocketPC - в студию пожалуйста).
А если сравнить с JRE? По производительности байт-кода, и по распространенности и доступности сред выполнения?
И еще - на десктопах, конечно, 30-70 метров это NULL, но для PocketPC - может быть, и не так уж мало. Или для них другие версии сред используются?
Ну про Java мы речь не ведём. Хотя конечно по переносимости J2ME конечно рвёт .NET, но он и не был расчитать на перенос приложений на микроконтроллеры.
Для семейства ОС Windows для мобильных устройств (Mobile, SmartPhone, CE) выпускается .NET Compact Framework, который конечно гораздо меньше 30 Мб весит.
Тогда сори за оффтоп, но все таки скажу:).
Хотя конечно по переносимости J2ME конечно рвёт .NET,
Про переносимость я согласен... Сравнивать их некорректно, учитывая возраст java и .net.Кто знает, сколько платформ будет у него лет через 7-8. Хотя, тут это может упереться в позицию мелкомягких.
Я как раз про производительность. Которая по твоим словам, на мощных машинах между .net и native (а значит, тем более, между .net и java) не заметно совершенно.
1. Это смотря какого типа/уровня приложение.
2. Ну Core Duo и AMD64 не везде стоят:).
2. Ну Core Duo и AMD64 не везде стоят:).
Я не говорю про то что дома стоит. А компьютеры в офисах среднего бизнеса (тем более крупного) - обычно мощные (если только во главе компании не стоит какой-нибудь старпер, который слыша слово IT перекрещивается).
1. Это смотря какого типа/уровня приложение.
Мощные приложения для работы с БД или Web выполняются на серверах, где вопрос производительности тривиален. Тем более работа с БД в .NET всё равно выполняется через механизмы OLE и ODBC, т.к. используются обёрнутые примитивы COM или WinAPI. При работе с MSSQL 2005 поддерживает CLR на уровне хранимых процедур.
Опять голословные утверждения? Да и к тому же зачем переходить на личности?
[quote=3A3-968M](некоторые до сих пор на Паскале сидят, а ещё некоторые - до сих пор про это книги выпускают).[/quote]
Представляешь, некоторые до сих пор среды разработки создают. Очень странно... :)
[quote=3A3-968M]компьютеры в офисах среднего бизнеса (тем более крупного) - обычно мощные (если только во главе компании не стоит какой-нибудь старпер, который слыша слово IT перекрещивается).[/quote]
Вообще-то сфера IT всегда была (и будет) сферой обслуживания (естественно я не говорю о софтверных компаниях), IT подразделения не приносит прибыли. Куда вложит деньги глава компании (гипотетический "старпер") - в развитие основного производства (закупка нового и улучшения старого оборудования, его расширение), где эти вложения принесут реальную прибыль или в новые компьютеры, сервера и новые версии ОС и программ? Думаю ответ очевиден - зачем что-то улучшать, когда и так все работает? И дело тут не в том, что наш "старпер" живет в 50х годах прошлого века, это просто здравый смысл. Деньги на апгрейд компьютерной техники обычно выделяются только в случае выхода последней из строя, либо для улучшения производительности уже существующего софта (например производственной БД), либо под внедрение какого-либо нового софта (ERP, MES и т.д.). Вот такие вот дела...
[quote=3A3-968M]Для семейства ОС Windows для мобильных устройств (Mobile, SmartPhone, CE) выпускается .NET Compact Framework, который конечно гораздо меньше 30 Мб весит.[/quote]
Очень интересно, почему весит меньше? Правильно, за счет урезанного функционала, который не поддерживается покетами. Я очень сомневаюсь, что нормальное WinForms приложение для PC можно без переделки запустить на WinCE. Соответственно какие могут быть разговоры о переносимости?
За примером далеко ходить не надо. Возьмем твой проект для разработчиков (весьма, кстати интересный) - можно его запустить на покете? ;)