Какие преимущества дает разработка приложения Win32 на C++ по сравнению с приложением .NET на C#?

Я изучил программирование для Windows с помощью Visual C++ и Win32 API. В настоящее время кажется, что большинство приложений разрабатываются в .NET с использованием C#. Я понимаю, что в большинстве случаев между нативным кодом и управляемым кодом нет большой разницы в производительности. Поэтому мне интересно, если бы я начал писать новое настольное приложение сегодня, есть ли какая-либо причина (кроме того факта, что я лучше знаком с C++), что я мог бы вместо этого написать его на неуправляемом C++ .NET? Есть ли еще какие-то преимущества в использовании C++ и нативного кода? Или этот метод был более или менее заменен на .NET на платформе Windows?

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


c++ .net c# unmanaged managed-code
person Joshua Carmody    schedule 18.02.2009    source источник
comment
Если решение между Win32 и .Net... идите в .Net Несколько человек жалуются на отсутствие .Net для их платформы... но если вы писали для Win32, эта кроссплатформенность не проблема.   -  person Matthew Whited    schedule 28.05.2009
comment
Я до сих пор регулярно занимаюсь разработкой на c++ win32, включая совершенно новые приложения. Большинство наших программ являются графическими по своей природе с очень небольшим количеством стандартных функций пользовательского интерфейса. Я нахожу людей, которые проклинают неуправляемую память, часто просто повторяют то, что они слышали, и на самом деле не имели опыта работы с С++. Я предпочитаю быть ближе к железу, чтобы оптимизировать определенные алгоритмы. Кроме того, я исправлю одно большое заблуждение — кривая обучения для win32 МЕНЬШЕ, чем для .NET и C# (при условии, что вы имеете опыт работы с C++). См. - charlespetzold.com/pw5/index.html. +win32 легко устанавливает/запускает все версии win.   -  person Jeff    schedule 17.04.2012
comment
Извините, но я редко вижу приложения .NET в действии. Большинство современных программ для Windows написано на Win32API/MFC/Delphi/C++Builder/wxWidget/Qt.   -  person dns    schedule 12.08.2014

Ответы (9)


arrow_upward
14
arrow_downward

  • Производительность (определенные ситуации, например графика)
  • Объем памяти (как сказал Манкузо)
  • Использование существующих библиотек
  • Нет необходимости в среде выполнения
  • Более точный контроль

Чтобы перечислить несколько.

Однако вы также можете взглянуть на вопрос с противоположной стороны, чтобы объективно оценить, какой язык использовать.

Кроме того, вы можете использовать C++/CLI для включения как собственного кода, так и кода .net.

person Inisheer    schedule 18.02.2009

arrow_upward
18
arrow_downward

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

Некоторые люди могут быть разочарованы, увидев, что ваше приложение размером 2 МБ на самом деле требует еще 20 МБ загрузки фреймворка и утомительного процесса установки для запуска. Если они не уверены, действительно ли им нужно ваше приложение, они могут просто удалить его, даже не попробовав, и перейти на конкурирующий продукт.

person Adrian Grigore    schedule 18.02.2009
comment
Хотел бы я проголосовать за это еще раз. Когда я хочу попробовать новое приложение, и оно просит меня установить среду выполнения, которую я еще не установил, я сразу же пробую что-то еще. - person Joe Pineda; 19.02.2009
comment
Как часто вы устанавливаете новую версию среды выполнения .NET или JRE? Кажется, я установил .NET 3.5SP1 еще в августе 2008 года. - person olli-MSFT; 19.02.2009
comment
Олли: Вы разработчик, что делает вас элитой пользователей компьютеров. Если ваши клиенты не являются также разработчиками (и особенно если они являются неопытными пользователями, которые почти не используют свой компьютер), примерно у половины из них, вероятно, не будет установлена ​​среда выполнения. - person Adrian Grigore; 19.02.2009
comment
Можно было бы загрузить фреймворк, но это превращает ваше 2-мегабайтное приложение в 20-мегабайтное. Положительным моментом является то, что пользователь не знает, что он устанавливает фреймворк. - person Steven Evers; 28.05.2009
comment
Как пользователь, я хотел бы, чтобы установщик загружал и устанавливал фреймворк для меня, если это необходимо, чтобы исходная загрузка не была раздута фреймворком. Таким образом, я могу загрузить приложение быстрее, если у меня уже есть фреймворк. Тем не менее, это далеко не идеально. Нативное приложение тут однозначно лучше. - person Adrian Grigore; 28.05.2009
comment
Иногда мне нужно написать небольшой инструмент с намерением сделать его исполняемым на максимально возможной машине. Я склонен использовать для этого C++. Когда вышел .NET, я надеялся, что использование самой низкой версии .NET будет хорошей стратегией для таких инструментов, но это определенно НЕ так — .NET 1.0/1.1 устарел, а .NET 2.0 не устанавливается по умолчанию в новых версиях Windows. Наконец, я уверен, что C++ - лучший выбор, но иногда я выбираю .NET 3.5 из-за банальной лени, когда тот или иной инструмент проще написать на .NET (и я знаю цену - сложнее или невозможно использовать на старых машинах). - person Andrzej Martyna; 04.10.2016

