Каковы преимущества выполнения 100% управляемой разработки с использованием C++/CLI?
Каковы преимущества (список возможных недостатков очень длинен) выполнения 100% -ой управляемой разработки с использованием C++/CLI (то есть компиляция с /clr:safe, которая "генерирует... сборки, подобные тем, которые написаны в... C#"))? Особенно при сравнении с C# (обратите внимание, C++/CLI: преимущества по сравнению с C# и есть ли преимущество использования C++ / CLI по сравнению со стандартным C++ или C#? В основном это касается управляемого / неуправляемого взаимодействия).
Например, вот некоторые из моих голов:
C++ - ссылки в стиле для управляемых типов, не такие элегантные, как полномасштабные ненулевые ссылки, но лучше, чем ничего или использующие обходной путь.
шаблоны, которые являются более мощными, чем дженерики
препроцессор (это может быть недостатком!, но макросы могут быть полезны для генерации кода)
семантика стека для ссылочных типов - автоматический вызов IDisposable::Dispose()
более простая реализация Dispose () через деструктор C++
В C# 3.0 добавлены автоматически реализованные свойства, так что это больше не является преимуществом C++ / CLI.
7 ответов
В C++/CLI вы можете определять функции вне классов, вы не можете делать это в C#. Но я не знаю, является ли это преимуществом
Я думаю, что единственным большим преимуществом является управляемое / неуправляемое взаимодействие. Написание чисто управляемого C++/CLI (по крайней мере для меня) без взаимодействия с C# или другими языками.Net кажется полностью упущенным. Да, вы могли бы сделать это, но почему бы вам.
Если вы собираетесь писать чистый управляемый код, почему бы не использовать C#. Особенно (как сказал nobugs), если VS2010 отказывается от поддержки IntelliSense для C++/CLI. Также в VS2008 IntelliSense для C++/CLI не так хорош, как C# IntelliSense; так что с точки зрения разработчика легче работать / изучать / реорганизовывать в C#, чем в C++/CLI.
Если вам нужны перечисленные вами преимущества C++, такие как препроцессор, семантика стека и шаблоны, то почему бы не использовать C++?
Странно, мне нравится C++/CLI, но вы перечислили именно те функции, которые мне не нравятся. Моя критика:
- Хорошо. Но случайное использование шляпы довольно широко распространено, поэтому значение типа значения помещается в рамку без предупреждения. Нет возможности диагностировать эту ошибку.
- Мощь, которая стоит дорого, написанные вами шаблоны не могут использоваться ни на каком другом языке.NET. Во всяком случае, это ухудшает проблему экспорта шаблона C++. Также стоит задуматься над полным провалом STL/CLR.
- Хм, нет
- Это была ИМО серьезная ошибка. Уже сложно избежать проблем со случайным боксом, как указано в первом пункте. Семантика стека серьезно затрудняет любой начинающий программист. Это было дизайнерское решение, чтобы успокоить программистов на C++, это нормально, но оператор using был лучшим решением.
- Не уверен, как это проще. Вызов GC.SuppressFinalize() автоматический, вот и все. Кто-нибудь очень редко пишет финализатор, но вы не можете избежать автоматически сгенерированного кода от вызова. Это неэффективно и является нарушением принципа "вы не платите за то, что не используете". Добавьте к этому, что написание деструктора также заставляет автоматически генерировать финализатор по умолчанию. Тот, который вы никогда не будете использовать и не захотите использовать, если вы забыли или не использовали деструктор.
Ну, это все возможно очень субъективно. Смертельный звонок будет поставляться с VS2010, он будет поставляться без поддержки IntelliSense для C++/CLI.
Как и другие здесь, я не могу вспомнить какие-либо общие случаи, когда существует явное преимущество, поэтому мое мышление перешло к ситуативным преимуществам - есть ли случаи, когда есть преимущество в конкретном сценарии?
Преимущество: использование навыков технического персонала C++ в сценарии быстрого прототипирования.
Позвольте мне уточнить...
Я довольно много работал с учеными и (не программирующими) инженерами, которые не являются формально обученными программистами. Многие из этих людей используют C++ для разработки специальных модулей, включающих физику / математику высокого уровня. Если в сценарии быстрого прототипирования требуется чистый модуль.NET и набор навыков ученого / инженера, ответственного за модуль, - C++, я бы научил их небольшому количеству дополнительного синтаксиса (public ref, ^ а также % а также gcnew) и заставить их программировать свой модуль как 100% управляемую C++/CLI DLL.
Я признаю, что есть целая куча возможных ответов "Да, но...", но я думаю, что использование набора технических навыков C++ технического персонала является возможным преимуществом C++/CLI.
Вы можете иметь перечисления и делегаты как общие ограничения в C++/CLI, но не в C#.
В C# есть библиотека для имитации этих ограничений.
Я согласен с тем, что вы упомянули, и в качестве примера использования препроцессора указывают на: Boost Preprocessor library для генерации набора типов на основе списка базовых типов, например PointI32, PointF32 и т. Д. В C++/CLI.
Можно представить следующие требования к гипотетическому продукту:
- Быстрое время выхода на рынок в Windows
- Возможное развертывание на платформах, отличных от Windows
- Не должен полагаться на 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 есть много хороших вещей, которые вы хотите использовать, чтобы выйти на рынок как можно скорее.
Я признаю, что все это немного ненадежно, поэтому я очень сомневаюсь, что это когда-либо было сделано, но было бы забавно попробовать!