Каковы неотразимые возможности MFC? Почему вы выбрали его для нового проекта?
Есть ли еще вопрос для MFC
Ответ 1
MFC был хорошим вариантом 10 лет назад. Это по-прежнему хорошая оболочка над Win32 API, но, к сожалению, устарела.
Trolltech QT - лучший вариант с одним большим преимуществом - он независим от платформы. С MFC вы обречены на Windows.
Ответ 2
Я все еще использую MFC для всех видов приложений. MFC получил плохой рэп от этого ранних реализаций, но теперь он отлично. Я считаю это более удобным, чем WTL. Кроме того, инструменты GUI в Visual Studio уже настроены, чтобы упростить быстрое создание графических интерфейсов с помощью MFC, управление отображением переменных, DDX и т.д.
Для настольных приложений, которые я намерен для широкого распространения, я по-прежнему работаю с собственными приложениями Windows, как правило, в MFC, потому что мы все еще не в той точке, где вы можете полагаться на своих клиентов, чтобы иметь версию .NET, я буду использовать установленный и попросить их установить его, это приведет к потере продаж, не говоря уже о головной боли обслуживания клиентов, когда они столкнутся с проблемами установки .NET в результате попыток запустить ваше приложение.
Ответ 3
Преимущество MFC заключается в том, что он по-прежнему лучше, чем кодирование, на bare win32, и вы можете распространять собственный .exe, который не требует среды исполнения 23-50Mb, например .Net.
Теперь, если вы обеспокоены этими вещами, там есть лучшие альтернативы: С++ Builder, WxWidgets и т.д. Но в некоторых местах не рассматриваются инструменты, отличные от Microsoft.
Ответ 4
Вы могли бы переформулировать вопрос, почему вы выбрали С++ над С# для настольного приложения. С++ по-прежнему предлагает преимущества скорости, которые важны для некоторых приложений (я работаю для компании, которая создает программное обеспечение для электронной торговли. Скорость имеет большое значение).
Если вы собираетесь разрабатывать настольное приложение, предназначенное для Windows только на С++, то MFC является самым зрелым выбором, с большим количеством свободного кода на основе MFC в Интернете, большого количества знаний.
Ответ 5
Помимо самого win32 api, MFC - единственная технология программирования Windows, которая все еще жива и хорошо в 2011 году после 15 лет. Еще в 2001 году все говорили: "MFC мертв, теперь все Winforms"; в 2005 году все сказали: "MFC мертв, теперь все XAML"; теперь это 2011 год, а Winforms и XAML мертвы (ОК XAML, возможно, не совсем мертв, но прошел мимо его основного), а MFC по-прежнему обновляется с последними событиями (лента, расширения Aero, API Win7 и т.д.).
Конечно, это не гарантирует ничего на будущее, но за эти 15 лет много написано кода MFC, и оно останется в использовании в течение следующего десятилетия или десятилетий. Это может быть не самая красивая технология, но она хорошо понята (ее хорошие и плохие точки) и не является движущей целью, как другие технологии шумихи, что означает, что люди, которые на самом деле хотят получить материал, могут сориентироваться на этом (более чем на альтернативы, так или иначе).
(то же самое относится к С++, btw)
Ответ 6
Здесь есть возможность - представьте себе приложение, которое потребует большой объем памяти, скажем, графическую программу, игру или, может быть, какое-то высокопроизводительное бизнес-приложение. Ни для кого не секрет, что hog-память .NET-приложений - в таком случае вам может понадобиться постное приложение MFC для ядра вашего приложения. Вы всегда можете загружать и использовать компоненты .NET, элементы управления и т.д. Через COM-коннекторы или непосредственно через С++/CLI.
Что все сказано - MFC - это боль. Вместо этого рассмотрим WTL - вы все равно можете позвонить в .NET, если вам нужно, так же, как я упоминал выше для MFC. WTL намного приятнее, чем MFC: -)
Ответ 7
По-видимому, это хороший выбор для приложений для ручных устройств на базе Windows, таких как устройства для продажи. В них ресурсы ограничены, поэтому такие вещи, как управление памятью, становятся более значительными.
Ответ 8
Быстрый просмотр новых функций MFC
Я слышал, что у них новый элемент управления лентой. Если вы занимаетесь такой сложностью. Вот скриншот недавно созданного приложения:
Действительно, это просто обновление виджета. Нужно ли нам больше виджетов?
Ответ 9
Я думаю, что нет. MFC проиграет в
- Уровень абстракции
- Время разработки
- Время устранения неполадок
- Кривая обучения для новых разработчиков
- Будущая коррекция (хотя теперь это сомнительно.. с чем-то новым, возникающим каждые 3-4 года).
- Поиск хороших людей, которые знают их MFC
- Простые в использовании элементы управления
Единственное место, где MFC, вероятно, проскользнет мимо, - это если у вас есть очень интенсивные приложения, например, у вас есть вещи на экране, которые нужно перерисовывать каждые 10 мсек или 1 секунду. "Управляемые" приложения до сих пор не смогли преодолеть это препятствие.
MFC был важным шагом в эволюции, но теперь доступны лучшие варианты.
Ответ 10
Существующий API окон полностью основан на C. Если вы хотите использовать С++ (и вы, вероятно, должны), то MFC является логическим выбором, если вы хотите остаться родным (т.е. Не использовать .NET).
MFC - это всего лишь набор объектно-ориентированных классов поверх C API. Плюс довольно много дополнительных "вспомогательных" классов, которые облегчают выполнение повседневных задач.
Ответ 11
Только по дизайну и техническим достоинствам? Извините за категоричность, но ничего. Это плохой дизайн, чрезвычайно непроницаемая абстракция, где вам приходится возвращаться к программированию API Win32, вопиюще злоупотреблять С++ и твердо ориентируется на вчерашнюю технологию: вы не получите современный (или даже привлекательный!) Пользовательский интерфейс из приложение MFC. Если вы можете получить разработчиков С# и у вас нет серьезных ограничений аппаратного обеспечения, зайдите в WinForms.
С другой стороны, внешние факторы, такие как доступность компетенции для проката, учебные программы и сторонние компоненты, могут продлить срок их службы, по крайней мере, для некоторых видов приложений: небольших и простых, предназначенных для специальных приложений с разумным несколько пользователей, предпочтительно внутри компании.
Ответ 12
Если вы разрабатываете Windows CE и мобильные приложения на С++, как уже упоминалось Einar, MFC - хороший выбор. Если вы сделаете этот выбор, MFC также станет разумным выбором для рабочего стола, так как вы можете использовать один и тот же код для настольных и ручных устройств. MFC остается хорошим опытом/легко реализуется комбинатонизация в этом сценарии. Лично я использую MFC совместно с библиотеками Stingray в этих модификациях, что дает очень хороший интерфейс, хорошую производительность и быстро и легко реализуется.
Ответ 13
Я бы сказал, что скорость и следы являются вескими причинами для .NET.
Возможно, вам будет трудно найти хороших программистов MFC, но это так же, потому что современные языки способствуют ленивым методам программирования, и большинство курсов программирования тяготеют к ним, поскольку их легче обучать.
Ответ 14
Я написал код межплатформенной платформы годами, поэтому, когда мне нужно что-то писать, у меня всегда есть очень тонкий слой абстракции между ним, и система вызывает почти все, кроме вызовов posix. Таким образом, вы можете закодировать его, перейдя по MFC, но при необходимости легко преобразовать его в другой API. Мой базовый набор библиотек С++, который я использую для всего, делает это с небольшим классом System. В настоящее время я использую MFC для Windows, и у меня также есть его с помощью XWindows для Linux и собственной версии Mac. И позже, когда я переношу его на карманный компьютер, он должен быть довольно безболезненным.
Если вы хотите заглянуть, это LGPL'ed и находится по адресу: