Здравствуйте, AlexGin, Вы писали:
AG>Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире 
AG>Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1Автор: MasterZiv
Дата: 27.04.17
— я обещал товарищу MasterZiv вернуться к теме
AG>обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).
Ну, тогда не могу не поучаствовать в топике
AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не
понимают. Для многих MFC -- это огромный и страшный монстр.
AG> Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt
AG> имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
AG> выполнить совсем не сложный SQL запрос.
Да нужно просто сразу сказать, что в MFC поддержки программирования с СУБД
просто нет. То лихое поделие, что
туда вставили во времена 6.0 годится только для галочки в маркетинговых статьях.
AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.
Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
Например, мой лично код на MFC всегда был конфеткой...
Программируя на MFC, разработчик
AG> всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG> Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG> Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG> техническими сущностями.
Не согласен. Очень сильно не согласен.
AG>c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!
AG> Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
AG> оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!
Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.
Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.
AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
Странная логика...
Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть
позвоночник MFC. Вот это -- реально очень плохо и негибко.
AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View 
Ну... Не прав на 100%.
AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.
AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это не Observer
Observer -- это как раз Doc/View ...
А это -- реализация контроллеров в MVC, которые везде, во всех системах теперь отмирают за ненадобностью.
И это -- очень хорошее , декларативное решение. Например, в QT такого нет, точнее тоже есть, но оно там
спрятано из кода вообще.
AG> Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++
AG> Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
AG> ... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Да объяви его как хочешь, он вытерпит....
AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет
AG> отступление от идей нормального объектно-ориентированного дизайна.
Ну и что, валидное архитектурное решение, ничего страшного. Свет клином на интерфейсах не сошёлся. В классах с COM/OLE там
наоборот интерфейсов додури.
В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но
это не интересно. MFC -- это самый что ни на есть ООП.
Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,
и ещё много чего.
AG>Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.
AG>Для более сложных проектов — очевиден выбор Qt.
AG>Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.
Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.
Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
Вот в таких условиях MFC точно пасует. Не потянет.
