Управляемый C ++ (C ++ / CLI) против C # / VB.NET

Question

Я много работал с C #, но я начинаю проект, в котором наш клиент желает, чтобы весь код был написан на C ++, а не на C #.Этот проект будет представлять собой смесь между управляемым (.NET 4.0) и собственным C ++.Поскольку я всегда предпочитал C # C ++ для своих нужд .NET, мне интересно, есть ли какие-то важные различия, которые я, возможно, не осознаю, между использованием C # и управляемым C ++?

Любое понимание этого очень ценится.

EDIT Просмотр в Википедии управляемого кода C ++ показывает, что новая спецификация - C ++ / CLI и что «управляемый C ++» устарел.Обновлен заголовок, чтобы отразить это.

Answer 1

C ++ / CLI - это полноценный язык .NET, и, как и другие языки .NET, он очень хорошо работает в управляемом контексте. Подобно тому, как работа с нативными вызовами в C # может быть затруднена, чередование нативного C ++ и Managed C ++ может привести к некоторым проблемам. С учетом сказанного, если вы работаете с большим количеством собственного кода C ++, я бы предпочел использовать C ++ / CLI вместо C #. Есть немало ошибок, большинство из которых могут быть охвачены тем, что не пишите на C ++ / CLI, как если бы вы писали на C #, и не пишите так, как если бы вы писали на родном C ++. Это его собственная вещь.

Я работал над несколькими проектами C ++ / CLI, и подход, который я выбрал бы, действительно зависит от того, насколько разные уровни приложения подвергаются воздействию собственного кода C ++. Если большая часть ядра приложения является нативной, а точка интеграции между нативным и управляемым кодом немного размыта, я бы везде использовал C ++ / CLI. Преимущество элемента управления в C ++ / CLI перевесит его проблемы. Если у вас есть четкие точки взаимодействия, которые можно адаптировать или абстрагировать, тогда я настоятельно рекомендую создать мостовой слой C ++ / CLI с C # выше и C ++ ниже. Основная причина этого заключается в том, что инструменты для C # просто более развиты и более распространены, чем соответствующие инструменты для C ++ / CLI. С учетом сказанного, проект, над которым я работаю, был успешным и не был кошмаром, на который указал другой.

Я бы также убедился, что вы понимаете, почему клиент движется в этом направлении. Если идея заключается в том, что у них есть куча разработчиков C ++, и они хотят упростить им переход к написанию управляемого кода, я бы сказал клиенту, что изучение C # может быть менее сложным, чем изучение C ++ / CLI.

Если клиент считает, что C ++ / CLI работает быстрее, это просто неверно, поскольку все они компилируются в IL. Тем не менее, если клиент имеет много существующих или текущих собственных разработок на C ++, то текущий путь на самом деле может быть лучшим.

Answer 2

Я сделал проект с C ++ / CLI, и я должен сказать, это была мерзость .По сути, это было приложение WinForms для управления сотрудниками, хоккейными играми, обменами между командами, календарями и т. Д. И т. Д.

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

Хуже всего было использовать только типы C ++ для моей серверной части и использовать управляемые типы для клиентской части.Прежде всего, вы не можете назначить стандартную строку управляемой строке.Вам нужно будет преобразовать все.Очевидно, вам придется преобразовать его обратно ...

Каждый раз, когда мне нужно было заполнить сетку, я сериализовал свои коллекции C ++ в нечто вроде vector<std::string>, извлекал это в моей библиотеке пользовательского интерфейса, а затем зацикливал впадинуэто и сделал новый DataGridRow, чтобы добавить их в сетку.Что, очевидно, можно сделать за 3 минуты с помощью C # и небольшого количества Linq to SQL.

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

Думаю, было бы проще, если бы я использовал List<Customer>^ (управляемый список некоторых объектов) в моем C ++ вместовсегда преобразовывать все между векторами строк.Но мне нужно было держать C ++ в чистоте от управляемых вещей.

/ pissedof

Answer 3

Из всех трех областей (.NET, C ++ / CLI и C ++) я могу сказать, что в любом случае я предпочитаю использовать .NET (через C # или VB.NET). Для приложений вы можете использовать либо WinForms, либо WPF (последнее из которых я считаю намного лучше, особенно для приложений, которые выглядят гораздо более удобными для пользователя).

Основная проблема с C ++ / CLI заключается в том, что у вас нет всех приятных языковых функций, которые вы получаете в .NET. Например, ключевое слово yield в C # и использование лямбды (я не думаю, что это поддерживается в C ++ / CLI - не удерживайте меня на этом).

Однако есть одно большое преимущество C ++ / CLI. Это означает, что вы можете создать мост, чтобы позволить C # и C ++ общаться. В настоящее время я работаю над проектом, в котором многие математические вычисления и алгоритмы уже написаны (на протяжении многих лет) на C ++, но компания хочет перейти на пользовательский интерфейс на основе .NET. Изучив различные решения, я пришел к выводу, что C ++ / CLI гораздо лучше для этого. Одним из преимуществ является то, что он позволил мне создать API, который для разработчика .NET выглядел и работал так же, как тип .NET.

Однако для разработки внешнего интерфейса приложения я бы не советовал использовать C ++ / CLI. С точки зрения удобства использования (с точки зрения времени разработчика при его использовании) это просто не стоит. Одна большая проблема заключается в том, что VS2010 отказался от поддержки IntelliSense для C ++ / CLI , чтобы «улучшить общее IntelliSense» (я думаю, специально для C ++). Если вы еще не пробовали, я бы определенно рекомендовал проверить WPF для приложений.