Ну почему используют полутруп MFC вместо QT или wxWidgets?

Ну почему до сих пор держатся за это полудохлое MFC при разработке на С++, ведь есть же прекрасные фреймворки как QT так и wxWidgets. Даже если не принимать во внимание их кроссплатформенность, они по функционалу и удобству разработки уже на порядок превосходят MFC и разработка с ними становится по удобству схожа с Java/.NET разработкой.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну я бы не сказал, что писать на WinAPI намного удобнее чем на МФЦ, все такие, как правильно было замеченоМФЦ — это всего лишь объектная обертка для WinAPI, и если писать С++ объектный код, то зачем изобретать лисапед и писать свои классы , если есть уже МФЦ, хотя бы как базовая платформа.

Ну так в том то и вопрос, что MFC уже давно не единственная альтернатива WinAPI для построения GUI. Для простых интерфейсов — Wtl (по есть по сути WinAPI, только с некоторыми облегчающими плюшками, если речь об С++ конечно) — более чем достаточно. Для сложных интерфейсов — я бы MFC не трогал (ну убейте меня — но он страшный, как изнутри, так и снаружи), точно так же не трогал и WinAPI (иначе свой MFC напишете). А вообще -какая разница на чем — начнете писать на одном, сможете перейти на другое. И наоборот — не потянете писать более-менее сносно с MFC — то боюсь выше редактора диалогов в Qt не подняться. Хорошего программиста отличает умение быстро адаптироваться и изучать новое.

ПС: имел в виду ситуацию, когда человек выбирает, что изучать для себя. Про коммерческие проекты — тут выбор может определяться совсем другими факторами, причем удобство для программиста может быть на последнем месте.

ППС: когда ж редактор сообщений на ДОУ приведут в порядок? Конечно, уже не те спецэффекты, что ранее, но игнор абзацев при повторном редактировании просто убивает.

1 — На мой взгляд это так называемая совместимость с древним кодом и его поддержка. Столько всяких прог написано на МФЦ, что легче его дальше тянуть на МФЦ, чем юзать что то новое.
2 — Если требуется какой то нестандартный элемент интерфейса, который не поддерживается ни MFC ни тем же Qt, то ,на мой взгляд, написать его, используя тот же низкоуровневый WinAPI намного проще используя MFC как базовый набор классов.
Например пару лет наза от меня потребовалось писать очень нестандарный Grid, я взял класс из MFC, сделал наследника и переопределил кучу обработчиков в том числе и овнер-дроу и др.
Сомневаюсь, что на Qt получилось бы так же удобно переопределить стандарное поведение интерфейса, используя низкоуровневый WinAPI, хотя может я ошибаюсь.

3 — Опять таки есть нужно писать прогу с чистого листа, при этом используя только доступный функционал GUI, то тот же Qt выглядит предпочтительнее.

И последнее — не нужно забывать что MFC это детище(хоть уже давно и не поддерживаемое) того же мелкософта, а значит для использование под виндой оно более заточено чем сторонние либы.

Простите за оффтоп.
Ищу С/С++ разработчика с опытом в MFC, и желанием развиваться (карьерно в том числе).

Возможно кому-то будут интересны детали?

Тот же QT выглядит похуже на винде, чем МФЦ.

Да и смысл начинать писать на QT, если можно перейти на .НЕТ.

Ну вид это весьма субъективно. Меня и Qt вид и в гноме и в винде вполне устраивает. Хотя я не эстет. А МФЦ раздражает во всех отношениях (хотя наверно я его готовить не умею, хотя иногда приходится).

Да многом заказчик говорят, что должно использоваться. У некоторых есть корпоративные правила которые меняются раз в 10 лет. Причем без возможности всякого обсуждения. Дома пишу на том, чем хочу, на работе то что требуется и на чем требуется.

Некоторые канторы не устраивает лицензии от этих библиотек, а некоторый просто увеличивают объем работ, которые оплатит заказчик. Что лучше для канторы: купить лицензию Х баксов или освоить 10Х бюджет на написание велосипеда?

какие лицензии? Подключай и юзай хоть динамически хоть статически, если не вносишь изменения в генофонд.

В Qt «L» перед GPL появилась лишь, где-то с год назад, а до этого коммерческая разработка с Qt тянула на 2.5 Кевро, или что-то типа, на одного разработчика/год. При том, что если разработка ведётся лишь для Винды — Qt довольно-таки убог.

Если многоплатформенность не нужна — MFC всем хорош. А в качестве бесплатного «аналога» WTL.

Чем он хорош? MFC даже по сравнению с бесплатным клоном Delphi — Lazarus пролетает, так как разработка в разы проще, что благоприятно оказывается на стабильности приложения. Из-за MFC и отказались в пользу всяких .NET и Java, так как С++ всем хорош, кроме ранее уёбищной разработки GUI.

Это лишь для формошлёпов, невладеющих темой — MFC сложен, а Дельфи хорош.

Что же касается профессиональной разработки, в странах запада будет с полсотни позиций с MFC, на одну позицию с Дельфи.

В странах запада пишут на .NET с подключение библиотек на С++. Довольно удобно.

Не все ещё перелезли на .NET. Но я имел в виду позиции, разрабатывающиe в нативный код. Понятно, что сейчас таких позиций немного — может, 1 на 5 а то и на 10 позиций .NET/Java.

А на этом делфи еще ктото пишет? о_О

Угу

rabota.ua/...keyWords=Delphi

А вот удаленки уже нет, только офис :( Приходится писать на C#

Ыть...

Даже джунов набирают

Тык они уже 64-бита прикрутили. Так что Delphi снова стал аналогом C++, но с C#-вской простотой.

— signals/slots, под виндой реализованы либо через SendMessage/PostMessage, либо (что скорее), через сабжект/обсервер. Но никто не мешает использовать сабжект/обсервер самому.

— а что в МФЦ с юникодом не то?

— ДДХ неплох и в виде макросов существует из-за ограничений языка/АПИ

Архитектура ужасна и сложноосознаваема. Если архитектура QT, WxWidgets, VCL, SWING, Winforms в целом базируется на одном объектно-событийном постулате, то MFC это какой-то ужасный костыль над WinAPI.

По-моему проще писать уже прямо на WinAPI(пару своих объектов на него наворотить) чем на этом убожестве.

Кто?

В старых проектах выбора особого нет, а про новые на MFC я особо не слышал, хотя я особо не искал, по понятным причинам :)

Повторяю

В старых проектах выбора особого нет
Если уже куча всего написана на MFC, то прикручивать QT или wxWidgets смыслу особого нет, хотя рано или поздно все равно перейдут, хоть куда-то.

Підписатись на коментарі