Все – на Windows Forms?

[Rookie]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

[vovap]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

Каковы преимущества любого языка программирования по сравнению с ассемблером процессора кроме упрощения процесса development’a?

[Rookie]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

Каковы преимущества любого языка программирования по сравнению с ассемблером процессора кроме упрощения процесса development’a?

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы. Или для .NET performance overhead не столь велик?

[vovap]

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы. Или для .NET performance overhead не столь велик?

Он не полуэнтерпритируемый, он компилируемый. И GUI его, насколько моя тупость понимает, обращается за работой к оконным библиотекам Windows а не делает все само, как Sving.
Не вдаваясь, однако, в этот флейм, я вообще не вижу в современных уловиях смысла говорить о "скорости работы GUI"

[Rookie]

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы. Или для .NET performance overhead не столь велик?

Он не полуэнтерпритируемый, он компилируемый. И GUI его, насколько моя тупость понимает, обращается за работой к оконным библиотекам Windows а не делает все само, как Sving.
Не вдаваясь, однако, в этот флейм, я вообще не вижу в современных уловиях смысла говорить о "скорости работы GUI"

Не имел ни малейшего намерения начинать флейм; очень жаль, что Вы это так воспринимаете. Все, что меня интересует – наскольно значителен performance overhead для Windows Forms, т.е. насколько его следует принимать во внимание. Возможности в плане упрощения разработки, предоставляемые Winforms, действительно впечатляют, но в Сети в том числе приходилось читать и о Forms как “being substantially slower than MFC”. Если я правильно понял Ваше последнее сообщение, Вы хотели сказать, что разница эта незначительна.

P.S. Под «полуинтерпретируемостью» я (быть может, не совсем точно) имею в виду хоть и «по требованию», но все-таки компиляцию CIL при запуске .NET-приложения. Отвлекаясь от Windows Forms, по личному опыту знаком с задержками на секунду-две при запуске примитивного консольного “Hello world”.

[vovap]

Не имел ни малейшего намерения начинать флейм; очень жаль, что Вы это так воспринимаете.

Да нет, Вы не начинали, просто если мы начнем рассуждать о том - компилируемый язык или нет - то он неизбежно начнется, уж поверьте - набегут

Все, что меня интересует – наскольно значителен performance overhead для Windows Forms, т.е. насколько его следует принимать во внимание. Возможности в плане упрощения разработки, предоставляемые Winforms, действительно впечатляют, но в Сети в том числе приходилось читать и о Forms как “being substantially slower than MFC”. Если я правильно понял Ваше последнее сообщение, Вы хотели сказать, что разница эта незначительна.

Именно, я полагаю, что нет никакого смысла рассуждать о этой разнице - ибо скорость работы интрефейса у большинства нормальных приложений сейчас как мощность двигателя ролса - "достаточная".
Я вообще глубоко убежден, что кроме весьма специальных случаев скорость работы программы засисит от ее писателя минимум процентов на 80 - а от платформы - не более чем на 20.

[DR_35_USA]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

Никаких преимуществ, разработка упрощается только до некоторой степени, после которой надо лезть из дот-нета в Win32 и начинается морока

[mbabayan]

В WinForms есть серьезные функциональные ограничения.
Я бы его по уровню сравнил с VB Forms, но никак не с MFC.

Арxитектура Document/View - отсутсвует, система иерархической прокачки командных и статусных сообщениий отсутствует....

При попытке написать серьезное приложение резко возникает ощущение детского конструктора.

[Rookie]

Не имел ни малейшего намерения начинать флейм; очень жаль, что Вы это так воспринимаете.

Да нет, Вы не начинали, просто если мы начнем рассуждать о том - компилируемый язык или нет - то он неизбежно начнется, уж поверьте - набегут

О да, это уж точно.

Именно, я полагаю, что нет никакого смысла рассуждать о этой разнице - ибо скорость работы интрефейса у большинства нормальных приложений сейчас как мощность двигателя ролса - "достаточная".
Я вообще глубоко убежден, что кроме весьма специальных случаев скорость работы программы засисит от ее писателя минимум процентов на 80 - а от платформы - не более чем на 20.

