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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Мои причины:

Снижение производительности незначительно. Google для тестов, если вы не примете мое слово. Еще важнее сам код. Вы можете написать O (n ^ m) алгоритмы в С++ или .NET/С#. В настоящее время двигатели JIT очень зрелы.
Неуправляемый С++ имеет серьезные недостатки, когда дело доходит до модульного тестирования, издевательств и рефакторинга. Это очень громоздко и негибко. Отражение позволяет управляемому коду сделать такие вещи очень удобными.
Развертывание - небольшая проблема. Однако создание установки, которая проверяет необходимые предпосылки .NET и устанавливает их автоматически, не требует никаких проблем.
Компиляция выполняется быстрее, без компоновщика! Это даже происходит в фоновом режиме при редактировании кода.
Поддержка библиотеки .NET лучше и чище, чем STL, MFC и boost.
Нет файлов заголовков и макросов. Они просто подвержены ошибкам.
Безопасность! Хорошие байтовые переполнения буфера, плохие указатели, неинициализированные переменные...
Исключения. Очистить иерархию исключений в .NET. Исключения С++ перепутаны.

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

Защита интеллектуальной собственности. Это бесконечно сложнее, если кто-то перепроектирует Unmanaged С++-приложение. Управляемые .Net или Java-приложения могут быть легко декомпилированы, это не относится к Unmanaged С++.
Скорость. С++ ближе к оборудованию и имеет меньший объем памяти, как упоминалось в другом комментарии. Вот почему большинство видеоигр продолжают записываться на С++ и встроенной сборке.

Ответ 9

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

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

. Запуск программ в сети медленный и медленный, родной запускается быстро и быстро выполняется.

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

Используйте Delphi для Native, а не С++..Net частично основана на Delphi RAD и Java-сервере.