Все – на Windows Forms?

[IA72]

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

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

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

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

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

Нет, конечно. Qt, к примеру, требует (угадайте ) наличия Qt.
Установить .NET дело простое, инсталлятор вашей программы проверит его наличие за вас и скачает (если вы по инету свою софтинку распространяете) либо возьмет с вашего CD.
К примеру, вот эти ребята http://www.red-gate.com/sql/summary.htm
тоже так считают. Кстати, лучший инструмент для сравнения баз, который я когда-либо видел.

[IA72]

Более бездарно спроектированой библиотеке чем 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” – из ветки на другом форуме. При необходимости ссылка также может быть предоставлена.

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?
Первая какая-то популярная статейка безо всяких цифирек, вторая - попсовые примитивные тесты, к WinForm и MFC не имеющие никакого отношения. Ведь нельзя считать перемножение переменных и выделения памяти под массив частью winforms & MFC? Причем и результаты не вызывают доверия. Если же интересуют подобные тесты, то лучше посмотреть
http://osnews.com/story.php?news_id=5602
И соответствующие тред на /.

[Rookie]

Более бездарно спроектированой библиотеке чем 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” – из ветки на другом форуме. При необходимости ссылка также может быть предоставлена.

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?

А Вам не стыдно, не читая внимательно ветку и ее сообщения, пристыжать других? "Доводы" существуют в споре, в котором я не участвую и не собираюсь. Перечитайте ветвь сначала еще раз и мое последнее сообщение в частности; в "Legal disclaimer", по-моему, все достаточно ясно объяснено.

[IA72]

Более бездарно спроектированой библиотеке чем 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” – из ветки на другом форуме. При необходимости ссылка также может быть предоставлена.

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?

А Вам не стыдно, не читая внимательно ветку и ее сообщения, пристыжать других? "Доводы" существуют в споре, в котором я не участвую и не собираюсь. Перечитайте ветвь сначала еще раз и мое последнее сообщение в частности; в "Legal disclaimer", по-моему, все достаточно ясно объяснено.

Что такое legal disclaimer я не понимаю, по-русски это будет "я тут фигню запостил, сам это понимаю, но ничего другого нет"?
Ну хорошо, согласен убрать "доводы". Остальное
"Слушайте, а вам не стыдно самому такие ссылки приводить"
остается в силе.

[Strannik223]

http://www.nku.edu/~hauserj/NET%20Performance.ppt

Более наивного (если не сказать больше) теста чем этот сложно придумать, дам комментарии позже, а то надо распределенный сервис на шарпе сегодня закончить :)))

[Rookie]

Более бездарно спроектированой библиотеке чем 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” – из ветки на другом форуме. При необходимости ссылка также может быть предоставлена.

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?

А Вам не стыдно, не читая внимательно ветку и ее сообщения, пристыжать других? "Доводы" существуют в споре, в котором я не участвую и не собираюсь. Перечитайте ветвь сначала еще раз и мое последнее сообщение в частности; в "Legal disclaimer", по-моему, все достаточно ясно объяснено.

Что такое legal disclaimer я не понимаю, по-русски это будет "я тут фигню запостил, сам это понимаю, но ничего другого нет"?
Ну хорошо, согласен убрать "доводы". Остальное
"Слушайте, а вам не стыдно самому такие ссылки приводить"
остается в силе.

Окей, попробую еще раз.
Я ни в коем случае не претендую на то, что данные ссылки могут служить источником сколь-либо объективной информации. В одном из начальных постов я упомянул о том, что в Сети приходилось читать (по-моему, эта фраза ни к чему не обязывает - или?) о performance issues Windows Forms; меня попросили дать ссылки, что я и сделал.
Еще раз (это касается и других, пытающихся воспринимать эти насчастные ссылки как доказательства в воображаемом споре): я не хочу ни с кем спорить и никому ничего доказывать. Моей целью было выяснить, насколько, согласно опыту уважаемых участников форума, производительность Windows Forms уступает Win32 и MFC. Вместо этого мы, как и предсказал vovap (который, кстати, дал одни из самых конструктивных ответов), скатываемся в банальный флейм, где я, как оказывается, - яростный противник .NET. Смешно, господа. Вот как раз это и должно быть стыдно.

[Strannik223]

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?
Первая какая-то популярная статейка безо всяких цифирек, вторая - попсовые примитивные тесты, к WinForm и MFC не имеющие никакого отношения. Ведь нельзя считать перемножение переменных и выделения памяти под массив частью winforms & MFC?

