使用C ++ / CLI进行100%托管开发有什么好处?

使用C ++ / CLI进行100%托管开发有哪些优点(可能存在的缺点列表)(即使用/ clr:safe编译,“生成…程序集,就像用C#编写的那样”) )? 特别是在考虑C#时(注意C ++ / CLI:优于C#的 优势,使用C ++ / CLI相比标准C ++或C#有什么优势?主要是关于托管/非托管互操作)。

例如,这里有一些我的头脑:

  • C ++ – 托管类型的样式引用 ,不像完整的非可空引用那样优雅,但总比没有好或使用解决方法 。

  • 模板比generics更强大

  • 预处理器(这可能是一个缺点!,但宏可用于代码生成)

  • 引用类型的堆栈语义 – 自动调用IDisposable :: Dispose()

  • 通过C ++析构函数更容易实现Dispose()

C#3.0添加了自动实现的属性,因此不再具有C ++ / CLI优势。

在C ++ / CLI中,您可以在类之外定义函数,但不能在C#中执行此操作。 但我不知道这是否有利

我认为最大的单一优势是托管/非托管互操作。 在没有使用C#或其他.Net语言的情况下编写纯托管C ++ / CLI(至少对我而言)似乎完全忽略了这一点。 是的,你可以做到这一点,但你为什么要这样做。

如果您要编写纯托管代码,为什么不使用C#。 特别是(如nobugs所说)如果VS2010放弃了对C ++ / CLI的IntelliSense支持。 同样在VS2008中,用于C ++ / CLI的IntelliSense不如C#IntelliSense好; 所以从开发人员的角度来看,在C#中工作/探索/重构比在C ++ / CLI中更容易。

如果您希望列出一些C ++好处,如预处理器,堆栈语义和模板,那么为什么不使用C ++?

奇怪,我喜欢C ++ / CLI,但你列出了我不喜欢的function。 我的批评:

  • 好的。 但是偶然使用帽子非常普遍,在没有警告的情况下获取值类型的值。 没有办法诊断这个错误。
  • 高价的电源,您编写的模板不能用于任何其他.NET语言。 如果有的话,它会恶化C ++模板导出问题。 STL / CLR的彻底失败也值得深思。
  • 呃,不。
  • 这是IMO的一个严重错误。 如第一个项目中所述,已经很难避免意外拳击的问题。 堆栈语义使任何初学程序员都很难对其进行排序。 这是一个安抚C ++程序员的设计决定,没关系,但using语句是一个更好的解决方案。
  • 不知道如何更容易。 GC.SuppressFinalize()调用是自动的,就是这样。 任何人编写终结器都是非常罕见的,但您无法避免自动生成的代码进行调用。 这是低效率的,违反了“你不为你不使用的东西付费”的原则。 除此之外,编写析构函数还会强制自动生成默认终结器。 如果您忘记或省略使用析构函数,那么您永远不会使用它并且不希望被使用。

嗯,这或许都是非常主观的。 VS2010将会出现死亡事件,它将在没有智能感知支持的情况下发布,而不支持C ++ / CLI。

像其他人一样,我无法想到存在明显优势的任何一般情况,因此我的思维转向情境优势 – 在特定情况下是否存在优势?

优势:在快速原型设计方案中利用技术人员的C ++技能。

让我详细说明……

我和那些没有经过正式培训的程序员的科学家和(非软件)工程师一起工作了很多。 其中许多人使用C ++开发涉及高端物理/数学的特定模块。 如果在快速原型设计场景中需要纯.NET模块,并且负责模块的科学家/工程师的技能集是C ++,我会教他们少量的附加语法( public ref^% and gcnew )和让他们将他们的模块编程为100%托管的C ++ / CLI DLL。

我认识到有一大堆可能的“是的,但是……”的回复,但我认为利用C ++技术人员的技能组合是C ++ / CLI的一个可能优势。

我同意你提到的内容,并作为预处理器使用的一个例子指向: Boost预处理器库,用于根据基本类型列表生成一组类型,例如C ++ / CLI中的PointI32,PointF32等

您可以将枚举和委托作为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/

可以想象一个假设产品的以下要求:

  1. 在Windows上快速上市
  2. 最终部署到非Windows平台
  3. 不能依赖Mono用于非Windows

在这种情况下,使用例如C#为1会使你在2和3时无法重写。 因此,可以用C ++ / CLI开发,适当地使用宏和模板恶作剧,看起来像普通的C ++一样,命中要求1,然后达到要求,需要(a)重新实现所述的宏和模板恶作剧映射到pukka C ++和(b)实现pukka C ++中使用的.NET框架类。 注意,一旦完成一次,(a)和(b)可以在将来重复使用。

最明显的反对意见是“为什么不在原生C ++中完成整个事情呢?”; 好吧,也许在你想要用来尽快进入市场的庞大.NET类库中有很多好东西。

我承认,这一点有点脆弱,所以我非常怀疑这件事是否已经完成,但试一试会很有趣!