Вы рекомендуете Собственному компоненту C++ C ++\CLI сдвиг? [дубликат]

Некоторые вопросы рассмотреть перед переключением:

[1] Соглашаются Вы с придерживанием Windows? Существуют клоны.NET для другой ОС, но Ваше приложение не собирается просто работать прозрачно. Сложность Вам, возможно, не понадобилось бы.

[2] Вы рассмотрение, переключающееся только для поддержки сборки "мусора"? Если так, можно просто пользоваться некоторыми библиотеками сборщика "мусора" C++. И если Вы выясняете, как усилить станд.:: shared_ptr, Вы не могли бы чувствовать потребность в сборщиках "мусора". Издержки Вам, возможно, не понадобилось бы.

[3] Вы рассматривающий C++ / CLI из-за сборки "мусора" & все полезные классы.NET, которые можно усилить? Если так, почему не просто переключаются на c#. C++ / CLI является переходной технологией, и лучше не инвестировать ресурсы в такие вещи. c# становится довольно зрелым и применимым.

Лично, я просто придерживался бы C++;).

Там какое-либо преимущество Вам? Вы, вероятно, потеряете способность переключиться на другую ОС.

не беспокойтесь, если Вы не интегрируетесь с приложениями.NET. Конечно, не используйте STL/CLR, поскольку его производительность действительно ужасна.

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

также кажется, что повышение OSS увеличивается, поэтому теперь могло бы быть время для исследования пользующихся межплатформенных библиотек и инструментов. Можно развернуть приложение Linux намного более легко, чем окна одно (путем поставки полностью настроенной ОС!), и Вы получаете намного лучший ROI при развертывании клиентов Linux (поскольку они свободны).

, Если бы я был бизнесменом, я надеялся бы, по крайней мере, иметь возможность развернуться на Linux или Mac, чем просто только для окон. Стратегически, я не хотел бы держать пари, что мир остался с Microsoft за 5 лет.

Мне не нравится C++ / CLI так, что я рекомендовал бы держаться подальше, как я описываю здесь . Некоторые предлагают использовать C++ / CLI как мост между стандартным C++ и C#, но благодаря пути разработан C++ / CLI, это очень утомительно для использования того пути (необходимо вручную создать обертки нормального кода C++, который можно назвать от C#). Поэтому я рекомендовал бы БОЛЬШОЙ ГЛОТОК вместо этого для взаимодействия через интерфейс со стандартным C++ с C# (хотя по общему признанию, БОЛЬШОЙ ГЛОТОК имеет существенную кривую обучения).

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

, Если бы необходимо использовать существующий код C++, смешанный в с платформой.NET, тогда имело бы смысл использовать C++ / CLI, но в целом необходимо только начать с C#.

, Если существует что-то в.NET, которую новый проект должен использовать экстенсивно (возможно, более простой дизайн GUI или что-то), затем используйте C#. в противном случае тогда палка с собственным C++. Я не думаю, что Вы потеряете что-либо путем выполнения этого.

Смотрите на те две статьи:

Критический Обзор C++ / CLI, Первая часть

Критический Обзор C++ / CLI, Вторая часть

Я полагаю, что к настоящему времени Вы убеждены, как я - то, что C++ / CLI не является ни один "набором расширений C++" (во многих аспектах, это - на самом деле подмножество C++), и при этом он не связан с C++ больше, чем какой-либо другой язык с точками с запятой и фигурными скобками. Кроме того, C++ / CLI является определенно ориентированным на Windows языком программирования; определенно не язык Солярис 10 серверов или мобильный телефон Nokia будут рады работать. Что это имеет какое-либо отношение к C++?

Документы Microsoft - это хороший старт

У Кэтлин Доллард тоже есть хорошие материалы

Для вашей собственной программы нет стандартного способа получения информации от JVM о вывозе мусора. Любой такой API зависит от поставщика.

Почему объекта, которое вы сочли недостаточным?

Одним из основных недостатков использования C + +/CLR является возможность потери IP-адреса (интеллектуальной собственности), если код не скрыт должным образом. В целом я согласен с заявлениями, сделанными здесь другими членами. Если требуется, чтобы переносимый код не зависел от виртуальной машины MS .net, необходимо использовать собственный C/C + +.