Сообщение Re[2]: Мысли об MFC от 03.05.2017 16:46
Изменено 03.05.2017 20:48 AlexGin
Re[2]: Мысли об MFC
Здравствуйте, уважаемый 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? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром".
Насчёт 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 системами, и научные расчёты, и индустрия развлечений.
В общем — дискуссии нашей пора в КСВ
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? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром".
Насчёт 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 системами, и научные расчёты, и индустрия развлечений.
В общем — дискуссии нашей пора в КСВ
Re[2]: Мысли об MFC
Здравствуйте, уважаемый 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 системами, и научные расчёты, и индустрия развлечений.
В общем — дискуссии нашей пора в КСВ
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 системами, и научные расчёты, и индустрия развлечений.
В общем — дискуссии нашей пора в КСВ