Полностью с Вами согласен. Спасибо, что развеяли мои сомнения относительно недостатков WinForms - они действительно не столь существенны.

[Sanek]

Мне тут выпало "счастье" написать гуй. Посмотрел на .нет, сказал ему нет. Конструктор он и есть. Сейчас ваяю на Qt.

[Sergey___K]

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы.

У меня особые опасения пропали уже где-то с VB 3.

То Sanek: Что есть Qt?

[Каскыр]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

Каковы преимущества любого языка программирования по сравнению с ассемблером процессора кроме упрощения процесса development’a?

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы. Или для .NET performance overhead не столь велик?

Зато толкает технический прогресс! Потребуется более быстрое железо, это даст новые работы, при более мощном железе программирование можно будет ещё упростить, больше бизнеса аутсорсить в Индию, или - даже на Чукотку, и так далее.

[Sanek]

Согласен; тем не менее, GUI, написанный на полуинтерпретируемом языке вызывает сомнения относительно скорости работы.

У меня особые опасения пропали уже где-то с VB 3.

То Sanek: Что есть Qt?

http://www.trolltech.com/products/qt/index.html

[Strannik223]

Мне тут выпало "счастье" написать гуй. Посмотрел на .нет, сказал ему нет. Конструктор он и есть. Сейчас ваяю на Qt.

Инересно, что полезного можно почерпнуть из такого сообщения

[Strannik223]

но в Сети в том числе приходилось читать и о Forms как “being substantially slower than MFC”. Если я правильно понял Ваше последнее сообщение, Вы хотели сказать, что разница эта незначительна.

Ссылки в студию!
Вы когда нибудь трассировали жизненный цикл сообщения в MFC?
Он такие претурбации и исторические наслоения проходит что ни о какой скорости нельзя вести речи

Более бездарно спроектированой библиотеке чем MFC я не видел

[Strannik223]

В WinForms есть серьезные функциональные ограничения.
Я бы его по уровню сравнил с VB Forms, но никак не с MFC.

Арxитектура Document/View - отсутсвует, система иерархической прокачки командных и статусных сообщениий отсутствует....

При попытке написать серьезное приложение резко возникает ощущение детского конструктора.

Позвольте не согласиться

Document/View не навязывается но это не значит что он отсутствует. Что вам мешает определить в классе представляющим данные events и подписать форму на эти события?

Команды - да на их место пришла другая парадигма, все теперь на события завязано (которые реализованы на callback). При наличии некоторого желания и знаний делом на пол часа есть переопределить WndProc и проимпортировать SendMessage.

[Strannik223]

Мне тут выпало "счастье" написать гуй. Посмотрел на .нет, сказал ему нет. Конструктор он и есть. Сейчас ваяю на Qt.

Qt библиотечка весьма симпатичная: проработаная иерархия классов, интуитивно понятные имена функций, документация просто идеальна. Недаром самый мощный Юникс gui (KDE) на ней написан
Недостатки: для того что бы решить недостаток C++ - отсутствие reflection был применен свой собственный прекомпилятор который макро OBJECT в данные о классе разворачивает
Библиотека платная для коммерческого использования, для Юникса можно текущую версию скачивать а для винды дают какую-то древнюю

[Sanek]

От меня пользы в этом разделе вообще мало, я не теоретик.

[DP]

Недаром самый мощный Юникс gui (KDE) на ней написан

я почему то думал что у Apple то GUI помощнее будет ...

[Strannik223]

Недаром самый мощный Юникс gui (KDE) на ней написан

я почему то думал что у Apple то GUI помощнее будет ...

Пардон, вношу поправку: самый мощный OpenSource gui :)

[DR_35_USA]

А вообще, какие такие WindowsForms? Прошлый век, ребяты, уже Avalon можна пробовать, весь такой XML-истый, DirectX-нутый, GDI+-нутый

Давайте луче про Avalon поговорим, я Longhorn ставил, а вот студию под него - нетути. Тока статейки почитал

[windfall]

Ссылки в студию!
Вы когда нибудь трассировали жизненный цикл сообщения в MFC?
Он такие претурбации и исторические наслоения проходит что ни о какой скорости нельзя вести речи

Более бездарно спроектированой библиотеке чем MFC я не видел

