MFC все еще используется для новых разработок (с любым объемом материала)?

Question

Я никогда не был большим поклонником MFC, но это не совсем так. Я читал, что Microsoft должна выпустить новую версию MFC в 2010 году, и это действительно показалось мне странным - я думал, что MFC мертв (без злого умысла, правда).

Используется ли MFC для новых разработок? Если да, то в чем выгода? Я не мог себе представить, что это имеет какую-то выгоду над чем-то вроде C # (или даже просто c ++ с использованием Win32 API в этом отношении).

Answer 1

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

Военно-морской флот все еще использует корабли с компьютерами с магнитными сердечниками для памяти, и я уверен, что у них есть люди, чтобы работать над ними. Однажды созданные технологии никогда не могут быть поддержаны. Это немного похоже на случай Deus ex machina, где крупные организации не совсем уверены в том, что делает их система, и испытывают такое сильное чувство страха, что могут поставить предприятие на колени, у них нет желания опробовать ваши новые запутанные технологии (КСТАТИ) мы платим IBM за максимальную поддержку OS2).

Кроме того, mfc является вполне приемлемым решением для разработки Windows, поскольку это объектная модель, которая обертывает системный API, который является практически всем, что большинство людей получают из .net.

---

В качестве дополнения, и поскольку этот вопрос стоит за награду, это цитата из MS относительно mfc в VS 11

В каждом выпуске нам необходимо балансировать наши инвестиции в различных областях продукта. Тем не менее, мы по-прежнему считаем, что MFC является наиболее полнофункциональной библиотекой для создания собственных настольных приложений. Мы полностью привержены поддержке и поддержанию MFC на высоком уровне качества. Вот краткий список некоторых проблем, которые мы исправили в MFC для Visual Studio 11:

Вот ссылка , если вы хотите прочитать полный пост

Answer 2

Прохлада не влияет на выбор технологии для новой системы. Да, если вы студент или хотите поиграть, выбирайте все, что хотите.

Но в реальном мире каждая технология имеет свои преимущества и недостатки. Год назад одна из команд запустила новый проект, было решено, что это будет сделано в МФЦ. Причина очень проста: им приходится много использовать windows api для низкоуровневых операций с принтером, Internet Explorer, и бог знает, что еще.

C # даже не было в игре, решение было принято между MFC и QT, оба обладали необходимой функциональностью, оба могли легко интегрировать функциональность низкого уровня, единственное отличие заключалось в том, что некоторые члены команды уже имели опыт работы с MFC, поэтому они не пришлось тратить время и деньги на тренировки.

Предположим, они выбрали C # и WPF:
-1 Вы должны обернуть весь нативный код C ++ и ASM в DLL (это может быть болезненно, вместо того, чтобы писать код, вы пишете обертки).
-1 Тебе, наверное, сейчас нужны две команды, одна для пользовательского интерфейса, другая для виннапи. Маловероятно, что вы найдете много людей, способных писать как на C #, так и на winapi. Согласились, что в любом случае вам нужен кто-то, чтобы сделать интерфейс красивым (программисты обычно сосут на это, и они стоят дороже), но, по крайней мере, с кодом только на C ++, больше нет времени ожидания между двумя командами, нужна модификация пользовательского интерфейса, нет проблем, я не надеваю Не нужно ждать дизайнера пользовательского интерфейса, он сделает это довольно поздно.
+1 Вы можете написать код пользовательского интерфейса в C # и WPF, скажем, разработка пользовательского интерфейса происходит быстрее, но пользовательский интерфейс составляет всего 1/4 проекта, поэтому общий выигрыш, вероятно, очень мал.
-1 Снижение производительности: для каждой маленькой операции, которую вы не можете выполнить в C #, вы вызываете внешнюю DLL (это незначительная проблема, поскольку программа работает на 8 ГБ четырехъядерных ОЗУ).

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

Answer 3

MFC все еще используется для некоторых новых разработок, а также для развития технического обслуживания (в том числе внутри Microsoft).

Хотя это может быть поминутнее медленнее, чем при использовании Win32 API напрямую, потеря производительности на самом деле незначительна - редко достигает целого процента. При использовании .NET потеря производительности на значительно * на 1006 * больше (в моем тестировании редко бывает менее 10%, с типичными 20-30% и еще выше для тяжелых вычислений. Например, у меня есть программа это делает вычисления Eigenvector / Eigenvalue на довольно больших массивах. Моя оригинальная версия, использующая C ++ и MFC, запускает один тестовый пример в всего за минуту на нашей стандартной тестовой машине. Некоторые из моих коллег решили, что было бы здорово - реализовать его в C #. Их версия занимает почти три минуты на одной и той же машине (четырехъядерный процессор, 16 гигабайт оперативной памяти, так что нет, не «устаревшее» оборудование). Я признаю, что я не слишком внимательно смотрел на их код так что возможно это можно улучшить, но они достойные программисты, поэтому улучшение 3: 1 кажется мне маловероятным.

С MFC также легко обойти инфраструктуру и использовать Win32 API напрямую, когда / если вы хотите. С .NET вы можете использовать для этого P / Invoke, но это весьма болезненно для сравнения.

Answer 4

Выпуск MFC Feature Pack (один или два года назад, iirc) стал крупнейшим расширением MFC примерно за 10 лет и дал совершенно новый импульс развитию MFC. Я думаю, что многие компании решили сохранить свои унаследованные приложения, продвигать их вперед и удалять новые приложения на его основе.

Для меня (как человека, который должен поддерживать большое приложение MFC) большая проблема заключается в уменьшении разработки и поддержки (Microsoft и сторонних) компонентов, а не самого MFC. Например, портировать на 64-битную версию непросто, если в приложении собрано много старых и неподдерживаемых чистых 32-битных компонентов Active-X.

Answer 5

MFC обновляется с каждым выпуском Visual Studio. Это просто не элемент заголовка.

Что касается новых разработок, то да. Он все еще используется и будет оставаться таковым (хотя я, как и вы, предпочитаю этого не делать). Многие организации приняли технологическое решение несколько лет назад, и у них нет причин для изменений.

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

Answer 6

Есть преимущества в том, чтобы держаться подальше от управляемого кода (может быть, вы пишете пользовательский интерфейс драйвера или делаете COM).

Это и есть тонн кода MFC. Возможно, вы работаете в компании X, и вам нужно использовать одну из zillion DLL, которую они написали за последние дюжину лет.

Answer 7

Я делал проект в прошлом году на основе MFC. Я не уверен, почему был выбран MFC, но его было достаточно для создания виртуального трехмерного графического пользовательского интерфейса - системы безопасности управления зданием - с частотой обновления 10 кадров в секунду, эффективно работающей на ПК на основе win32, начиная с середины 1990-х , Размер исполняемого файла (для которого требуются только основные системные DLL-библиотеки win32) менее 400 КБ - это нелегкое достижение с помощью современных инструментов.