С++ MFC vs .NET?

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

MFC больше, чем его классы оболочки GDI. В свое время он был разработан как замена OOP для базового API Win32, в значительной степени похожий на .Net сегодня. Тем не менее, MFC не остановил API Win32, и теперь я могу сказать, что API-интерфейсы win32 растут из того, что может поддерживать MFC. За последние десять лет количество API увеличилось в десятки раз.

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

Я бы изучил MFC с нуля (учитывая существующие технологии)? Нет, наверное, нет.
Я бы написал новые приложения в MFC? Нет, вероятно, нет.

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

Ответ 9

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

Ответ 10

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