Каковы преимущества выполнения 100% управляемой разработки с использованием C ++ / CLI?

Question

Каковы преимущества (список возможных недостатков длинен) выполнения 100% управляемого разработки с использованием C ++ / CLI (то есть компилируется с / clr: safe which " генерирует ... сборки, как написанные в ... C # ")? Особенно при сравнении с C # (примечание C ++ / CLI: преимущества по сравнению с C # и . Есть ли какое-либо преимущество в использовании C ++ / CLI по сравнению со стандартным C ++ или C #? в основном по поводу управляемого / неуправляемого взаимодействия ).

Например, вот несколько советов от моей головы:

• C ++ - ссылки в стиле для управляемых типов , не такие элегантные, как полномасштабные ненулевые ссылки, но лучше, чем ничего, или использование обходного решения .

• шаблоны, более мощные, чем генерики

• препроцессор (это может быть недостатком !, но макросы могут быть полезны для генерации кода)

• семантика стека для ссылочных типов - автоматический вызов IDisposable :: Dispose ()

• упрощенная реализация Dispose () через деструктор C ++

В C # 3.0 добавлены автоматически реализованные свойства, так что это больше не является преимуществом C ++ / CLI.

Answer 1

Я думаю, что единственным большим преимуществом является управляемое / неуправляемое взаимодействие. Написание чисто управляемого C ++ / CLI (по крайней мере для меня) без взаимодействия с C # или другими языками .Net кажется полностью упущенным. Да, ты мог бы сделать это, но почему бы тебе.

Если вы собираетесь писать чистый управляемый код, почему бы не использовать C #. Особенно (как сказал nobugs), если VS2010 отказывается от поддержки IntelliSense для C ++ / CLI. Также в VS2008 IntelliSense для C ++ / CLI не так хорош, как C # IntelliSense; так что с точки зрения разработчика легче работать / изучать / реорганизовывать в C #, чем в C ++ / CLI.

Если вам нужны перечисленные вами преимущества C ++, такие как препроцессор, семантика стека и шаблоны, то почему бы не использовать C ++?

Answer 2

Странно, мне нравится C ++ / CLI, но вы перечислили именно те функции, которые мне не нравятся. Моя критика:

• Хорошо. Но случайное использование шляпы довольно широко распространено, поэтому значение типа значения помещается в рамку без предупреждения. Нет возможности диагностировать эту ошибку.
• Мощность, которая стоит дорого, написанные вами шаблоны не могут использоваться ни на каком другом языке .NET. Во всяком случае, это ухудшает проблему экспорта шаблона C ++. Также стоит задуматься над полным провалом STL / CLR.
• Эмм, нет.
• Это была серьезная ошибка ИМО. Уже сложно избежать проблем со случайным боксом, как указано в первом пункте. Семантика стека серьезно затрудняет любой начинающий программист. Это было дизайнерское решение, чтобы успокоить программистов на C ++, это нормально, но оператор using был лучшим решением.
• Не уверен, как это проще. Вызов GC.SuppressFinalize () автоматический, вот и все. очень редко кто-нибудь может написать финализатор, но вы не можете избежать автоматического генерирования кода от вызова. Это неэффективно и является нарушением принципа «вы не платите за то, что не используете». Добавьте к этому, что написание деструктора также заставляет автоматически генерировать финализатор по умолчанию. Тот, который вы никогда не будете использовать и не захотите использовать, если вы забыли или не использовали деструктор.

Ну, это все возможно очень субъективно. Смертельный звонок будет поставляться с VS2010, он будет поставляться без поддержки IntelliSense для C ++ / CLI.

Answer 3

В C ++ / CLI вы можете определять функции вне классов, вы не можете делать это в C #. Но я не знаю, является ли это преимуществом

Answer 4

Как и другие здесь, я не могу вспомнить ни одного общего случая, когда существует явное преимущество, поэтому мое мышление перешло к ситуативным преимуществам - есть ли случаи, когда есть преимущество в конкретном сценарии?

Преимущество: Использование навыков технического персонала C ++ в сценарии быстрого прототипирования.

Позвольте мне уточнить ...

Я довольно много работал с учеными и(не программные) инженеры, которые не являются официально обученными программистами.Многие из этих людей используют C ++ для разработки специальных модулей, включающих физику / математику высокого уровня.Если в сценарии быстрого прототипирования требуется чистый модуль .NET и набор навыков ученого / инженера, ответственного за модуль, - C ++, я бы научил их небольшому количеству дополнительного синтаксиса (public ref, ^ и % и gcnew) и заставить их программировать свой модуль как управляемую на 100% DLL C ++ / CLI.

Я понимаю, что существует целая куча возможных ответов "Да, но ...", ноЯ думаю, что использование навыков технического персонала C ++ является возможным преимуществом C ++ / CLI.

Answer 5

Вы можете иметь перечисления и делегаты как общие ограничения в C ++ / CLI, но не в C #.

https://connect.microsoft.com/VisualStudio/feedback/details/386194/allow-enum-as-generic-constraint-in-c

В C # есть библиотека для имитации этих ограничений.

http://code.google.com/p/unconstrained-melody/

Answer 6

Я согласен с тем, что вы упомянули, и в качестве примера использования препроцессора можно указать: Boost Preprocessor library для генерации набора типов на основе списка основных типов, например PointI32, PointF32 и т. Д. В C ++ / CLI

Answer 7

Можно представить следующие требования к гипотетическому продукту:

1. Быстрое время выхода на рынок в Windows
2. Возможное развертывание на платформах, отличных от Windows
3. Не должен полагаться на Mono для не Windows

В таком сценарии использование, например, C # для 1 приведет к блокировке 2 и 3 без перезаписи. Таким образом, можно разработать в C ++ / CLI, подходящем объединенном с макросами и шаблонами, чтобы он выглядел максимально похожим на обычный C ++, чтобы достичь reqt 1, а затем, чтобы выполнить reqt 2, потребуется (a) переопределить указанные макросы и шаблоны shenanigans. отобразить в pukka C ++ и (b) реализовать классы .NET Framework, используемые в pukka C ++. Обратите внимание, что (a) и (b) могут быть повторно использованы в будущем, когда это будет сделано один раз.

Самым очевидным возражением будет «ну почему бы тогда не сделать все это на нативном C ++?»; ну, может быть, в обширной библиотеке классов .NET есть много хороших вещей, которые вы хотите использовать, чтобы выйти на рынок как можно скорее.

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