Вовсе не обязательно сразу наезжать
Тем более вы сами попались на ньюанс который не все знают
MFC сама управляет памятью, у нее есть несколько memory spool, для мелких, средних и больших объектов. Эта прослойка наверное и вносит такую большую задержку

[IA72]

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?
Первая какая-то популярная статейка безо всяких цифирек, вторая - попсовые примитивные тесты, к WinForm и MFC не имеющие никакого отношения. Ведь нельзя считать перемножение переменных и выделения памяти под массив частью winforms & MFC?

Вовсе не обязательно сразу наезжать
Тем более вы сами попались на ньюанс который не все знают
MFC сама управляет памятью, у нее есть несколько memory spool, для мелких, средних и больших объектов. Эта прослойка наверное и вносит такую большую задержку

То есть вы согласны с результатами и корректностью тестов?

[windfall]

http://www.nku.edu/~hauserj/NET%20Performance.ppt

Заглянул в этот "тест". Слов не осталось, одна ругань. Боже, куда катится мир.

[Strannik223]

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?
Первая какая-то популярная статейка безо всяких цифирек, вторая - попсовые примитивные тесты, к WinForm и MFC не имеющие никакого отношения. Ведь нельзя считать перемножение переменных и выделения памяти под массив частью winforms & MFC?

Вовсе не обязательно сразу наезжать
Тем более вы сами попались на ньюанс который не все знают
MFC сама управляет памятью, у нее есть несколько memory spool, для мелких, средних и больших объектов. Эта прослойка наверное и вносит такую большую задержку

То есть вы согласны с результатами и корректностью тестов? :)

Вы ОЧЕНЬ невнимательно читаете топик
Я несколькими сообщениями выше высказал свое мнение по поводу этих тестов. Но так как доказательсво их несостоятельности займет некоторое время то я пообещал сделать это вечером когда домой прийду

Кричать sucks & must die вообще не есть признак профессионализма. Если есть что конкретно сказать не пожалейте времени и выскажитесь (аргументировано), в противном случае это flame в чистом виде, потому что вы просто поленились собрать данные и свои мысли по этому поводу

На одну из ваших ошибок я уже указал: работа memory allocator-а в MFC и pure C++ отличается что и видно по результатам

[Strannik223]

http://www.nku.edu/~hauserj/NET%20Performance.ppt

Заглянул в этот "тест". Слов не осталось, одна ругань. Боже, куда катится мир.

Лучше все-таки словами
Вы это про то что автор полагал что цикл for(inti=0;.......) может дать разные результаты на MFC & C++? :)))))))

[IA72]

Слушайте, а вам не стыдно самому такие ссылки приводить как доводы?
Первая какая-то популярная статейка безо всяких цифирек, вторая - попсовые примитивные тесты, к WinForm и MFC не имеющие никакого отношения. Ведь нельзя считать перемножение переменных и выделения памяти под массив частью winforms & MFC?

Вовсе не обязательно сразу наезжать
Тем более вы сами попались на ньюанс который не все знают
MFC сама управляет памятью, у нее есть несколько memory spool, для мелких, средних и больших объектов. Эта прослойка наверное и вносит такую большую задержку

То есть вы согласны с результатами и корректностью тестов?

Вы ОЧЕНЬ невнимательно читаете топик
Я несколькими сообщениями выше высказал свое мнение по поводу этих тестов. Но так как доказательсво их несостоятельности займет некоторое время то я пообещал сделать это вечером когда домой прийду

Кричать sucks & must die вообще не есть признак профессионализма. Если есть что конкретно сказать не пожалейте времени и выскажитесь (аргументировано), в противном случае это flame в чистом виде, потому что вы просто поленились собрать данные и свои мысли по этому поводу

На одну из ваших ошибок я уже указал: работа memory allocator-а в MFC и pure C++ отличается что и видно по результатам

Так вы считаете тесты корректными? Если да, то извините, если нет - то тогда причем тут кричать sucks & must die? Что бы определить, что окорок тухлый, не надо есть его целиком, а уж доказывать несостоятельность... Считаю оправданным наезд на того, кто запостил на них ссылки. Ибо нефиг.
Аргументы приводить считаю совершенно излишними, если надо нормальных тестов, то ссылку я приводил.

[windfall]

http://www.nku.edu/~hauserj/NET%20Performance.ppt

Заглянул в этот "тест". Слов не осталось, одна ругань. Боже, куда катится мир.

Лучше все-таки словами
Вы это про то что автор полагал что цикл for(inti=0;.......) может дать разные результаты на MFC & C++? ))))))

И это тоже.