arrow_upward
8
arrow_downward

Если ваше приложение должно иметь возможность работать без установки (т. е. если вы не можете или не должны делать что-то вроде установки .NET framework), вы не можете рассчитывать на то, что .NET будет на компьютере с Windows (до Vista). ). Многие служебные приложения могут попасть в эту категорию.

person Daniel LeCheminant    schedule 18.02.2009

arrow_upward
7
arrow_downward

Я бы рекомендовал писать каждое настольное приложение в управляемом коде. .NET/C# — отличная платформа для этого.

Мои причины:

  1. Снижение производительности незначительно. Погуглите тесты, если не верите мне на слово. Важнее сам код. Вы можете писать алгоритмы O(n^m) на C++ или .NET/C#. Двигатели JIT в наши дни очень зрелые.
  2. Неуправляемый C++ имеет серьезные недостатки, когда речь идет о модульном тестировании, моделировании и рефакторинге. Это очень громоздко и негибко. Рефлексия позволяет управляемому коду делать такие вещи очень удобными.
  3. Развертывание — небольшая проблема. Однако создание установки, которая проверяет наличие необходимых предварительных условий .NET и устанавливает их автоматически, не составляет труда.
  4. Компиляция быстрее, без компоновщика! Это происходит даже в фоновом режиме, когда вы редактируете код.
  5. .NET поддержка библиотеки намного лучше и чище, чем STL, MFC и boost.
  6. Нет файлов заголовков и макросов. Они просто подвержены ошибкам.
  7. Безопасность! Прощайте, переполнение буфера, плохие указатели, неинициализированные переменные...
  8. Исключения. Четкая иерархия исключений в .NET. Исключения C++ испорчены.
person olli-MSFT    schedule 18.02.2009
comment
Ничто не может быть дальше от истины. Снижение производительности при работе в управляемой среде огромно. У вас практически нет контроля над управлением памятью, это катастрофа для приложений, которым требуется производительность в реальном времени, таких как видеоигры. Управляемые решения обычно лучше всего подходят для бизнес-приложений. - person James; 19.02.2009
comment
И вы застряли с решением только для Windows. Очень жаль всех этих пользователей Mac... - person user52875; 19.02.2009
comment
Предоставленный неуправляемый C++ не имеет смысла для каждой ситуации. Но у него все еще есть свои преимущества в определенных сценариях в соответствии с намерением исходного вопроса. Из всех этих комментариев можно подумать, что неуправляемому C++ больше не место (неправда). - person James; 19.02.2009
comment
Существуют альтернативы .Net, которые являются кроссплатформенными и по-прежнему управляемыми (например, Mono, Java). - person Mark; 19.02.2009
comment
@James, учитывая, что C ++ имеет свое место для видеокодеков, видеоигр и сценариев в реальном времени. Но определенно не для настольных приложений, веб-приложений, бизнес-приложений и так далее. - person olli-MSFT; 19.02.2009
comment
@wdu, написание переносимого нативного приложения C/C++ - черное искусство. Это требует больших усилий. Добиться того же с помощью mono/.NET и Java проще. - person olli-MSFT; 19.02.2009
comment
В этом ответе есть ряд хороших моментов, но я принял ответ Джеймса Аткинсона, потому что он более прямо отвечает на вопрос. Что я действительно хотел знать, так это то, где неуправляемый C++ все еще имеет мир .NET. - person Joshua Carmody; 19.02.2009
comment
Я согласен с Джеймсом. Накладные расходы памяти для приложений .net огромны. Посмотрите на Qt (теперь с LGPL) для хорошего неуправляемого кросс-платформенного решения. - person Nick; 23.03.2009
comment
Опять же, я не могу не согласиться с этим пунктом. Да, из-за GC возникают накладные расходы, но на современных ПК с ~4 ГБ ОЗУ просто бессмысленно говорить о проблемах с памятью в стандартных настольных приложениях. Обработка памяти в неуправляемом коде подвержена ошибкам и требует времени и, следовательно, денег. - person olli-MSFT; 23.03.2009
comment
Вам, ребята, которые сохраняют управляемый код, который не может работать с играми, действительно нужно проверить XNA. Настоящие 3D-игры на Java — отстой, но XNA великолепен и с ним легко работать. - person Matthew Whited; 28.05.2009

