MFC: is dead или еще нет?

Господа, подскажите несведующему, как под виндой обстоят дела с библиотеками для создания интерфейсов. Стоит ли изучать MFC, или он уже устарел, и имеет смысл сразу смотреть в сторону Win Forms? До этого занимался программированием с Qt, и плохо представляю актуальность использования других либ под винду. Что можете сказать по этому?

 

Я писал недавно проект, буквально месяца 3 назад, объёмом ~6 тыс. строк с использованием MFC в качестве GUI библиотеки. Тогда же познакомился с MFC впервые и решил, что больше никогда юзать не буду Данная библиотека показалась какой-то незрелой чтоли, хотя и много лет существует, но меня постоянно напрягала перегруженность интерфейсов у классов, какая-то неудобная общая архитектура классов(возможно я плохо спроектировал), что в итоге заставляло придумать некоторые костыли. Вообще половина библиотеки написана макросами, дикость какая Если бы не тесная интеграция со студией, то я вообще не вижу смысла юзать эту библиотеку.

С Qt я знаком плохо, на уровне "поставил, сделал пару примеров по хелпу", но даже на этом уровне библиотека мне показалась на уровень выше по качеству и абстракции, да ещё и кроссплатформенность

Win Forms - это ещё не вчерашний, но уже и не завтрашний день. MS вместе с framework 3.0 анонсировала технологию(скорее даже платформу) WPF(Windows Presentation Foundation) на базе которой можно создавать UI очень высокого класса. Вот это действительно интересно и что лично меня больше всего привлекает в WPF, так это уход от древнего GDI(отрисовка любых объектов в WPF производится с помощью DirectX с аппаратным ускорением и всеми вытекающими) и полное разделение процессов разработки UI и написания функционального кода.

 

IMHO.
Изучать там особо нечего - стандартная модель "Controller-View". Изначально это был покраденный борландовский OWL, потом пути несколько разошлись. Удобна, когда быстро нужно сделать что-то достаточно стандартное. Тонны примеров на codeguru etc. На rsdn, наверное, тоже есть - забыл, когда и был там. Глюков хватает, но есть документация и исходники. Достаточно компактна сама и экономит кучу времени и места по сравнению с написанием на API.

В Qt опыт небольшой на Win/Linux. Впечатления самые отвратительные (несмотря на большое сходство с MFC).

 

Спасибо за ответы! Правда меня больше интересовал вопрос актуальности MFC через некоторое время. Уже начал изучать эту либу.

Да, вещь далекая от совершенства, да еще и эта муть под названием метакомпилятор,
и невозможно встроить фриварную версию в VC++... Пишу на ней скрипя зубами.

 

?? У них же был вариант под винду (и именно под VC). Я брал Demo с сайта и выковыривал NAGs и reg-info из DLL.. "метакомпилятор" (это уже не С), UI designer, Unicode, дрянные решения (типа ZLib в обертке qCompress) + неприемлемый для меня стиль написания кода... счастлив был забыть

M$ каждую пару лет меняют технологии и объявляют их устаревшими (хотя, реально, устаревшими они были еще в момент создания) - это маркетинг. Пока живы компилятор и платформа, на которой можно запустить MFC - оно актуально. Тот же DOS и сейчас используется в Real-Time системах.

 

MFC была актуальна лет пять назад. Посмотри когда выпускались самые популрные книги по MFC (подскажу, что новее 2002 хороших книг не найдёшь). Поищи заявления MS за последние годы в которых компания говорит о намеренности развивать эту технологию. Посмотри, когда в MFC появлялось что-то действительно новое. MFC не развивается, она просто поддерживается для уже существуюшего кода.
Да были бы там какие-то возможности особенные, я бы понял твой выбор, но как можно предпочесть умирающую библиотеку с посредственным функционалом новому развивающемуся и популярному фрейворку(Qt), я отказываюсь понимать

Это значит DOS актуален и его нужно изучать? Бред.

 

W4FhLF
+1, вот да.. наверное, лучше и не напишешь
Но все равно помню, сравнивал GUI Microsoft Office Word 2007 c похожим аналогом с www.codeproject.com (Ribbon Panel Office 2007 style)
Так вот этот Ribbon мягко говоря, ну никак не дотягивает до сишного кода