Можно было бы аргументированно указывать на ошибки, если бы автор документа проделал какую-то работу, подбирая жизненные сценарии вместо 4-х арифметических действий (которые скорее всего сворачиваются оптимизатором в одни и те же инструкции во всех трех случаях, а различия вызваны неудачным thread switch-ем или page fault-ом), а получив результат, попытался бы объяснить причину различий и при необходимости исправить тесты.

А тут, ошибка по сути только одна - когда человек взялся за вопрос, в котором не понимает ровным счетом ничего. Тут можно только покрутить пальцем у виска и забыть.

[Strannik223]

Можно было бы аргументированно указывать на ошибки, если бы автор документа проделал какую-то работу, подбирая жизненные сценарии вместо 4-х арифметических действий (которые скорее всего сворачиваются оптимизатором в одни и те же инструкции во всех трех случаях, а различия вызваны неудачным thread switch-ем или page fault-ом), а получив результат, попытался бы объяснить причину различий и при необходимости исправить тесты.

На самом деле интересно какой код генерится для шарпа и для C и почему у шарпа такой разрыв. Оптимизатор то для шарпа то же работает и машинный код генерит (несмотря на то что здесь некоторые думают :)
Я честро говоря ожидал идентичых результатов
Вечером попробую сравнить asm-ы

[mbabayan]

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

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

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

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

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

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

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

А самое главное - возможность обработки не триггеров этих эелементов а их состояний. (включено / выключено , и т.д.). Попытайстесь сымплементить это на WinForms-овом меню например, где каждый элемент меню - отдельный обьект..

Вопрос не в том что на WinForms всего этого нельзя заполучить, я в том что это надо разрабатывать с нуля. Точно так же можно и по Петцольду на АПИ писать.
Мне бы очень хотелось видеть нормальную реализацию модели Документ/Вид/Контроллер в Винформс.. однако..

[Sergei VP]

Лично я уже полгода имею дело с Windows Forms.
Достоинства и недостатки у них примерно те же, что и в VB или Delphi. Лично я уже пол года имею дело с Windows Forms.
Достоинства и недостатки у них примерно те же, что и в других средах RAD, например VB или Delphi. Коротко могу сказать что, производительность ниже, возможности и гибкость ограничены, но клепать простые окна (формы) можно действительно быстрее.
Супер качественый GUI такой как в приложениях Microsoft Office, например, на них вряд-ли получится, поэтому вывод такой: если Вам нужно быстро сделать простой GUI, например, состоящий из кнопок и полей ввода, то Windows Forms сгодятся, а серьёзные вещи лучше делать на чём-то другом.
Лично мне больше всего нравится WTL, что касается MFC то тут конечно есть много недостатков, но в тоже время для него есть куча хороших библиотек. WTL – это неофициальная библиотека Майкрософта, и она имеет и баги, и недоработки но гибкость и прозрачность их компенсирует с моей точки зрения.
Если писать нечто более-менее сложное на Windows Forms приходится иногда вызывать WinAPI, через Interop, так как не всё что нужно там реализовано, при этом конечно же теряется переносимость и т.д.. К тому же мне не нравится когда появляется окно, а потом его child-ы рисуются на глазах у пользователя, такое происходит в основном с контролами написанными на .NET и ActiveX, конечно это бывает только первый раз если JIT-компилятор ещё не скомпилировал нужные методы. Может я не понимаю “современных” подходов но такой фликериг почему-то меня раздражает.
Кто не согласен, посмотрите на сам Майкрософт, они абсолютно не собираются писать, скажем, Microsoft Office на Windows Forms и вообще на managed коде, тоже самое касается и других продуктов, например новая версия SQL Server Yukon написана на обычном С/С++. Так что по моему, наилучшая сфера для .NET – это DNA, ASP.NET и пр, а не полностью всё, что пишется под Windows, как утверждают некоторые “компетентные” источники.

[Dmitry S]

Кто не согласен, посмотрите на сам Майкрософт, они абсолютно не собираются писать, скажем, Microsoft Office на Windows Forms и вообще на managed коде, тоже самое касается и других продуктов

Откуда у вас информация, что и как собирается и что не собирается делать Microsoft?

[Sergei VP]

Кто не согласен, посмотрите на сам Майкрософт, они абсолютно не собираются писать, скажем, Microsoft Office на Windows Forms и вообще на managed коде, тоже самое касается и других продуктов

Откуда у вас информация, что и как собирается и что не собирается делать Microsoft?