arrow_upward
2
arrow_downward

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

person Nicholas Mancuso    schedule 18.02.2009
comment
.NET имеет тенденцию занимать память и не возвращать ее обратно в ОС, если только доступная память последней не упадет ниже порогового значения. Это нормально, если у вас будет несколько экземпляров вашего приложения, работающих одновременно, используя для этого большую часть ресурсов. В других случаях это катастрофа. - person Joe Pineda; 19.02.2009

arrow_upward
2
arrow_downward

Если вы можете позволить себе зависимость от стека, выберите .NET Modern, элегантную, мощную и, как следствие, более быструю для разработки.

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

Win32 старый и неуклюжий, но он работает практически с любой версией Windows без дополнительных зависимостей, а ваш код может быть написан на простом переносимом языке C/C++.

person nixps    schedule 18.02.2009

arrow_upward
2
arrow_downward

+1 за то, что не требуется пакет/установка .NET на целевой машине (машинах). Это все еще большая проблема.

Когда на всех машинах будут моно или NET, это не будет иметь большого значения.

person Tim    schedule 18.02.2009

arrow_upward
0
arrow_downward

Две вещи, о которых я могу думать.

  1. Защита интеллектуальной собственности. Кому-то невероятно сложно реконструировать неуправляемое приложение C++. Управляемые приложения .Net или Java можно легко декомпилировать, но это не относится к неуправляемому C++.

  2. Скорость. С++ ближе к оборудованию и имеет меньший объем памяти, как упоминалось в другом комментарии. Вот почему большинство видеоигр продолжают писать на C++ и встроенном ассемблере.

person James    schedule 18.02.2009
comment
Сравнение яблок с бананами. C++ — это многоплатформенный язык, который можно использовать для создания кода, ориентированного на среду .NET. Это приложение будет так же легко декомпилировано, как приложение c#/CLR или Java/JVM. И потом, если я правильно помню, GCC умеет компилировать java в нативный код, так что этот момент спорный. - person Joe Pineda; 19.02.2009
comment
На самом деле это вообще не спорно, все зависит от того, какой компилятор вы используете. Вы правы, если код скомпилирован в управляемый код. Но если вы скомпилируете неуправляемый код, моя точка зрения остается в силе. - person James; 19.02.2009
comment
Вряд ли это защита, методы обфускации для управляемого кода слабы по сравнению с ней. Вы когда-нибудь пытались дизассемблировать нативный код обратно в работающий C++? Поверьте мне, это гораздо сложнее, чем реконструировать управляемое приложение, где сейчас есть бесплатные инструменты, которые делают это. - person James; 19.02.2009
comment
Хотел бы я отредактировать свой комментарий. Я хотел сказать, что сейчас есть много бесплатных инструментов, которые делают это. Так что определенно есть преимущество, если вы хотите написать что-то с более надежной защитой кода. - person James; 19.02.2009

arrow_upward
0
arrow_downward

Программы .Net также имеют срок службы поддержки, в то время как родные программы на самом деле не имеют. Native будет работать в течение многих лет в разных ОС без необходимости обновлений.

Программы .Net могут быть закрыты из-за плохой конфигурации .Net, нативные программы просто продолжают работать и практически не зависят от обновлений ОС.

Программы .Net запускаются медленно и кажутся вялыми, родные запускаются быстро и быстро работают.

.Net должен быть закодирован для наименьшего общего знаменателя (наиболее распространенная версия фреймворка), Native компилирует весь код в приложение — так что используйте то, что хотите.

Используйте Delphi для Native, а не C++. .Net частично основан на Delphi RAD и бэкенде Java.

person William Egge    schedule 04.10.2016