Мысли об MFC
От: AlexGin Беларусь  
Дата: 28.04.17 17:04
Оценка: 3 (2) +5
Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире
Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
Автор: MasterZiv
Дата: 27.04.17
— я обещал товарищу MasterZiv вернуться к теме
обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).

Я начал заниматься на MFC в 1999 году. Точнее скажу, что это была первая освоенная мной библиотека классов.
После неё было: Borland C++ Builder (VCL); .NET (C#) и, наконец, Qt. Посему — вроде как есть с чем сравнить.
Впрочем — сравнивать C# и MFC как-то нелогично (разные базовые языки), поэтому оставим только то, что на C++
Попутно замечу, что для некоторых проектов я применяю MFC и на сегодняшний день.

ДОСТОИНСТВА:
1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
надстройка над WIN API, то она весит совсем не много. По современным меркам — практически ничего.

2) Интуитивная ясность библиотеки MFC для разработчиков, владеющих WIN API. Библиотека классов MFC представляет
набор классов и методов для тех сущностей, которые составляют основу оконного интерфейса Windows, что упрощает
понимание сущностей, определенных в библиотеке MFC.

3) Большой объем наработок — как в интернете (codeguru, codeproject и т.д.), так и в старых репозиториях разработчиков,
посему — возможность быстро получить ответ (в т.ч. и здесь — на КЫВТе) по самым различным аспектам применения.

4) За счёт простоты, благодаря наличию исходников и уже указанным наработкам — большая кастомизируемость
(возможность сделать то, что хочет левая пятка Заказчика).

5) Следует отметить, что MFC развивается (правда экстенсивно) — MFC Feature Pack позволает разрабатывать
приложения с довольно современным GUI. Тот факт, что в оставку MSVC2015 вернули MBCS — Multi Byte Character Set
(которую уже выбросили из MSVC2013) — также несомненно свидетельствует о некоторой популярности MFC в наши дни.

НЕДОСТАТКИ (как всегда — обратная сторона достоинств):
a) Достаточно простые на сегодняшний день вещи, оказывается сделать совсем не просто. Конечно, если работал с MFC
долгие годы, то выход найдёшь. Но это уже совсем другая история
Так, например, ComboBox в составе тулбара: в Qt несколько строк; на MFC — куча кода
Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt
имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
выполнить совсем не сложный SQL запрос.

b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC. Программируя на MFC, разработчик
всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
техническими сущностями.

c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!
Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах —
напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.
Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++
Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет
отступление от идей нормального объектно-ориентированного дизайна.

Я прекрасно понимаю, что есть требования совместимости со старым кодом, но ведь могли же ввести, наряду с поддержкой старого, и какие-либо
новые варианты — соответствующие сегодняшнему уровню развития технологий...
Или же M$ уже собралась хоронить MFC

Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.
Нередко это просто диалоговое окно со статически прилинкованной библиотекой MFC.
Для более сложных проектов — очевиден выбор Qt.
Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.

Благодарю всех, у кого хватило терпения дочитать до этой строчки!
И еще более благодарю тех, кто выразит свои мысли по данному поводу!
Отредактировано 28.04.2017 17:51 AlexGin . Предыдущая версия . Еще …
Отредактировано 28.04.2017 17:43 AlexGin . Предыдущая версия .
Отредактировано 28.04.2017 17:10 AlexGin . Предыдущая версия .
Re: Мысли об MFC
От: sergey2b ЮАР  
Дата: 28.04.17 17:58
Оценка:
Здравствуйте, AlexGin, Вы писали:

Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI
Re[2]: Мысли об MFC
От: Stanislav V. Zudin Россия  
Дата: 28.04.17 19:03
Оценка: 8 (1) +3
Здравствуйте, sergey2b, Вы писали:

S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI


В своё время неплохой была книжка Д.Круглински. Piter Press издавало её на русском.
Сейчас может чего-то новое появилось.
За исключением версии Студии и "нового" Feature Pack книжка по-прежнему актуальна.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 28.04.17 20:07
Оценка: 12 (2)
Здравствуйте, sergey2b, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:


