C ++ MFC против .NET?

Question

Мои коллеги используют Visual Studio 2002 и используют C ++ MFC. Я развиваюсь в C #.

Раньше проблем не было, но теперь мы спрашиваем наших клиентов, действительно ли нам следует развиваться в разных средах. Мои коллеги считают (конечно), что я должен перейти на C ++ MFC. Я думаю, что они могут использовать .NET вместо MFC.

Есть ли смысл изучать МФЦ? Это немного устарело, или я не прав? Какие аргументы против и для .NET по сравнению с MFC?

Edit:

Мы разрабатываем технологические системы и вспомогательные приложения для атомной промышленности. Основное приложение - это эмулятор, который эмулирует старую компьютерную систему и использует C ++ / MFC. Это очень критично ко времени, может быть, ядро ​​все еще должно быть в нативном C ++. Но графический интерфейс для эмулятора и всех окружающих приложений не особенно важен.

И есть ли реальная причина, по которой вам следует заменить существующее приложение MFC?

Answer 1

Я очень долго использовал и MFC, и Windows Forms. Я из индустрии видеоигр, поэтому на протяжении многих лет мне приходилось писать много настольных приложений, а до .net MFC был чрезвычайно полезен. Еще до этого я писал инструменты на чистом Win32.

MFC определенно имел свои причуды, но в целом это сделало жизнь намного проще. Было очень легко интегрировать OpenGL и Direct3D в настраиваемые представления, и как только вы освоили их, написание пользовательских элементов управления оказалось несложным делом. Лучше всего я мог просто написать код на чистом C ++, который оказался моим любимым языком. Кроме того, я обнаружил, что MFC очень эффективный и быстрый.

Постепенно MFC начал получать поддержку библиотек внешнего управления, в частности библиотек стыковки / панели инструментов, поэтому мои инструменты, такие как средства просмотра 3D-моделей и редакторы уровней, выглядели довольно мило.

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

MFC 9 тоже неплох, особенно с библиотекой управления / стыковки ленты, которую Microsoft выпустила как часть Feature Pack. Так что у старой собаки еще есть жизнь! :)

Когда вышел .net 1.0, я обнаружил, что переход довольно прост, потому что он поддерживает управляемый C ++. Это было не красиво, но дало сравнительно простую динамику для .net Framework. Но переломный момент для меня наступил, когда я начал писать инструменты, которые больше нуждались в конструкторе Windows Forms, во времена .net 2.0. Я решил начать снова и изучать C #, который мне очень понравился - хотя я никогда не привыкну иметь new () без delete ();). Затем я начал писать пользовательские элементы управления, находя весь опыт очень приятным и понятным. Платформа .net была огромной, хорошо поддерживаемой, и в целом мне было проще делать практически все в C # /. Net. Кроме того, компиляция была молниеносной, а возможность рефакторинга в Visual Studio была потрясающей.

Прелесть c # /. Net в том, что вы не ограничены только написанием управляемого кода. Вы по-прежнему можете использовать неуправляемый код, например, если проблема связана с производительностью или если вам нужно обмениваться кодом между платформами. Например, мои математические библиотеки написаны на C / C ++, который я поместил в библиотеки, позволяющие C # переносить / использовать один и тот же код, хотя это только временно. Я тоже собираюсь портировать эти библиотеки на C #, чтобы все было чисто .net.

Последний опыт, который я хочу упомянуть, - это то, что последние несколько месяцев я тратил на программирование консольных игр и на программирование InterWeb. Я использовал стек Microsoft, программируя на ASP.net/C#, и должен сказать, что это очень хорошо, при этом все знания C # напрямую применимы. Единственной кривой обучения был ASP.net, а не язык и вспомогательные библиотеки. С выходом .net 3.5 (LINQ это мило) жизнь в .net Framework с C # прекрасна.

В любом случае, я не хочу превращать это в историю своей жизни, но я просто хотел кратко рассказать о человеке, который изучил все технологии, о которых вы спрашивали. Я также хотел бы отметить, что вам полезно попробовать разные языки / фреймворки. Я уже год пишу для iPhone, и теперь мне очень нравится Objective-C. Это все программирование, и все хорошо.

