>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
При должном опыте — не сложнее, чем NAnt; конфиги и принцип в чем-то совпадают.
Кроме того, он используется как «режущая поверхность» у «комбайна» под названием Team Build из MS Team Foundation System.
В качестве домашнего средства я остановился на NАnt + CC.NET.
>> Но «выгоднее с точки зрения бизнеса разработчика» != «выгоднее для конечного пользователя», согласитесь?
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
>>Не вижу никакого смысла искать пруфлинк насчет того, что DirectX
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
Для MS SQL, например, это не так. Его оптимизатор позволяет сохранять планы даже для динамического SQL. План, грубо говоря — это распарсенное до атомарных операций выражение SQL, готовое к выполнению. После первого парсинга план помещается в кэш, после чего для его использования не нужно нагружать парсер, достаточно просто взять из кеша нужный запрос и подставить параметры.
Понятно, что параметризовать именем таблицы нельзя, зато можно держать планы для всех таблиц в БД (их редко бывает больше сотни-другой) для среднего проекта.
С другой стороны, наличие динамического sql, как правило, говорит о том, что что-то не так в датском королевстве вы используете БД не по назначению, заставляя ее выполнять задачи сервера приложений.
Не подводит: Microsoft.Office.Interop.Word.dll — это CCW (COM Callable Wrapper), автоматический сгенеренный тулзой TlbImp из состава Microsoft Windows SDK for .net. Все, что он делает — пробрасывает вызовы/объекты в COM-компоненты и худо-бедно рулит памятью (худо-бедно — потому что завязан на финализацию, и часто держит ссылки на COM-объекты дольше чем надо; часто — почти всегда:)
Автору — для создания путей лучше не использовать операции над строками, а использовать Path.Combine()
>> Вы используете ТЗ (велосипед), я использую SRS (машину)
Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения. Давайте назовем его «самокат»
Собстно, такой код, который вы привели, наглядно демонструирует, что при использовании исключений «мухи отдельно, коттлеты отдельно» — т.е. рабочий код чист и не загрязнен операциями зачистки/восстановления состояния после ошибок
Я бы не стал говорить про недостаток :) Иногда это превращается в достоинство — всегда известны тайминги операций (драйверы, low-level, nuclear facilities :)
Самая большая проблема исключений в том, что их генерация влечет за собой накладные расходы и операции, которые сами по себе могут быть источником проблем и исключений.
Простейший пример — нехватка памяти. Нужно выбросить exception, но не факт, что хватит памяти сконструировать сам экземпляр исключения. В управляемой среде (виртуальная машина java, интерпретатор php, или рантайм) сама среда берет на себя заботу об этом. В с++/MFC, например, чтобы памяти хватило, экземпляр исключения о нехватке памяти (и только такого) конструируется заранее, и затем везде выбрасывается один и тот же (вернее, указатель на один и тот же — чтобы исключить потенциально опасную операцию копирования объектов с контекста на контекст).
Насчет обертки — вы абсолютно правы, стоит делать как удобнее. Я только писал, что внутри DirectX продолжает оставаться COM-like, и не использует исключения — по указанным выше причинам.
Нет, я не про индусов :) я, в основном, про русских разработчиков в Той команде :)
Я бы использовал коды возврата в том случае, если это составляет логику работы программы. Ну и использовал бы их не в raw-формате, а как enum или его самописные аналоги (в Java)
P.S. Извините за медлительность, какой-то анонимус отметился в карму — видимо, не понравилось, что я слишком аргументированно спорил; и теперь ни писать в блог, ни комментить нормально не могу :( что с этим делать (плюсовать не надо, если вдруг, только ответьте)?
Вот так проявляется уникальная черта программистов — из неверных посылок делается верный вывод :)
Про выброс исключений и очистку ресурсов вы все правильно сказали, хотя посылка про неизвестность, критическая ошибка или нет, мне непонятна — про метод всегда известно, способен ли он сделать recover возникшей ошибки, или нет.
Собственно, сама возможность фильтровать по типу исключения внутри блока catch(SomeType ex) сделана для того, чтобы наглядно разделять recoverable и non-recoverable (извините за английский, он в данном случае выразительнее)
Таки позволю себе несогласиться :) Я застал то время, когда мы писали COM-объекты на Си. Так вот, как вы могли понять, не было исключений, и поэтому любой метод возвращал HRESULT, который должен был быть проверен (примерно так):
Ну и если вы посмотрите на исходники той же Windows (например, в Direct X, чтобы далеко не ходить), вы увидите, что они сами тоже не очень жалуют эксепшены, и в настоящее время продолжают писать в Cи/COM стиле. Так что рано еще хоронить коды возврата :)
>> Почему бы не скомпилировать ее разработчику?
Читайте выше про оптимизацию
>> Кроме того, подозреваю, что в то время как обычный exe файл не загружается целиком в память, а просто ммапится на область памяти, в схеме с JIT эта возможность теряется.
Эта возможность позволяла вам стартануть приложение сразу, а не ждать его загрузки; однако, в системе с размером страницы в 4кб (win32) и производительностью диска в несколько МБ (старые винты 3-5 летней давности) это перестало давать преимущество. Можете на нем не фиксироваться. Тем не менее, она не теряется — jitter работает этапами и компилирует только «горячий» код, тот, который нужен.
>> я плохо представляю компилятор, который обрабатывает код со скоростью несколько десятков мегабайт в секунду (500 Кб/ 0.01 сек = 50 Мб./сек.), и еще как-то при этом оптимизирует его
Простота абстрактной машины CLR позволяет иметь скорость достаточно оптимизированной компиляции под x86 в 10-20 МБ/с (это подтвержденные цифры библиотеки libjit, родная от МС выдает и больше). 500 кб / 10 МБ/сек = 0,05 сек. Достаточно быстро, не находите?
>> байт-код и JIT — направлены не на благо пользователя, а на возможность нераскрываения исходников разработчиками.
Здесь я вас расстрою. Байткод java и IL с легкостью превращается во вполне читаемые исходники. Так что программы в байт-коде гораздо легче реверсить, чем либы нативного с++. Вы проиграли :)
>> думаю МС просто лениво было бы
Это отличный аргумент в споре, продолжайте в том же духе :)
-+-
Вообще мы начали разговор про размер фреймворка, так что давайте завязывать спорить про производительность. В сети полно данных про сравнение компиляторов и программ — не абстрактных циклов и функций, а вполне законченных решений.
Мое мнение — на вкус и цвет фломастеры разные. Вы хотите иметь все и сразу. В жизни все доступно только через компромиссы.
P.S. Ваши посты одинаково читаются как сверху вниз, так и наоборот. Это говорит о том, что вы пишете, не думая, что вы писали раньше. Не вижу смысла спорить далее.
Кроме того, он используется как «режущая поверхность» у «комбайна» под названием Team Build из MS Team Foundation System.
В качестве домашнего средства я остановился на NАnt + CC.NET.
Еще можно добавить (из более-менее известных):
— Apache Maven (Тынц)
— Boost Jam Tool (Тынц)
Из «диковинок»:
— Bake (Make для Boo) (Ты-тынц)
Это далеко не полный список
Не соглашусь. весь сервис build/deploy/update гораздо проще вести в .net. Т.е. конечному пользователю гораздо проще и быстрее получить обновление, потому что я (грубо) это обновление быстрее выпущу.
>> Принцип RAD проталкивают уже не первый год, когда-то на роль среды для RAD MS пропихивала Visual Basic
Вы путаете RAD и .net. Родоначальник RAD — это Delphi, там .net и не «пахло». Microsoft пропихивала VB в основном по той причине, что он тесно связан с COM, который интегрирован в Windows.
>>Я бы предпочел пользоваться компактными, не требующими инсталляции, быстрыми программами с удобным интерфейсом (и с нативными контролами), а предстоит (похоже) пользоваться тем что получится
Именно это и несет с собой .net — компактные, удобные, быстрые, не требующие инсталляции программы. Беда не в платформе, а в быдлокодерах.
>> (и с нативными контролами)
В .net под windows нативные контролы (не все, правда), если что. Чуть раньше вы сказали, что вам, как пользователю, глубоко фиолетово, что там внутри. Вот. Я думаю, что глубоко фиолетово, нативные они или нет.
>> И почему компилятор выдает байт-код а не номальный машинный код? Что за фигня?
Читайте выше: он внутри, и вам на него чихать. Он вам его по почте шлет и спамит, что ли? =) В .net перед выполнением сборка компилируется в машинный код (причем оптимизируясь с учетом архитектуры вашего конкретного процессора, а не абстрактного x86, который внутри уже давно RISC over CISC). Эта компиляция занимает характерное время в 0.01 — 0.1 секунду для всего приложения целиком — это быстрее, чем дабл-кликнуть по иконке. Для наиболее частых запускаемых приложений специальный сервис windows хранит уже откомпилированные в машинный код сборки — так что даже на это время не тратится.
>> И нужны ли вещи вроде RTTI, или Reflection в не-отладочном режиме?
Поверьте, нужны. Часто их используют не только для интроспекции кода.
>>а вот если у вас кривой интерфейс, или программа тормозит — вот от этого уже холодно.
Немного про себя. У меня средний ноутбук, я разрабатываю на нем в .net (и в линуксе под mono тоже), приложения не тормозят. Что я делаю не так? :)
Вернее сказать так — у меня много приложений, которые не тормозят, несмотря на то, что написаны с использованием .net fw. Так что это не к технологии придирки, а кривым рукам программистов.
предоставляет доступ к видеокарте. Не верите — не надо.
Речь шла (цитирую вас) «DirectX — нужен для прямого доступа к оборудованию, без него никак». Так вот, прямой доступ к оборудованию предоставляют абстракции HAL и драйвера. Сам DirectX — наоборот — изолирует вас от оборудования: для вас есть абстрактная графическая машина, и вы ею управляете. Все. Прямой доступ закончился со времен DirectX 5 (Когда он был еще DirectDraw).
>> или требует 30 мегабайтный инсталлятор
Вы внимательнее почитайте. Этот инсталлятор — для фреймворка, а не для программы. Будучи поставлен единожды, остальные программы (в инсталляторе) имеют характерный размер в 100 — 500 кб. С возможностями, сравнимыми с MS Office. Речь об этом и о том как упростить и уменьшить далее сам инсталлятор фреймворка.
>> MSVCRT — входит в винду начиная с 98
Вы забыли указать версию библиотеки. В винде она обычно 7.1 (Win XP SP). Для более новых программ (VS2005) нужно тащить эту библиотеку вместе с программой — к каждой программе. Немного, но неприятно.
>> По поводу производительности Java/.NET… []… или не хочет использовать нативные контролы…
Простите, не вижу связи между нативными контролами и производительностью. Вы про Java? Так она не использует нативные контролы, потому что работает на разных платформах без перекомпиляции. На разных платформах — разные нативные контролы, всех не отследишь. Поэтому используются свои, из JRE.
>> требует 30 мегабайтный инсталлятор…
Аналогично, отношения к производительности не имеет. Просто секрет в том, что в винду (XP, например) встроен рантаймы для c++ и mfc, а для .net — нет. Он появился позже. В следующих версиях винды — тоже будет встроен, так что ничего тащить не надо будет.
— Вывод мой, в общем-то прост. Вы чересчур импульсивно высказываете свое мнение, которое, к сожалению, опирается на факты, которые либо устарели, либо являются не фактами, а домыслами. Все попытки вам на это указать ни к чему не приводят. По поводу DirectX — вы неправы. По поводу MFC — уже сдались и признали неправоту.
Факт: в .net/java гораздо проще не допускать ошибки, а если случились — искать и отлавливать их. Гораздо проще, чем в с++. Я с ужасом вспоминаю многочасовые сессии в отладчике.
Реальность такова, что программирование — это не поиск дао и не процесс ради процесса — это удовлетворение нужд бизнеса прежде всего. И с точки зрения бизнеса технология, позволяющая упростить и ускорить разработку банально выигрывает. По простым показателям выгоды и окупаемости.
Я ясно выражаюсь? И есть ли смысл продолжать диалог?
>> Уверен, что TC не зависит от «Qt, GTK, DirectX, виртуальная машина Java с базовыми библиотеками, .NET framework, Adobe Flash и множество множество других».
Пруфлинк или вы — не разбираетесь
MFC/MSVCRT — входят в Windows с незапамятных времен, и не содержат пакостей вроде JIT или байт-кода (хотя и великоваты), так что не надо их трогать.
Пруфлинк или вы — не разбираетесь
DirectX — нужен для прямого доступа к оборудованию, без него никак
Пруфлинк или вы — не разбираетесь
… далее вы поняли, куда грести.
Вы тролль-популист?
К каждому вашему замечанию выше хочется заметить следующее — «пруфлинк или вы фейл»
Понятно, что параметризовать именем таблицы нельзя, зато можно держать планы для всех таблиц в БД (их редко бывает больше сотни-другой) для среднего проекта.
С другой стороны, наличие динамического sql, как правило, говорит о том, что
что-то не так в датском королевствевы используете БД не по назначению, заставляя ее выполнять задачи сервера приложений.Автору — для создания путей лучше не использовать операции над строками, а использовать Path.Combine()
Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения.
Давайте назовем его «самокат»Статья полезная, спасибо.
Самая большая проблема исключений в том, что их генерация влечет за собой накладные расходы и операции, которые сами по себе могут быть источником проблем и исключений.
Простейший пример — нехватка памяти. Нужно выбросить exception, но не факт, что хватит памяти сконструировать сам экземпляр исключения. В управляемой среде (виртуальная машина java, интерпретатор php, или рантайм) сама среда берет на себя заботу об этом. В с++/MFC, например, чтобы памяти хватило, экземпляр исключения о нехватке памяти (и только такого) конструируется заранее, и затем везде выбрасывается один и тот же (вернее, указатель на один и тот же — чтобы исключить потенциально опасную операцию копирования объектов с контекста на контекст).
Насчет обертки — вы абсолютно правы, стоит делать как удобнее. Я только писал, что внутри DirectX продолжает оставаться COM-like, и не использует исключения — по указанным выше причинам.
Я бы использовал коды возврата в том случае, если это составляет логику работы программы. Ну и использовал бы их не в raw-формате, а как enum или его самописные аналоги (в Java)
P.S. Извините за медлительность, какой-то анонимус отметился в карму — видимо, не понравилось, что я слишком аргументированно спорил; и теперь ни писать в блог, ни комментить нормально не могу :( что с этим делать (плюсовать не надо, если вдруг, только ответьте)?
Про выброс исключений и очистку ресурсов вы все правильно сказали, хотя посылка про неизвестность, критическая ошибка или нет, мне непонятна — про метод всегда известно, способен ли он сделать recover возникшей ошибки, или нет.
Собственно, сама возможность фильтровать по типу исключения внутри блока catch(SomeType ex) сделана для того, чтобы наглядно разделять recoverable и non-recoverable (извините за английский, он в данном случае выразительнее)
Таки позволю себе несогласиться :) Я застал то время, когда мы писали COM-объекты на Си. Так вот, как вы могли понять, не было исключений, и поэтому любой метод возвращал HRESULT, который должен был быть проверен (примерно так):
if(FAILED(hr = _SomeFunction())){
… handling error…
}
Ну и если вы посмотрите на исходники той же Windows (например, в Direct X, чтобы далеко не ходить), вы увидите, что они сами тоже не очень жалуют эксепшены, и в настоящее время продолжают писать в Cи/COM стиле. Так что рано еще хоронить коды возврата :)
Пошел ставить новую фразу на screensaver :) просто и очень сильно сказано