S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI


Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них:
1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов
2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную)
3) Кейт Грегори — Использование Visual C++ 6
Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.
Re[2]: Мысли об MFC
От: bnk Австрия http://unmanagedvisio.com/
Дата: 28.04.17 21:20
Оценка: +1
Здравствуйте, sergey2b, Вы писали:

S> сейчас впервый разв в жизни стал использовать MFC для GUI


Нелегко тебе однако. Йоханнесбург?
Re[3]: Мысли об MFC
От: sergey2b ЮАР  
Дата: 28.04.17 22:18
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Здравствуйте, sergey2b, Вы писали:


S>> сейчас впервый разв в жизни стал использовать MFC для GUI


bnk>Нелегко тебе однако. Йоханнесбург?


я уехал оттуда в 11 году
нет США
Re[4]: Мысли об MFC
От: bnk Австрия http://unmanagedvisio.com/
Дата: 28.04.17 22:28
Оценка: 4 (1)
Здравствуйте, sergey2b, Вы писали:

bnk>>Нелегко тебе однако. Йоханнесбург?


S>нет США


Кто-то тут недавно, кажется, об отсталости/закостенелости Америки говорил? Вот, еще один наглядный пример

По сути, — я присоединюсь к Круглински.
Если до этого вообще дела с ужасом, летящим на крыльях ночи MFC, не имел, можешь firststeps.ru глянуть
Re[3]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 29.04.17 05:12
Оценка:
Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>В своё время неплохой была книжка Д.Круглински. Piter Press издавало её на русском.

+100500
Да, это была очень классная книга!
Где-то у меня она ещё есть, изданая на русском в Питер-пресс.

SVZ>Сейчас может чего-то новое появилось.

К сожалению, теперь ничего по MFC нового нет

SVZ>За исключением версии Студии и "нового" Feature Pack книжка по-прежнему актуальна.

Ну Feature Pack — я изучал по интернету (гуглением) лет пять назад.
Вот неплохие ресурсы:
http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm
https://www.codeproject.com/Articles/217588/Porting-a-legacy-MFC-app-to-MFC-Feature-Pack
http://ntcoder.com/bab/tutorial_mfc_feature_pack1_part1
Кроме того, помогает простое гугление по названию функции/метода/имени_класса — по Feature Pack инфы не так много,
как п оклассическому MFC, но при желани — найти можно.
Да и сайт MSDN — в качестве справочника по классам и их методам.
Отредактировано 29.04.2017 5:16 AlexGin . Предыдущая версия .
Re[3]: Мысли об MFC
От: rumit7  
Дата: 29.04.17 07:24
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них:

AG>1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов
AG>2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную)
AG>3) Кейт Грегори — Использование Visual C++ 6
AG>Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.

если не найдутся, у моего друга вроде как были, скину если надо будет
Re[4]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 29.04.17 07:41
Оценка:
Здравствуйте, rumit7, Вы писали:

R>если не найдутся, у моего друга вроде как были, скину если надо будет

Спасибо, уважаемый rumit7, у меня всё по MFC есть
Это спрашивал sergey2b, у которого возникла необходимость в изучении MFC.
Re: Мысли об MFC
От: Evgeniy Skvortsov Россия  
Дата: 29.04.17 18:17
Оценка: 10 (2)
Здравствуйте, AlexGin, Вы писали:

AG>И еще более благодарю тех, кто выразит свои мысли по данному поводу!


К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.
Так же хорошая поддержка COM.
Ну и мне всегда нравился класс CSocket для простеньких сетевых приложений. Для сложных вещей конечно этот класс использовать не надо.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 30.04.17 18:26
Оценка: 1 (1)
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.

+100500
Это, конечно несомненно так, студия много чего (в плане заготовок для новых приложений) умеет сделать сама.
Мне часто кажется, что M$ снабдила свою студию таким набором визардов для MFC, для того,
чтобы скрыть все непрстые особонности применения дянной библиотеки. Типа: "а у на это — прямо из коробки, и вот это, и вот то..." —
в общем некоторое решение, может даже неплохое, чтобы как-то компенсировать разбухание прикладного C++ кода.

