Я никогда не был большим поклонником MFC, но это не совсем так. Я читал, что Microsoft должна выпустить новую версию MFC в 2010 году, и это действительно показалось мне странным - я думал, что MFC мертв (никакого намеренного намерения я действительно не сделал).
Является ли MFC для новых разработок? Если да, то какая польза? Я не мог себе представить, что это может принести пользу чему-то вроде С# (или даже просто С++ с использованием API Win32).
Существует тонна кода, использующая MFC. Я вижу, что все эти вопросы все еще используются, так как все еще используется ответ "Да". Я работаю в очень большой организации, в которой по-прежнему работают сотни людей, которые пишут в коболе. Если он когда-либо использовался на предприятии, он будет по-прежнему использоваться до тех пор, пока не будет больше оборудования для его поддержки, тогда какая-то компания заплатит кому-то за создание эмулятора, чтобы старый код все равно работал.
Военно-морской флот по-прежнему использует корабли с компьютерами с магнитными сердечниками для памяти, и я уверен, что у них есть люди, над которыми они работают. Технология после создания никогда не может быть поддержана. его небольшая часть дела Deus ex machina, где крупные организации не совсем уверены в своей системе и имеют такое основное чувство страха перед тем, как поднять предприятие на колени, у них нет желания опробовать новые технологии (BTW) мы платим IBM за лучшую поддержку усилий на OS2).
Также mfc является совершенно приемлемым решением для разработки Windows, поскольку это объектная модель, которая обертывает системный API, который в значительной степени является тем, что большинство людей выбрали из .net.
Как добавление, и поскольку этот вопрос подходит для щедрости, это цитата из MS относительно mfc в VS 11
В каждом выпуске нам необходимо сбалансировать наши инвестиции в различных областях продукта. Тем не менее, мы по-прежнему считаем, что MFC является самой полнофункциональной библиотекой для создания собственных настольных приложений. Мы полностью привержены поддержке и поддержанию МФК на высоком уровне качества. Вот краткий список некоторых проблем, которые мы исправили в MFC для Visual Studio 11:
Вот ссылка если вы хотите прочитать полный пост
Coolness не влияет на выбор технологии для новой системы. Да, если вы студент или хотите поиграть, вы выбираете то, что хотите.
Но в реальном мире каждая технология имеет свои преимущества и недостатки. Год назад одна из команд начала новый проект, было решено, что это будет сделано в MFC. Причина очень проста: им приходится многократно использовать windows api для операций низкого уровня с принтером, интернет-исследователем, а бог знает, что еще.
С# не было даже в игре, было принято решение между MFC и QT, оба имели необходимую функциональность, оба могли легко интегрировать функциональность с низким уровнем, единственное отличие состояло в том, что некоторые члены команды уже имели опыт MFC, поэтому они не пришлось тратить время и деньги на тренировки.
Предположим, что они выбирают С# и WPF:
-1 Вы должны обернуть весь собственный С++ и ASM-код в DLL (это может быть больно, а не кодирование, вы пишете обертки).
-1 Вам, вероятно, нужны две команды сейчас, одна для ui для материала winapi. Очень маловероятно, что вы найдете много людей, умеющих писать как С#, так и winapi. Согласились, что в любом случае вам нужен кто-то, чтобы сделать интерфейс довольно (программисты обычно сосать на это, и они стоят дороже), но, по крайней мере, с С++ только кодом, больше нет времени ожидания между двумя командами, нужна модификация ui, никаких проблем я не делаю "Надо ждать дизайнера ui, он сделает это довольно позднее.
+1 Вы можете написать код UI в С# и WPF, скажем, что разработка пользовательского интерфейса выполняется быстрее, но пользовательский интерфейс составляет только 1/4 от проекта, поэтому общий выигрыш, вероятно, очень мал.
-1 Снижение производительности: для каждой небольшой операции, которую вы не можете сделать в С#, вы вызываете внешнюю DLL (это небольшая проблема, поскольку программа работает на четырехъядерных ядрах 8 ГБ).
Итак, в заключение: MFC по-прежнему используется для новой разработки, потому что требования и затраты определяют технологию для проекта, и только так случается, что MFC является лучшим в некоторых случаях.
MFC по-прежнему используется для какой-то новой разработки, а также для разработки технического обслуживания (в том числе внутри Microsoft).
Хотя это может быть медленнее, чем использование Win32 API напрямую, потеря производительности на самом деле крошечная - редко целых процентов. Используя .NET, потеря производительности значительно выше (в моем тестировании, редко менее 10%, при типичном 20-30%, и еще выше для тяжелых вычислений. Например, у меня есть программа, которая вычисляет Eigenvector/Eigenvalue на довольно больших массивах. Моя первоначальная версия с использованием С++ и MFC запускает один тестовый пример всего за минуту на нашей стандартной тестовой машине. Некоторые из моих коллег решили, что было бы здорово повторить ее реализацию на С#. Их версия занимает почти три минуты на той же машине (четырехъядерный процессор, 16-гигабайт оперативной памяти, так что нет, а не "устаревшее" оборудование). Я признаю, что я не слишком внимательно смотрел на их код, так что, возможно, это можно улучшить, но они приличные кодеры, поэтому улучшение 3: 1 кажется мне маловероятным.
С MFC также легко обойти фреймворк и использовать Win32 API напрямую, когда/если вы хотите. С .NET вы можете использовать P/Invoke для этого, но это довольно болезненно при сравнении.
MFC обновляется с каждой версией Visual Studio. Это просто не элемент заголовка.
Что касается новой разработки, да. Он по-прежнему используется и будет оставаться таким (хотя я, как и вы, предпочитаю не делать этого). Многие организации приняли решение о технологиях несколько лет назад и не имеют причин для изменения.
Я действительно думаю, что вы говорите о хорошо зарекомендовавших себя магазинах, хотя люди с большим интересом держат/усиливают то, что было написано, а не остаются на переднем крае.
Выпуск MFC Feature Pack (один или два года назад, iirc) был самым большим расширением MFC с 10 лет, и это дал новый импульс развитию MFC. Думаю, многие компании решили сохранить свои устаревшие приложения, подтолкнуть их вперед и развить новые приложения на его основе.
Для меня (как для тех, кто должен поддерживать большое приложение MFC), большая проблема заключается в уменьшении разработки и поддержки компонентов (Microsoft и сторонних), а не самой MFC. Например, перенос на 64-разрядный нелегкий, если в приложении собрано много старых и неподдерживаемых чистых 32-битных компонентов Active-X.
Есть преимущества избегать управляемого кода (возможно, вы пишете пользовательский интерфейс драйвера или выполняете COM).
То и там тонны кода MFC. Возможно, вы работаете в компании X, и вам нужно использовать одну из библиотек DLL, которые они пишут за последние десять лет.
В прошлом году я сделал проект на основе MFC. Я не уверен, почему MFC был выбран, но он был достаточным для создания виртуального 3D-графического пользовательского интерфейса - системы безопасности управления зданием - с частотой обновления 10 кадров в секунду, эффективно работающей на компьютерах на базе win32, относящихся к середине 1990-х годов, Исполняемый файл (который требует только базовые системные DLL файлы win32) составляет менее 400 КБ - нелегкое достижение с использованием современных инструментов.