Управляемый С++ (С++/CLI) vs С#/VB.NET

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

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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

/pissedof

Ответ 3

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

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

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

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