Что касается MFC / .net, то у обоих есть свои плюсы и минусы, и я действительно не возражаю против MFC, но с точки зрения продвижения вперед, я бы, вероятно, придерживался C # /. Net, но, пожалуйста пожалуйста, пожалуйста, поймите, как это работает. Единственная проповедь, которую я скажу, - это понять, как работает память в .net, хотя «она обо всем позаботилась о вас»;)

Ваши знания C / C ++ должны быть полностью независимыми от того, используете ли вы MFC или нет, это по-прежнему критический язык (особенно в программировании видеоигр на основе консоли), но для программирования приложений для настольных компьютеров под Windows становится все сложнее и сложнее спорить против .net. Это быстро, просто, имеет отличную поддержку инструментов, отличные сторонние библиотеки, огромное растущее сообщество, теперь кроссплатформенный (Mono) и позволит вам переключаться между всеми текущими / появляющимися технологиями Microsoft (ASP.net, WPF, Silverlight, WCF и т.д.). * * тысяча двадцать-одна

Для всего этого я все же настроил Visual Studio как среду C ++. Некоторые привычки никогда не умирают;)

Answer 2

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

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

Использование .NET похоже на жизнь на съемочной площадке The Truman Show . Это соответствует представлению одного человека о том, на что должна быть похожа реальная жизнь . В его границах жизнь может показаться утопической. В конце концов, однако, это всего лишь приятная тюрьма, и ничто из того, что она изображает как жизнь, не вполне реально. Все ваше взаимодействие с внешним миром зависит от прихоти режиссера, чьи цели в основном состоят в повышении его собственных рейтингов; Ваше благополучие рассматривается только в той степени, в которой оно влияет на него.

В отличие от большинства тюрем, .NET имеет хорошо обозначенный путь эвакуации (помеченный как «P / Invoke»). Как и в случае с побегом из любой хорошей тюрьмы, это канализационная труба длиной в милю. Большинство жителей знают о его существовании, но почти единственные, кто туда приезжает, это подростки, доказывающие свою мужественность. Те немногие, кто использует его в реальных целях, делают это только в случае крайней необходимости. Те из нас, кто посчитал это необходимым слишком часто, поняли, что лучше просто остаться снаружи и не возвращаться обратно.

Редактировать: Поскольку некоторые люди хотят, чтобы в качестве доказательств в суде использовались круги и стрелки и абзац на задней части каждого из них: сильная и слабая сторона MFC заключается в том, что в основном это довольно тонкая оболочка вокруг API. Это слабое место, потому что в его покрытии есть довольно много дыр, и потому что он сравнительно мало «сглаживает» места, которые сам API не особенно хорошо сочетаются друг с другом. Например, если что-то реализовано с использованием COM, это обычно будет отображаться непосредственно в вашем коде, который его использует. Это сильная сторона, потому что довольно просто расширить MFC для обработки областей, которых он не имеет по умолчанию, а также просто обойти его и работать напрямую с API, когда это необходимо. Он также обновлялся относительно редко, поэтому в настоящее время он может создавать достаточно «современные» приложения, что не всегда имело место. Учитывая его историю, было бы трудно предсказать, что это будет продолжаться.

Сила и слабость .NET в том, что это гораздо более «толстая» оболочка вокруг API. Это значительно больше для «сглаживания» различий в API, поэтому (например) части, которые реализованы в COM, не выглядят и не заметно отличаются от частей, которые реализованы как прямые вызовы функций Си. Внутри .NET различия исчезают. .NET (в настоящее время) является излюбленной технологией Microsoft, поэтому она обновляется гораздо более регулярно и обеспечивает лучшую работу по обеспечению того, чтобы ваш пользовательский интерфейс следовал последним рекомендациям. Я предполагаю, что гораздо более вероятно, чем MFC, продолжать делать это в течение некоторого времени.

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

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

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

Answer 3

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

