C++/CLI или C# для создания быстрого, современного и адаптивного графического интерфейса в Windows
В настоящее время я разделен между этими двумя языками. Я почти на полпути к программированию моего текущего приложения, которое должно быть очень быстрым. Он рассчитывает изолированные стеклянные конструкции любого типа при различных нагрузках.
Я просто не знаю, если это правильный выбор, чтобы написать его на C++/CLI. Например, в Интернете я никогда не читал название "C++/CLI", но все советуют изучать C#.
Каковы на самом деле недостатки C++ / CLI? Из моего прочтения я понял, что в ближайшие несколько лет обречено быть устаревшим. Это правда? И если они есть, они настолько плохи, что действительно нужно переключиться на C#?
Единственное, что сейчас говорит против C#, это то, что у меня есть C-код, к которому мне нужен доступ, и я не могу создать.Dll из-за проблем безопасности и предотвращения взлома. (Программа будет очень дорогой)
Какие еще возможности у меня есть, чтобы написать быстрый графический интерфейс, работающий на окнах (также с 3D-анимацией, многоядерной и даже графической обработкой ядра)?
5 ответов
В поисках более высокой производительности я перенес большую часть пользовательского интерфейса C#/WPF на C++/CLI (который превратился в C++/CX в том, что касается WinRT). Важно помнить, что это не C++, а набор управляемых расширений для языка C++ для поддержки.NET. Я люблю низкоуровневое кодирование пользовательского интерфейса и часто пишу большинство элементов управления в WPF, основываясь на DrawingVisual или UIElement, в зависимости от требований пользователя.
Мне лично не нравились "расширения" (например, использование шляп ^), и я нахожу это очень неестественным. Я не видел больших преимуществ от C# (и недавно выпущенный 4.6, похоже, внес дополнительные улучшения). Я лично думаю, что C++ / CLI скоро уйдет в прошлое. Я определенно не одинок в своей неприязни к C++/CLI, и такие ребята, как Кенни Керр, оказали большое влияние на весь вопрос. Фактически, я предсказываю, что MS примет его библиотеку и закат C++ / CLI в целом.
После выгрузки всего проекта и перехода на чистый C++ / Direct2D. Я сильно недооценил время разработки, но обнаружил ОГРОМНЫЙ выигрыш. Это нелегкий путь, так как вы будете писать свои собственные элементы управления (текстовые поля и все). Однако теперь есть Win2D (оболочка Direct2D), которая предоставляет эти элементы управления и выглядит как отличное решение (однако оно не было доступно, когда я начал, и я не собираюсь сейчас менять).
Я не мог бы быть счастливее с моим решением сейчас, но у меня наверняка были некоторые сомнения на этом пути, и я не обязательно рекомендовал бы это усилие, если ваше сердце действительно не надолго. В противном случае придерживайтесь того, что вы знаете.
РЕДАКТИРОВАТЬ: И, кстати, любой из тех, кто говорит, что C#/WPF так же быстро, как C++/DirectX, либо отрицание, либо бред. А с некоторыми из улучшений оптимизатора, включенных в VS2015, вы будете поражены небольшими затратами и производительностью, которая в результате. А удаление зависимости.NET - это огромная потеря веса, в то же время очень затрудняющая работу тех, кто намеревается провести реинжиниринг вашего продукта.
РЕДАКТИРОВАТЬ 2: Если вы в настоящее время не знаете C#/WPF, то, конечно, избегайте его, особенно если у вас есть существующий код C (вот почему я одобрил ответ Дейва). И если производительность критична, сейчас самое время перейти на DirectX 12 (наилучшая возможная производительность от MS tech). Удачи, звучит как веселый проект.
РЕДАКТИРОВАТЬ 3: Как указано выше (в отношении Кенни Керр), вот недавнее объявление, которое, вероятно, начнет новую эру, и закат C++ / CLI и C++/CX.
Чтобы ответить на ваш последний вопрос, возможно, вы должны смотреть на QT.
C++ / CLI хорош для склеивания нативных вещей и вещей.NET, но это непросто даже для опытных программистов C++ (потому что на самом деле это не C++).
"Проблема" с C++/CLI заключается в том, что C++ является одним из самых сложных языков высокого уровня (хотя некоторые утверждают, что это не язык высокого уровня). Поэтому создание приложения, особенно на основе графического интерфейса, намного сложнее, чем в C# или другом подобном современном языке. Также намного проще совершать радикальные ошибки, которые очень сложно отлаживать и отслеживать, хотя часть CLI этой комбинации облегчает эту задачу или решает некоторые проблемы, с которыми вы можете столкнуться.
С другой стороны, в некоторых отношениях проще оптимизировать, если это вообще нужно, и взаимодействие с кодом C очень простое. С другой стороны, очень легко написать очень плохо работающий код C++, если вы не знаете, что делаете. Поэтому, если вы не знаете C++, я бы рекомендовал держаться подальше от него для критически важного проекта, так как было бы сомнительно, что вы поставите работающую программу, не говоря уже о быстрой.
C# может быть таким же быстрым, но есть несколько вещей, которые мешают вам, самая большая из которых - автоматический запуск сборки мусора, который может вызывать периодические проблемы с производительностью. Таким образом, легче начать работать, но может быть труднее добиться хороших результатов. С взаимодействием кажется легким, хотя я не пробовал. Этот ответ кажется хорошим (верхний ответ в поиске Google 'C code from C#'): возможно ли вызвать функцию C из C#.Net?
Я иногда придерживаюсь мнения, что если бы мы могли повернуть время вспять, не могло бы быть C#, поскольку C++/CLI мог бы (сделал) свою работу. Но к тому времени, когда мы получили C++/CLI (Visual Studio 2005, Managed C++ был ужасен), C# уже был довольно успешным.
Мне придется искать ссылку, но текущее (или, по крайней мере, недавнее) руководство от Microsoft состояло в том, что C++/CLI теперь предназначен только для сценариев "взаимодействия". Это довольно большой шаг назад по сравнению с первоначальными целями, когда C++/CLI был впервые представлен; Первоначально он был задуман как первоклассный язык.NET рядом с C# и VB.NET.
Мое эмпирическое правило заключается в том, что если мне придется дублировать заголовочные файлы в C#, то C++/CLI может быть предпочтительнее. В противном случае, если это "простой" (строки, целые, двойные) P/Invoke для неуправляемого кода, просто пойдите с этим.
Эта идея, что C DLL менее безопасна, чем CLI DLL - откуда это взялось? Это полностью ложно в моей голове. Библиотеки C гораздо сложнее реконструировать, чем любой код IL.
Я использовал C++/CLI для взаимодействия с библиотекой C. Я также использовал взаимодействие с C# (aka, DllImport) для нескольких проектов ( таких как этот). DllImport бесконечно проще, чем C++/CLI. И это позволяет вам сохранить цель "Любой процессор"; Просто включите собственную DLL для каждой целевой платформы и загрузите нужную во время выполнения. Пиннинг в CLI трудно понять правильно. Вы заканчиваете с большим количеством попыток / наконец-то. Это странное сочетание операторов.