Конкретно, в чем именно бездарность ее проектирования? Общие фразы не принимаются, конкретный пример, пожалуйста, и с объяснением, как это можно было сделать лучше.

Из своего опыта пожизненного программирования на MFC скажу - да, есть баги. За эти годы я нашел штук пять. Есть некоторая кривизна, в основном вызванная кривизной лежащего под MFC Win32 API. Да, MFC устарела на сегодняшний день - это тоже есть. Посмотрим, что станет с дот-нетом через 6 лет.

Но бездарности проектирования - не заметил. Который раз уже ввязываюсь в подобную дискуссию. И каждый раз после бурных споров выясняется, что дело не в библиотеке, а в прослойке между креслом и клавиатурой.

[windfall]

Какие преимущества у Windows Forms по сравнению с Win32 API и MFC, кроме упрощения процесса development’a? По скорости работы приложения Windows Forms – наверняка медленнее, да еще и нужно, чтобы .NET Framework на машине был установлен. Или преимущества перевешивают недостатки?

WinForms работает только там, где установлен .NET. То есть на сегодняшний день - далеко не везде. Это достаточный недостаток, или как?

Говоря о перфомансе - вместо абстрактных рассуждений об интерпретируемости/JIT-компилируемости/линкумости, просто возьмите и сравните 3 параметра для приложений с одинаковой функциональностью:

1) Скорость выполнения какой-нибудь вычислительной задачи.
2) Время запуска приложения от дабл-клика до способности обрабатывать ввод пользователя.
3) Использованную на этот момент память.

1) будет отличаться на пару процентов, не более.
2) и 3) будут отличаться как минимум в разы.

[Strannik223]

А вообще, какие такие WindowsForms? Прошлый век, ребяты, уже Avalon можна пробовать, весь такой XML-истый, DirectX-нутый, GDI+-нутый

Давайте луче про Avalon поговорим, я Longhorn ставил, а вот студию под него - нетути. Тока статейки почитал

Давайте поговорим :)

1. Между прошлым и будущим что то у нас существует? Я к тому что Longhorn когда выйдет, года через 2? Так что объявлять формс прошлым веком вы поторопились :)

2. Преценденты использования xml для построения gui есть, например mozilla XUL (Xml UI Language если не ошибаюсь).

3. К тому времени когда Longhorn выйдет есть ненулевая вероятность что аналогичная технология будет реализована в том же KDE. Если я правильно понял то уже сейчас кое какие иконки в KDE рисуються в svg. http://svg.kde.org

4. МС реализовала свою технологию аналогичную svg-1.2 и ближаешие 2 года будет довольно интересное противостояние. С технологической точки зрения явного победителя не видно, микросфт как всегда делает свою технологию более простой для использования но у w3c уровень абстрактности спецификаций выше

[Rookie]

но в Сети в том числе приходилось читать и о Forms как “being substantially slower than MFC”. Если я правильно понял Ваше последнее сообщение, Вы хотели сказать, что разница эта незначительна.

Ссылки в студию!
Вы когда нибудь трассировали жизненный цикл сообщения в MFC?
Он такие претурбации и исторические наслоения проходит что ни о какой скорости нельзя вести речи

Более бездарно спроектированой библиотеке чем MFC я не видел

Вы правы, лучше не быть голословным. Пожалуйста.

http://www.appdevadvisor.co.uk/Downloads/ADA7_3/Anderson7_3.pdf
Visual C++ with Windows Forms
“…Even so, certain things are much slower in .Net. The managed GDI+ classes are far slower than Win32 GDI, which may account for the sluggish performance of some Windows Form applications.”

Или, еще интереснее:

http://www.nku.edu/~hauserj/NET%20Performance.ppt
Везде, кроме OS Intensive (о чем в отношении MFC, как я понял, Вы и говорите), .NET значительно медленне как Win32, так и MFC.

Legal disclaimer: указанные ссылки нельзя считать официальной информацией (впрочем, Вы вряд ли бы ожидали увидеть такое на microsoft.com); приведены они лишь как основание для сомнений, которые побудили меня начать эту ветку.

P.S. Сама фраза “…substantially slower than MFC” – из ветки на другом форуме. При необходимости ссылка также может быть предоставлена.