«Никто не должен больше использовать MFC» Почему?

Question

Правда ли, что "никто больше не должен использовать MFC"

А почему это так?

Answer 1

Возможно, никто не должен когда-либо использовать MFC (говоря, как кто-то, кто подвергся его воздействию после MFC 1.0). Всегда были лучшие технологии для разработки графического интерфейса, от SQL-окон Gupta и Delphi Борланда до Microsoft Visual Basic. И в настоящее время у нас есть .NET или, возможно, более похожий на MFC, Qt.

Сам MFC представлял собой серию хаков и часто преднамеренных злоупотреблений языком C ++. Конечно, если у вас большой проект MFC, вы, вероятно, застряли с ним.

Answer 2

Нет, это не правда. Подобные заявления всегда неверны, потому что для каждого проекта и каждой ситуации вам нужно снова оценивать библиотеки и языки. И просто отбрасывать MFC без веской причины неправильно.

Несмотря на то, что MFC существует уже много лет, и многие люди больше не хотят использовать его для новых проектов, он все же может быть лучшим выбором в зависимости от проекта. Да, .NET и его пользовательские интерфейсы в большинстве случаев являются лучшим выбором для новых проектов сегодня. Но если вам требуется небольшой объем памяти, очень быстрое время запуска или ваше приложение должно работать на очень ограниченных компьютерах, MFC по-прежнему может быть хорошим выбором.

Например, нетбуки (или как вы хотите их называть) популярны, и не на всех из них установлена ​​платформа .NET. А тем, у кого только 512 МБ-1 ГБ ОЗУ, вы можете не захотеть, чтобы ваше приложение использовало эту платформу.

И, конечно, помимо MFC есть и другие библиотеки, отличные от .NET, которые вы можете использовать. Но MFC по-прежнему хороший выбор.

Answer 3

Это просто старая технология: есть новые, более блестящие технологии, которые намного проще в использовании ...

Answer 4

Немного трудно найти вескую причину, по которой новый проект будет использовать MFC / C ++ ... , если - это технология, которую знает команда разработчиков. Команда, имеющая опыт работы в C ++ и MFC, которая активно работает с .NET / WPF в новом проекте, потеряет много времени.

Джоэл написал хорошую статью на этом пути назад (я думаю), но я не могу ее найти. По сути, вам нужна бизнес-причина для переключения технологий. «Это старо и некрасиво, и мы хотим быть крутыми с WPF» - это не бизнес-причина.

Answer 5

Иногда я чувствую себя немного похожим на Пола Баньяна в том смысле, что я размахиваю топором MFC и срубаю много деревьев только для того, чтобы увидеть, как появляются эти новые цепные бензопилы. Все говорят, насколько лучше бензопила, поэтому я учусь пользоваться бензопилой, и я начинаю вырубать эти деревья, а затем появляется валочно-пакетирующая машина , и все говорят, насколько лучше валочно-пакетирующая машина Так что я учусь использовать валочно-пакетирующую машину и вырубаю больше деревьев.

Я не говорю, что AX лучше, чем валочно-пакетирующая машина - это не так, но если у вас уже есть топор, и вы уже знаете, как использовать топор, и все, что вам нужно сделать, это срубить дерево ...

Иногда дьявол, которого вы знаете, лучше, чем тот, кого вы не знаете.

FWIW - почти весь Windows SDK основан на макросе; это почти как #ifdef и #define - сам по себе язык разработки.

Answer 6

Если вы смотрите доклад Project Centennial из Build 2015, он показывает, что Adobe все еще использует MFC в своих продуктах Adobe. Они используют mfc100 из VS2010 для создания приложения UWP из компонентов Win32 / COM / MFC, поэтому MFC все еще используется.

Пока Microsoft не предоставит платформу пользовательского интерфейса C ++ с элементами пользовательского интерфейса, в которых настольные приложения используют ленты / панели инструментов / меню / диалоги и т. Д., MFC может оставаться популярным даже со всеми его причудливыми битами.