Информация об изменениях

Сообщение Re[4]: Мысли об MFC от 21.05.2017 17:09

Изменено 21.05.2017 17:17 AlexGin

Re[4]: Мысли об MFC
Здравствуйте, Went, Вы писали:

W>Я бы не сказал, что избыточность библиотеки для некоторого класса задач делает ее плохой. Основная проблема MFC (если не брать ее неактуальное состояние), это излишняя "прибитость гвоздями" к некоторым концепциям. Например, документ жестко завязан на то, что он будет храниться в файле. Когда нужно сделать некоторый "абстрактный" документ, начинаются "сопли". Фрейм завязан на то, чтобы хранить "вид", который завязан на то, чтобы отображать именно "документ". Все это можно обходить, но обходится не очень красиво.

+100500
Это именно то, о чем шла речь в первоначальном моём сообщении.
Отсутствие гибкости, при избыточности — это то, что можно именовать как "прибитость гвоздями" к некоторым концепциям

AG>>Однако, все приличные современные приложения обычно MDI + Dockable (в плане GUI).

W>У меня на MFC именно такое приложение, полет нормальный. Выглядит довольно современно. И панели докаются, и ribbon, и диспетчер свойств. Жизнь портит только некоторая "сырость" Feature Pack-а.
У меня также есть приложения такого рода, с MDI + Dockable с применением MFC Feature Pack (ранее известный как BCG Library).
Вопрос ведь совсем не в этом. Ведь никто не утрерждает что это не возможно
Однако, никто и не собирается спорить, о том что это в MFC + (MFC Feature Pack) делается с большим оверхедом.
Этот оверхед имеет место на уровне кодов проекта, а не на уровне каких-то дополнительных (технических, автогенерируемых) файлов.

AG>>Точнее — осталось только, пожалуй, Dialog Based, как вариант с минимальным оверхедом

W>Не соглашусь. См п.1. — приложения-редакторы пишутся на MFC довольно удобно.
Какова актуальность очередного велосипеда редактора в 2017-ом?

AG>>Всё остальное на C++ имеет смысл разрабатывать используя Qt.

W>Ну зачем мне QT для разработки windows-vs-only редактора?
Вот в том-то и дело, что на уровне кодов проекта, даже тот же самый редактор (например текстов) сделанный на Qt,
окажется более компактным и читабельным, чем его собрат от MFC.
Да, в Qt будут автоматически сгенерированные файлы, но сложности проекта это НЕ ДОБАВИТ, так как это является
отдельной технической сущностью, которая "живёт" не в кодах проекта. Прикладному программисту эта сущность не осложняет жизнь, для него она вообще практически не заметна (она существует где-то "за кадром").
Re[4]: Мысли об MFC
Здравствуйте, Went, Вы писали:

W>Я бы не сказал, что избыточность библиотеки для некоторого класса задач делает ее плохой. Основная проблема MFC (если не брать ее неактуальное состояние), это излишняя "прибитость гвоздями" к некоторым концепциям. Например, документ жестко завязан на то, что он будет храниться в файле. Когда нужно сделать некоторый "абстрактный" документ, начинаются "сопли". Фрейм завязан на то, чтобы хранить "вид", который завязан на то, чтобы отображать именно "документ". Все это можно обходить, но обходится не очень красиво.

+100500
Это именно то, о чем шла речь в первоначальном моём сообщении.
Отсутствие гибкости, при избыточности — это то, что можно именовать как "прибитость гвоздями" к некоторым концепциям

AG>>Однако, все приличные современные приложения обычно MDI + Dockable (в плане GUI).

W>У меня на MFC именно такое приложение, полет нормальный. Выглядит довольно современно. И панели докаются, и ribbon, и диспетчер свойств. Жизнь портит только некоторая "сырость" Feature Pack-а.
У меня также есть приложения такого рода, с MDI + Dockable с применением MFC Feature Pack (ранее известный как BCG Library).
Вопрос ведь совсем не в этом. Ведь никто не утверждает здесь, что это не возможно
Однако, никто и не собирается спорить, о том что всё вышеуказанное в MFC + (MFC Feature Pack) делается с большим оверхедом.
Этот оверхед имеет место на уровне кодов проекта, а не на уровне каких-то дополнительных (технических, автогенерируемых) файлов.

AG>>Точнее — осталось только, пожалуй, Dialog Based, как вариант с минимальным оверхедом

W>Не соглашусь. См п.1. — приложения-редакторы пишутся на MFC довольно удобно.
Какова актуальность очередного велосипеда редактора в 2017-ом?
Конечно же, когда MFC появился, подобная актуальность была значительно выше.

AG>>Всё остальное на C++ имеет смысл разрабатывать используя Qt.

W>Ну зачем мне QT для разработки windows-vs-only редактора?
Вот в том-то и дело, что на уровне кодов проекта, даже тот же самый редактор (например текстов) сделанный на Qt, окажется более компактным и читабельным, чем его же собрат от MFC.
Да, в Qt будут автоматически сгенерированные файлы, но сложности проекта это НЕ ДОБАВИТ, так как это является отдельной технической сущностью, которая "живёт" не в кодах проекта. Прикладному программисту эта сущность не осложняет жизнь, для него она вообще практически не заметна (она существует где-то "за кадром").

P.S. Совсем не хочу умалять значимости MFC в мире IT!
При помощи MFC сделано немало хороших проектов.
К некоторым из них, я имел честь приложить мозги и руки
Однако, на сегодня MFC не выглядит таким инновационным как 15 лет назад