C++ MFC по сравнению с.NET?

Фантастически полезное module-starter генерирует простой в использовании скелетный проект, который обрабатывает установку модуля, создание документации и наглядности для файлов модуля для проживания в, и - я думаю - поддержка покрытия кода. Это - IMO большой запуск для любого Perl связанное с модулем усилие.

Также: использование CPAN-связанных инструментов как Module::Build - даже для модулей, которые, вероятно, никогда не будут выпущенными публично - , является очень хорошей идеей .

46
задан magol 8 November 2012 в 23:37
поделиться

8 ответов

I've used both MFC and Windows Forms extensively for a very long time. I'm from the video game industry, so have had to write many desktop applications over the years, and before .net, MFC was extremely useful. Even before that I was writing tools in pure Win32.

MFC definitely had its quirks, but overall it made life a lot easier. It was very easy to integrate OpenGL and Direct3D into custom views, and once you got the hang of it writing custom controls was a piece of cake. Best of all, I could just code in pure C++, which just happened to be my language of choice. Plus I found MFC to be very efficient and snappy.

Gradually MFC started to get external control library support, particularly docking/toolbar libraries, so my tools like 3D model viewers and level editors, all looked pretty sweet.

Most applications I wrote created the UI programmatically, so the dialog/window layout tool was more than adequate for my needs.

MFC 9 is pretty cool too, especially with the Ribbon control/docking library that Microsoft has released as part of the Feature Pack. So there is life in the old dog yet, for sure! :)

When .net 1.0 came out I found the transition fairly easy, because it supported managed C++. It wasn't pretty, but gave a relatively straightforward on-ramp to the .net framework. But the tipping point for me came when I started to write tools that needed the Windows Forms Designer more, around the time of .net 2.0. I decided to start again and learn C#, which I loved - although I'll never get used to having new() without delete() ;). I then started writing user controls, finding the whole experience very nice and straightforward. The .net framework was huge, well supported, and generally I found it easier to do just about everything in C#/.net. Plus, compilation was lightning fast, and the ability to refactor in Visual Studio was awesome.

The beauty of c#/.net is it doesn't limit you to just writing in managed code. You can still use unmanaged code, if performance is an issue for instance, or if you need to share code between platforms. For instance, my math libraries are written in C/C++, which I put into a libraries enabling C# to wrap/use the same code, although that's only temporary. I'm going to port those libraries to C# in time too so everything is pure .net.

The last experience I want to mention is that I have been spending the last few months away from console game programming, and spending time programming the InterWeb. I've been using the Microsoft stack, programming in ASP.net/C#, and I have to say it's very nice, with all of the knowledge of C# directly applicable. The only learning curve was ASP.net, not the language and support libraries. With the arrival of .net 3.5 (LINQ is sweet) life in the .net framework with C# is lovely.

Anyway, I don't want to turn this into my life's story, but I just wanted to give a brief experience of someone who has moved through all of the technology you've asked about. I'd also like to mention that it's good for you to try different languages/frameworks. I've been coding for the iPhone for a year now, and have grown to really like Objective-C. It's all programming, and it's all good.

With respect to MFC/.net, both have their pluses and minuses, and I really don't mind MFC at all, but in terms of moving forward, I'd probably stick to C#/.net, but please, please, please understand how it works. The only preachy thing I'll say is to understand how memory in .net works, even though 'it's all taken care of for you' ;)

Your knowledge of C/C++ should be completely independent of whether you use MFC or not, it's still a critical language (particularly in console-based video game programming), but for desktop application programming on Windows, it's getting harder and harder to argue against .net. It's fast, easy, has great tool support, excellent 3rd party libraries, a huge growing community, is now cross platform (Mono) and will enable you to move between all current/emerging Microsoft technologies (ASP.net, WPF, Silverlight, WCF etc).

For all of this, though, I still set up Visual Studio as a C++ environment. Some habits never die ;)

84
ответ дан 26 November 2019 в 20:03
поделиться

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

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

25
ответ дан 26 November 2019 в 20:03
поделиться

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

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

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

3
ответ дан 26 November 2019 в 20:03
поделиться

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

MFC - это больше, чем классы-оболочки GDI. Когда-то он разрабатывался как ООП-замена базового Win32 API, во многом как .Net сегодня. Однако MFC не остановил рост Win32 API, и теперь я могу сказать, что 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 возродился по запросу потребителей. Если вы разрабатываете будущие приложения, вы можете принять это во внимание.

Net может идти в ногу со временем без значительного увеличения объема загрузки через несколько лет.

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

Net может идти в ногу со временем без значительного увеличения объема загрузки через несколько лет.

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

3
ответ дан 26 November 2019 в 20:03
поделиться

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

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

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

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

2
ответ дан 26 November 2019 в 20:03
поделиться

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

-3
ответ дан 26 November 2019 в 20:03
поделиться

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

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

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

В отличие от большинства тюрем, .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 не поддерживает.

40
ответ дан 26 November 2019 в 20:03
поделиться

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

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

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

2
ответ дан 26 November 2019 в 20:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: