Managed C++ (C++/CLI) vs 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. Однако, если у клиента много существующей или текущей родной разработки на С ++, тогда текущий путь может быть лучшим.

Answer 2

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

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

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

Каждый раз, когда мне нужно было заполнить сетку, я сериализовал свои 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 dropped support for IntelliSense for C++/CLI для «улучшения общего IntelliSense» (я думаю, специально для C++). Если вы еще не пробовали, я бы определенно посоветовал проверить WPF для приложений.