Что касается MFC , я стараюсь изо всех сил от него оторваться. Он устарел по вычислительным стандартам (думаю, что он приближается к 20 годам), но Microsoft по-прежнему видит ценность в поддержке его новыми выпусками и пакетами функций. С этой точки зрения, я сомневаюсь, что MFC скоро уйдет. Но это не значит, что я хочу программировать с этим. Текучесть и легкость, с которой можно программировать на C #, превосходят MFC / C ++ каждый день недели. Потоки, сокеты, операции со строками и т. Д. - все это проще сделать в C #, чем в C ++. Кроме того, C # / .NET является основным технологическим направлением для Microsoft, и я предпочел бы быть на этом краю, чем отставание MFC, когда дело доходит до развития карьеры.

Answer 4

Одна приятная особенность, которую предоставляет MFC, - это структура Document / View (один документ или несколько документов), которой еще не было эквивалентности в .NET. Эта функция может быть очень полезной и удобной, когда вам нужно создать приложение, которое работает как Microsoft Word. Это помогает отделить модель данных от представления, которое вы хотите представить пользователям. Я думаю, что большинство людей сразу перейдут на сторону .NET, как только эта функция будет реализована. (Microsoft работает над этим или, по крайней мере, планирует работать над этим?)

Answer 5

Какую проблему вы хотите решить? Предположим, вы в равной степени знаете и C ++ / MFC, и C # / .NET. Какой набор инструментов позволит вам создавать и поддерживать лучше? (Лучше субъективно, но опять же это зависит от ваших целей)

Если я не буду много работать с нативными API, которые недоступны в .NET, я пойду с .NET далеко. C ++ - отличный язык, и ничто не мешает вам программировать в Managed C ++, чтобы сохранить .NET Framework и управление памятью.

Для сравнения, моё наблюдение состоит в том, что инфраструктура MFC очень сложна и громоздка по сравнению с формами .NET Windows.

Answer 6

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

Однако

MFC - это больше, чем классы-оболочки GDI. Когда-то он разрабатывался как замена ООП для базового Win32 API, почти как сегодня .Net. Однако MFC не остановил развитие Win32 API, и теперь я могу сказать, что Win32 API вырастают из того, что может поддерживать MFC. За последнее десятилетие количество API-интерфейсов увеличилось в десятки раз.

Windows Forms, с другой стороны, должны были заменить только систему Windows GDI. Это остальные библиотеки .NET Framework, предназначенные для замены остальной части Win32, такие как WPF и XNA для DirectX и System.Speech для SAPI. Тем не менее, я вижу, что Win32 API вырастают из того, что может поддерживать .Net без значительного увеличения размера загрузки в течение нескольких лет.

Поэтому Windows Forms не может делать все, что может делать MFC, она разработана для упрощения RAD на основе GDI + и может включать в себя то, что MFC не может делать. Тем не менее, Windows Forms на основе GDI + идут вниз, так как Microsoft переориентируется на WPF, а MFC возрождается на основе запросов потребителей. Если вы разрабатываете для будущих приложений, вы можете принять это во внимание.

Answer 7

Я перешел с C ++ / MFC на C # / WinForms чуть более года назад (я знаю, поздний расцвет);

Помимо языковых различий, переход с MFC на WinForms будет намного проще, чем наоборот. Я думаю, что знание MFC определенно полезно, если вы хотите эффективно поддерживать устаревшие приложения. Тем не менее:

Буду ли я изучать МФЦ с нуля (с учетом существующих технологий)? Нет, наверное нет.
Буду ли я писать новые приложения в MFC? Нет, наверное нет.

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

Answer 8

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

.NET Framework имеет лучшую поддержку, так как его поддерживает большая команда, и он рассматривается как нечто, на чем строятся новые части Windows.

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

Answer 9

Неуправляемый код не обязательно выполняется быстрее, это зависит от написанного кода и от того, кто пишет код. Я читал некоторые сложные отчеты о тестах (источник, Code Project), и C # побил C ++ в некоторых отношениях, C ++ победил в других. Это зависит от вашей области: я пишу программное обеспечение для симуляторов полета, поэтому мне нужна неуправляемая среда. Если вы делаете приложение с графическим интерфейсом, C # может быть лучшим выбором. При программировании сокетов с низким уровнем рычага C ++ может давать лучшие результаты. Я не заметил серьезной разницы в скорости между C ++ и C # в обычных операциях, но я фанат C ++ за его собственную переносимость и C # за его простоту.

Answer 10

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