Есть ли еще вопрос для MFC

Question

Каковы неотразимые особенности MFC? Почему вы выбрали его для нового проекта?

Answer 1

Quick Tour Of New MFC Functionality

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

http://blogs.msdn.com/blogfiles/vcblog/WindowsLiveWriter/QuickTourOfNewMFCFunctionality_C777/Wizard%20Generated%20with%20accelerator%20tips_2.jpg

Действительно, это просто обновление виджета. Так нам нужно больше виджетов?

Answer 2

Преимущество MFC заключается в том, что он по-прежнему лучше, чем кодирование, на bare win32, и вы можете распространять собственный .exe, который не требует 23-50 Мб времени исполнения, например .Net.

Теперь, если вас беспокоят те вещи, есть лучше альтернативы: C++ Builder, WxWidgets и т. Д. Но в некоторых местах не рассматриваются инструменты, отличные от Microsoft.

Answer 3

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

Answer 4

Вы можете задать вопрос, почему вы выбрали C++ над C# для настольного приложения. C++ по-прежнему предлагает преимущества скорости, которые важны для некоторых приложений (я работаю для компании, которая создает программное обеспечение для электронной торговли. Скорость имеет большое значение).

Если вы собираетесь разрабатывать настольное приложение, предназначенное для Windows только на C++, то MFC - это самый зрелый выбор, с большим количеством свободного кода на основе MFC в Интернете, большого количества знаний.

Answer 5

Существующий API окон полностью основан на C. Если вы хотите использовать C++ (и вы, вероятно, должны), то MFC является логическим выбором, если вы хотите остаться родным (т. Е. Не использовать .NET).

MFC - это всего лишь набор объектно-ориентированных классов в верхней части C API. Плюс довольно много дополнительных «вспомогательных» классов, которые облегчают повседневные задачи.

Answer 6

По дизайну & технических достоинств в одиночку? Извините за категоричность, но ничего. Это плохой дизайн, чрезвычайно непроницаемая абстракция, где вам приходится возвращаться к программированию API Win32, злоупотреблять C++ вопиющим образом и твердо ориентироваться на вчерашней технологии: вы не получите современный (или даже привлекательный!) Пользовательский интерфейс из приложение MFC. Если вы можете получить разработчиков C# и у вас нет серьезных ограничений аппаратного обеспечения, зайдите в WinForms.

Внешние факторы, такие как доступность компетенции для найма, учебные программы и сторонние компоненты, с другой стороны, могут продлить срок их службы, по крайней мере, для некоторых видов приложений: небольшой & простой, предназначенный для специальных приложений с достаточно мало пользователей, предпочтительно внутри компании.

Answer 7

Вот возможность - представьте себе приложение, которое потребует большого объема памяти, скажем, графической программы, игры или, может быть, какого-то высокопроизводительного бизнес-приложения. Не секрет, что в HQ-памяти .NET-приложений - в этом случае вам может понадобиться худшее приложение MFC для ядра вашего приложения. Вы всегда можете загружать и использовать компоненты .NET, элементы управления и т. Д. Через COM-оболочки или непосредственно через C++/CLI.

Это все сказано - MFC - это боль. Вместо этого рассмотрим WTL - вы все равно можете позвонить в .NET, если вам нужно, так же, как я упоминал выше для MFC.WTL намного приятнее, чем MFC :-)

Answer 8

MFC был хорошим вариантом 10 лет назад. Это по-прежнему хорошая оболочка над Win32 API, но, к сожалению, устарела.

QT Trolltech является лучшим вариантом с одним большим преимуществом - он независим от платформы. С MFC вы обречены на Windows.

Answer 9

Я написал код межплатформенной платформы в течение многих лет, поэтому, когда мне нужно что-то написать, у меня всегда есть очень тонкий слой абстракции между ним, и система вызывает почти все, кроме вызовов posix. Таким образом, вы можете закодировать его, перейдя по MFC, но при необходимости легко преобразовать его в другой API. Мой базовый набор библиотек C++, который я использую для всего, делает это с небольшим классом System. В настоящее время я использую MFC для Windows, и у меня также есть его с помощью XWindows для Linux и собственной версии Mac. И позже, когда я переношу его на карманный компьютер, он должен быть довольно безболезненным.

Если вы хотите взять быстрый взгляд, это LGPL'ed и находится в:

http://code.google.com/p/kgui/

Answer 10

Я думаю, что нет .. MFC потеряет в

• Уровень абстракции
• Время разработки
• Время устранения неполадок
• Кривая обучения для новой d evelopers
• Будущее теплоизолирующие (хотя сейчас это сомнительно .. что-то новое придумывают каждые 3-4 года)
• найти хороших людей, которые знают их МФЦ
• Простота в использовании управления

Единственное место где MFC, вероятно, проскользнет мимо, - если у вас есть приложения с очень высокой интенсивностью, например, у вас есть вещи на экране, которые нужно перерисовывать каждые 10 мсек или 1 сек. «Управляемые» приложения до сих пор не смогли преодолеть это препятствие.

MFC был важным шагом в эволюции, но теперь доступны лучшие варианты.

Answer 11

Если вы разрабатываете Windows CE и мобильные приложения на C++, как уже упоминалось Einar, MFC - хороший выбор. Если вы сделаете этот выбор, MFC также станет разумным выбором для рабочего стола, так как вы можете использовать один и тот же код для настольных и ручных устройств. MFC остается хорошим опытом/легко реализуется комбинатонизация в этом сценарии. Лично я использую MFC совместно с библиотеками Stingray в этих enivornments, что дает очень хороший интерфейс, хорошую производительность и быстро и легко реализуется.

Answer 12

Я по-прежнему использую MFC для всех видов приложений. MFC получил плохой рэп от его ранних реализаций, но теперь он отлично. Я считаю это более удобным, чем WTL. Кроме того, инструменты GUI в Visual Studio уже настроены, чтобы упростить быстрое создание графических интерфейсов с помощью MFC, управление отображением переменных, DDX и т. Д.

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

Answer 13

Я бы сказал, что скорость и следы являются вескими причинами для .NET.

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

Answer 14

Помимо самого win32 api, MFC - единственная технология программирования Windows, которая все еще жива и хорошо в 2011 году после 15 лет. Еще в 2001 году все говорили: «MFC мертв, теперь все Winforms»; в 2005 году все сказали: «MFC мертв, теперь все XAML»; теперь это 2011 год, а Winforms и XAML мертвы (ОК XAML, может быть, не совсем мертв, но не прошел его премьер), а MFC по-прежнему обновляется с последними событиями (лента, расширения Aero, API Win7 и т. д.).

Конечно, это не гарантирует ничего в будущем, но за эти 15+ лет кода MFC написано, и оно останется в использовании в течение следующего десятилетия или десятилетия. Это может быть не самая красивая технология, но она хорошо понятна (ее хорошие и плохие точки) и не является движущей целью, как другие технологии шумихи, а это означает, что люди, которые действительно хотят получить материал, могут на это положиться (а лучше чем по альтернативам, во всяком случае).

(то же самое относится и к C++, кстати)