Майкрософт конечно же такой информации мне не предоставляет. Но на счёт того, что Yukon написан на неупровляемом C++ есть упоминание в книге Джефри Рихтера, а по поводу Office я говорил имея ввиду Office 2003.
Могу перефразировать своё высказывание чтобы избежатиь глупых споров:
"Майкрософт не разрабатывал последнюю версию Microsoft Office на Windows Forms". И лично я не верю, что для этого в ближайшее время будет использоваться Windows Forms или Avalon.
Просто сейчас ходят слухи, что WinAPI никому уже не нужно и всё нужно делать под .NET, но на практике как мне кажется это не верно.

[Dmitry S]

Кто не согласен, посмотрите на сам Майкрософт, они абсолютно не собираются писать, скажем, Microsoft Office на Windows Forms и вообще на managed коде, тоже самое касается и других продуктов

Откуда у вас информация, что и как собирается и что не собирается делать Microsoft?

Майкрософт конечно же такой информации мне не предоставляет. Но на счёт того, что Yukon написан на неупровляемом C++ есть упоминание в книге Джефри Рихтера, а по поводу Office я говорил имея ввиду Office 2003.
Могу перефразировать своё высказывание чтобы избежатиь глупых споров:
"Майкрософт не разрабатывал последнюю версию Microsoft Office на Windows Forms". И лично я не верю, что для этого в ближайшее время будет использоваться Windows Forms или Avalon.
Просто сейчас ходят слухи, что WinAPI никому уже не нужно и всё нужно делать под .NET, но на практике как мне кажется это не верно.

Как вы думаете, когда начался цикл разработки Office 2003? И вспомните, когда появился .NET.
А верить или не верить во что угодно - ваше право.

[Sergei VP]

Как вы думаете, когда начался цикл разработки Office 2003? И вспомните, когда появился .NET.
А верить или не верить во что угодно - ваше право.

Я думаю что цикл разработки Office 2003 начался после начала цикла разработки .NET.
Конечно я прекрасно осознаю, что там работает огромное количество кода, написанного ещё и для прежних версий офиса, и всё это необходимо портировать под Windows Forms, и задача это очень не простая и требует много времени.
Но я лично не верю что Майкрософт будет этим заниматься, и на это есть совершенно другая причина, .NET разрабатывался для DNA, а не для DeskTop приложений с высококачественным GUI.

Я не являюсь противником .NET и Windows Forms, я просто считаю, что практическая сфера применения этих технологий не так широка как нас пытаются убедить.
Подобные вещи уже происходили в прошлом, вспомните VB, MFC, ActiveX, при появлении этих продуктов кричали со всех сторон, что о WinAPI можно забыть, но на практике лично мне очень часто приходится им пользоваться, даже работая Windows Forms. И иметь знания в WinAPI очень важно и сейчас.

А вы всерьёз верите, что весь GUI будет на Windows Forms?

[Roy]

Как вы думаете, когда начался цикл разработки Office 2003? И вспомните, когда появился .NET.
А верить или не верить во что угодно - ваше право.

Я думаю что цикл разработки Office 2003 начался после начала цикла разработки .NET.
Конечно я прекрасно осознаю, что там работает огромное количество кода, написанного ещё и для прежних версий офиса, и всё это необходимо портировать под Windows Forms, и задача это очень не простая и требует много времени.
Но я лично не верю что Майкрософт будет этим заниматься, и на это есть совершенно другая причина, .NET разрабатывался для DNA, а не для DeskTop приложений с высококачественным GUI.

Я не являюсь противником .NET и Windows Forms, я просто считаю, что практическая сфера применения этих технологий не так широка как нас пытаются убедить.
Подобные вещи уже происходили в прошлом, вспомните VB, MFC, ActiveX, при появлении этих продуктов кричали со всех сторон, что о WinAPI можно забыть, но на практике лично мне очень часто приходится им пользоваться, даже работая Windows Forms. И иметь знания в WinAPI очень важно и сейчас.

А вы всерьёз верите, что весь GUI будет на Windows Forms?

Офис и SQL, конечно, вряд ли в ближайшее будущее будет полностью переписан на .NET (вы представляете, какой объём работы для этого требуется - никто себе такого не позволит), однако многие другие продукты МС полностью или частично используют .NET. В частности APS.NET и XML, XSL парсеры на 99% процентов на писаны на С#.
MS CRM полностью написан на .NET технологиях.

[IA72]

http://www.internetnews.com/ent-news/ar ... hp/3310521

Office 12, the next version due no earlier than 2006, will use the Avalon user interface, the WinFS database-driven file system and the WinFX API (define). It may also offer development APIs that are natively accessible to applications running on the .Net framework, according to the report.

[Dmitry67]

У юкона на шарпенписа вес интерфейс
Сами сервисы размеется C++