ES>Так же хорошая поддержка COM.

Да, COM — хорошая штука, но на уровне современных решений это довольно сложная вещица.
На сегодняшний день востребованы более простые для прикладного применения решения.
Re: Мысли об MFC
От: MasterZiv СССР  
Дата: 03.05.17 12:47
Оценка:
Здравствуйте, 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 точно пасует. Не потянет.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 03.05.17 16:46
Оценка:
Здравствуйте, уважаемый MasterZiv, Вы писали:

MZ>Ну, тогда не могу не поучаствовать в топике

Рад приветствовать, уважаемый MasterZiv

AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)


MZ>Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не

MZ>понимают. Для многих MFC -- это огромный и страшный монстр.
Стараюсь быть объективным. Это скорее маленькая рабочая лошадка

AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.

MZ>Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
MZ>Например, мой лично код на MFC всегда был конфеткой...

Всё дело в том, что на MFC очень много чего лишнего приходится делать руками.
Пример: ProgressBar или ComboBox в составе ToolBar-a головного окна (для проекта MFC Feature Pack) — для MFC куча всякого кода,
дополнительные классы с переопределёнными вирт-методами и т.д.
То же самое для Qt — несколько скромных (весьма простых) строчек кода.
Замечу, что здесь не следует воспринимать что-либо как обиду (не наезжаю я на твой код), просто констатирую очевидный факт для MFC.
И мой, и твой, и самого господина Гейтса код на MFC, будет обладать всеми особенностами того, чем обладает любой мфц-шный проект.

AG>Программируя на MFC, разработчик

AG>всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG>Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG>Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG>техническими сущностями.
MZ>Не согласен. Очень сильно не согласен.

Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.
А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь
автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").

Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.
Они уходят корнями туда, даже в тех случаях, когда вроде как нет аналогичной глобальной апи-шной функции (абсолютного аналога).
Да, для конца 1990-х и начала 2000-х это было шикарно. Однако, на сегодняшний день это уже не так.

AG> Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками

AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

MZ>Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.

Организация 'виджетов' в Qt кардинально отличается от WinAPI — отсюда ИМХО и "ноги растут".

MZ>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.

Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>Странная логика...
Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции), при этом он не связан с каким либо паттерном проектирования — он
просто представляет собой атавизм, актуальный разве что для текстовых редакторов
Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?
Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...

MZ>Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть

MZ>позвоночник MFC. Вот это -- реально очень плохо и негибко.
MDI иногда позволяет решить проблему, а иногда создаёт проблемы. Здесь всё зависит от проекта.

AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.

AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP

MZ>Это не Observer

Просто одна из его (не весьма удачных) реализаций. Скажу так — Observer, но изуродованный до полной неузнаваемости

MZ>Observer -- это как раз Doc/View...

Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.
Во всяком случае, этот Observer подобен "Демьяновой ухе" — его навязывают практически без необходимости.

AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет

AG> отступление от идей нормального объектно-ориентированного дизайна.

MZ>В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но

MZ>это не интересно. MFC -- это самый что ни на есть ООП.

Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.
Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

MZ>Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,

MZ>и ещё много чего.
+100500
Похоже, что MFC появился до внедрения STL — вот и объяснение.

MZ>Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.


Ну давай смотреть, какие есть альтернативы и для чего:
1) .NET:
1.1. WindowsForms;
1.2. WPF;
2) Qt (здесь как под-вариант QML);
3) Java (да, несколько не нативно, но тем не менее).
MZ>Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
В определенной нише — много (даже очень много) кто хочет!
MZ>Вот в таких условиях MFC точно пасует. Не потянет.
Конечно же, документооборот теперь почти весь на Web-е (что-то есть на .NET-е и что-то на Java).
Львиная доля современных технических desktop проектов — на Qt.

P.S. На сегодня desktop — это и управление IoT системами, и научные расчёты, и индустрия развлечений.