P. S.
Лучше чистых API(!), ахтунги из Microsoft еще не придумали(сколько им уже лет?!(но все равно успели запоганить своими прототипами API функций почти полностью C++(несовместимостью разных буквочек в названии типа DWORD) ну оттуда весь практически флейм на форумах)ведь можно просто взять там где можно в место PVOID, LPSTR итд. заменить на DWORD, сколько хедеров из природы сразу исчезнед) и многие знают, что постоянно явное привидение типов приходиццо юзать (Кстати в C# они так почти и сделали, но со знаковой типизацией гемор оставили бгг.)
И сложности быть вообще не может, если постоянно кодить с помощью чистых API
Это тоже что и когда впервые куда-то идешь (начинаешь у всех спрашивать как доехать туда-то, как пройти итд.), но это только когда первый раз
Потом когда ездишь/ходишь целый год в одно и тоже место, это все происходит автоматизировано мозгом(так и с чистым API)
Ну и для примера чтоб наверняка, все дружно вспомним лолненькую AfxMessageBox (вот нах ее в природе придумали, для полных чайнадаунов чтоле..)
абстракция от Microsoft – просто аццки пацталом плакать можно!
ЗЫ: ИМХО

 

Demon666

и далеко ты так уедешь?? писать руками тысячи строк лишнего кода?
лучше уж аццки пацталом плакать можно MFC с лольненьким MessageBox'ом как по мне..

 

Demon666

Я с тобой не согласен в плане того, что в приложении следует использовать API. В общем-то, если ты системный программист и пишешь утилиты для продвинутых пользователей/программистов/админов, то там основной акцент следует делать на функционале, а UI вообще не всегда обязателен, есть консоль. Да, но основная часть средств в мире разработки ПО вращается вокруг различных бизнес-систем и решений и на этом рынке есть большой спрос на людей, которые способны создавать интерфейсы с высоким юзабилиты, удобные и, что в последнее время модно, интерактивные. При прочих равных, если твой конкурент умеет это делать, а ты нет или он делает это быстрее, качественнее, красивее, то заказчик предпочтёт именно его. Хорошо это или плохо, who cares? Это рынок и под него нужно уметь вовремя подстраиваться.

Вот недавний пример. Знакомый работает в одной фирме разработчиком, пишет софт обработки изображений и информации полученные с разных девайсов(неважно каких, суть не в этом). GUI разрабатывался с использованием MFC. Фирма развивается, потребовалось расширение и в том числе поддержка *nix. Писать второй продукт и поддерживать потом два продукта - невыгодно. Было принято решение портировать софт с использованием Qt. C задачей справились, но Qt сейчас - это не просто библиотека для рисования форм, там есть компоненты для созданий сцен с поддержкой огромного числа объектов(при этом на низком уровне используется OpenGL), а это позволило здорово улучшить и качество отрисовки объектов и возможности работы с ними(когда писали с использованием MFC реализация таких возможностей требовала огромных затрат). Вот, кто не верит, официальный пример от троллтеков, где на форме 4 представления сцены с 40 000 элементов:
http://depositfiles.com/files/6118720

Обратите внимание на код, очень простой и логичный. А теперь представьте чего стоит создать такое на WinAPI или MFC(хотя с GDI такое вряд ли даже возможно)

Нечто подобное так же легко создаётся с использованием WPF.

Я уверен, что WPF - это то, на чём MS сделает упор в сфере разработки UI в ближайшие лет 5 точно.

 

Спасибо, поржал

 

И сложности нет и смыса тоже (относительно уя точно)

 

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

гы-гы, ога прям в виндовом блокноте(сорри не сдержался) и нигде более %)
ща писать не че и не надо, почти все уже написано, гуглишь и копипастьшь(ну накрайняк рип)

 

Представьте, актуален. На том же exetools тьюторам по взлому DOS программ отведена отдельная секция. Многие нынешние антиотладочные техники пришли оттуда. Другие техники (double buffering, page swapping) не слишком изменились. TurboVision (DOS) я бы просто ввел обязательным предметом. Террабайты высококачественного кода под однозадачную OS в которой можно было делать _все_ никогда не станут бредом.

 

Откуда такое пренебрежительное отншение к блокноту?
gazlan, +1.

 

gazlan

Я понимаю, всё познаётся в сравнении Я не отрицаю, что, возможно, сейчас на каждые N тысяч вакансий программиста под Windows приходится одна вакансия на программиста под DOS. Позволяет ли нам такая статистика судить об актуальности DOS'a и целесообразности выбора платформы для изучения? Я считаю, что позволяет. Может у вас другие критерии актуальности.

1. Как вы оценили такой объём?
2. Как вы оценили качество такого объёма кода?

 

Конъюнктурщики.

Хм, в конце XIX века тоже считалось, что в физике всё открыто.

 

1. Под DOS было создано больше программ, чем под все остальные OS вместе взятые. Эт от код и сейчас доступен на многих публичных архивах (большей частью на TC 2.0)

2. Во времена 5.25" дискет на 360 Kb (первоначально - 180) и 512 Kb RAM (640 и XMS пришли позднее) для плохого кода просто не было места - ни на дискетах, ни в памяти.

 

1. Под DOS было создано больше программ, чем под все остальные OS вместе взятые. Эт от код и сейчас доступен на многих публичных архивах (большей частью на TC 2.0)

2. Во времена 5.25" дискет на 360 Kb (первоначально - 180) и 512 Kb RAM (640 и XMS пришли позднее) для плохого кода просто не было места - ни на дискетах, ни в памяти.

 

gazlan, мы уже оффтопим.

Откуда эта статистика? И куда помещались эти терабайты, в 512 кб ram?

Да Вы максималист

 

RIP

Да ну? Откуда такая дезинформация? Больной, вам пора на процедуры.

Вспоминается старый анекдот про язык Ада, С и платформы. Ну да, конечно актуально, кому то же надо все-таки подавать мне кофе.