В общем — дискуссии нашей пора в КСВ
Отредактировано 03.05.2017 20:48 AlexGin . Предыдущая версия . Еще …
Отредактировано 03.05.2017 20:43 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:23 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:16 AlexGin . Предыдущая версия .
Отредактировано 03.05.2017 17:04 AlexGin . Предыдущая версия .
Re[3]: Мысли об MFC
От: MasterZiv СССР  
Дата: 04.05.17 06:01
Оценка: +1
Здравствуйте, AlexGin, Вы писали:


AG>Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.


Ну так там концепция другая, там published — свойства объектов, и объекты из сохранённых образов объектной системы восстанавливаются.


AG>А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь

AG>автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").

.ui файлы там. По сути тоже аналог того решения, что сделано в WinFOrms.
Да, это вынесено из исходного кода, но зато если нужно что-то массово подправить -- сложнее.
Если не хочешь пользоваться визардами и средствами проектирования UI -- тоже сложнее, хотя не намного.
Но в целом, так на так и выходит, есть и плюсы, и минусы. Сравнивать это вряд ли можно, слишком разные решения.


AG>Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.


Да ладно, ну совсем никак не связано. Совершенно новая концепция именно в MFC для связи контролов WinAPI с контролами
формы и для связи данных из диалога с данными в форме на MFC/C++.
Где ты там корни WinAPI увидел -- сложно понять...
Ращве что только что это код, а не данные, хотя если абстрагироваться, можно DDX не воспринимать как код, а
воспринимать как специальный декларативный DSL, призваный описать какие-то аспекты работы формы. В принципе
в идеале он и должен быть таким, чисто декларативным.



MZ>>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.

AG>Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой
Ну ты же не будешь переделывать сразу все 50 проектов... По одному,

AG>>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>>Странная логика...
AG>Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC

Ну-ну. С каого это совсем другое? Это оно и есть, MVC, Subject/Observer, классика из GoF.
Совершенно разные реализации и подходы, это да, в MVC идея взята в более чистом виде, в QT сделали
много стандартных повторноиспользуемых моделей данных, список, таблица и таблица с иерархией.
(мне кстати не очень нравится, достаточно неуклюже сделано, чистого Subject/Observer нет вообще).

AG>Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции),


Нет, не навязан он всегда, есть Dialog based приложения.

Ну да, он немного более сильно чем нужно встроен в ядро MFC, это да, и я про это уже писал.
В том числе несчастный MDI.

AG>при этом он не связан с каким либо паттерном проектирования — он

AG>просто представляет собой атавизм, актуальный разве что для текстовых редакторов
AG>Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
AG>в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

Я ещё раз говорю, у тебя странная логика. Одно и то же решение, один и тот же паттерн тебе в одном случае нравится, принимается
за инновацию, в другом случае кажется архаичным и неправильным. И это при том, что в MFC Doc/View был с самого начала, с 90-ы, а
в QT появился только в 21 веке, потому что ну видимо все уже разработчики тыкали их носом в какашки и ругались, а где же у вас
Doc/View или MVC.

AG>Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?

AG>Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
AG>В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...

MFC и WinForms были сделаны для разных целей. MFC -- для создания Word-ов и Excel-ей, WInFOrms -- на замену VisualBasic, для создания корпоративных
приложений, состоящих в основном из таких концепций UI, как "форма". Ну, не нужны там Doc/View.

(для того же -- убить VisualBasic- создавалась и Delphi, автор идеи которой делал и WinFOrms).


AG>Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.


Без натяжек, это он и есть.

AG>Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.

AG>Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

Кто тебе сказал, что .net -- это образцовый ООП?
Кто тебе сказал, что современный C++ -- это ООП (только ООП)?

AG>Похоже, что MFC появился до внедрения STL — вот и объяснение.


Он появился задолго даже до момента появления мысли о STL.



AG>В общем — дискуссии нашей пора в КСВ


Re: Мысли об MFC
От: qaz77  
Дата: 04.05.17 10:38
Оценка: +2
Здравствуйте, AlexGin, Вы писали:

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

Вот здесь не соглашусь.
Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Это и в MDI работало, и в SDI.

Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.

Сам я в Doc/View от MFC много толку не вижу.
Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Мне всегда было проще свой Model/View замутить.
Re[2]: Мысли об MFC
От: AlexGin Беларусь  
Дата: 04.05.17 11:56
Оценка:
Здравствуйте, qaz77, Вы писали:

Q>Здравствуйте, AlexGin, Вы писали:


AG>d) Архаичная архитектура Doc/View (Документ/Вид)

AG> Это усложнение, которое просто приходится обходить в современных проектах -
AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

Q>Вот здесь не соглашусь.

Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
m_pPhoneBookTemplate = new CMultiDocTemplate(IDR_PhoneBookTYPE,
        RUNTIME_CLASS(CPhoneBookDoc),
        RUNTIME_CLASS(CChildFrame), // настраиваемая дочерняя рамка MDI
        RUNTIME_CLASS(CPhoneBookView));
    if (!m_pPhoneBookTemplate)
        return FALSE;
    AddDocTemplate(m_pPhoneBookTemplate);

Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти, увы, не так-то просто (когда-то я экспериментировал с этим).
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти фундаментальную архитектуру Doc/View

Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).

Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
 virtual BOOL SaveModified( );

переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View

Q>Сам я в Doc/View от MFC много толку не вижу.

+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков.
Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Отредактировано 04.05.2017 12:27 AlexGin . Предыдущая версия . Еще …
Отредактировано 04.05.2017 12:01 AlexGin . Предыдущая версия .
Отредактировано 04.05.2017 12:01 AlexGin . Предыдущая версия .
Re[3]: Мысли об MFC
От: qaz77  
Дата: 04.05.17 15:06
Оценка: +1
Здравствуйте, AlexGin, Вы писали:
AG>Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?

Ну вот работает — и все.
Сейчас под рукой MSVC 2013, делаем New project->MFC->MFC Application.
Там же, где выбирается MDI/SDI/Dialog based, есть опция "Document/View architecture support".
Если галочку снимаем, то никакие шаблоны документов и проч. не генерируются, ни в InitInstance, ни где-то еще.
ChildView делается просто наследником CWnd.

AG>Ещё интересная фича:

AG>
AG> virtual BOOL SaveModified( );
AG>

AG>переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.

"Сохранить документ" — это то же файлами отдает. А если у нас БД или просто на лету куда-то пишется?
К тому же есть простая альтернатива — return из OnClose окна-рамки до вызова родительской реализации.
Re[2]: Мысли об MFC
От: qaz77  
Дата: 05.05.17 07:09
Оценка:
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.


К сожалению, в современных версиях студии добавление чего-либо в исходники с помощью визардов сильно испортили.
Раньше добавлялись метки //{{AFX_... для вставки в строго отведенные места.
Сейчас такие метки не добавляются, все лепится в конец.

С namespace это добро никогда нормально не работало.
Определения функций-членов лепились за закрывающей скобкой namespace и приходилось руками переносить.

Крайне неудобно добавлять файлы (визард Add class), если файл проекта лежит не в корне папки с исходниками.
Файлы всегда норовят создаваться рядом с файлом проекта.
Для мня это актуально, т.к. одноименные .vcproj под разные версии студии лежат в подпапках.

Не много не в тему. Наболело про редактор ресурсов.
Редактирование таблицы строк в новых студиях — это просто песня. В VC6 был вполне удобный.
Импорт ресурса из файла, например иконки, добавляет в проект "res/my_icon.ico" и "../res/my_icon.ico".

Вывод такой.
В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку.
Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями.
В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.
Re[3]: Мысли об MFC
От: MasterZiv СССР  
Дата: 05.05.17 08:41
Оценка: +1
Здравствуйте, qaz77, Вы писали:

Q>В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку.

Q>Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями.
Q>В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.


MSVC 6.0 вообще была лучшей версией студии. Начиная со следующей (2000+) её переписали на формсах,
и всё испортили (IMHO).
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.