使用C++进行100%管理开发有什么优点?

在C++/CLI中,你可以在类外定义函数,在C语言中你不能这样做。但我不知道这是不是一个优势

我认为最大的优势是托管/非托管互操作。编写纯管理的C++/CLI(至少对我来说),而不与C语言或其他.NET语言进行交互似乎完全忽略了这一点。是的,你可以这么做,但你为什么要这么做。

如果要编写纯托管代码,为什么不使用c。特别是(如NoBug所说),如果VS2010降低了C++/CLI的智能感知支持。同样在VS2008中,C++/CLI的智能感知不如C语言智能化好,因此从开发人员的角度来看,C语言中的工作/探索/重构比C++/CLI更容易。

如果你想要一些C++的好处,比如预处理器、栈语义和模板,那么为什么不使用C++呢?

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

• 可以。但是,意外使用帽子的情况相当普遍,在没有警告的情况下将值类型的值装箱。没有办法诊断这个错误。
• 你所编写的模板在任何其他.NET语言中都不可用。如果有什么问题,它会恶化C++模板导出问题。stl/clr的完全失败也值得深思。
• 呃,不。
• 这是我的一个严重错误。已经很难避免意外拳击的问题,如第一个子弹所述。堆栈语义使得任何一个初学者都很难解决这个问题。这是一个安抚C++程序员的设计决定,没关系,但是使用语句是一个更好的解决方案。
• 不知道怎么容易。suppressFinalize()调用是自动的,仅此而已。它是 非常 很少有人会编写终结器,但您无法避免自动生成的代码进行调用。这是低效的,违反了“不使用就不用付钱”的原则。除此之外,编写析构函数还强制自动生成默认终结器。如果你忘记或忘记使用析构函数,你就永远不会使用也不想使用它。

好吧,这可能都很主观。死亡丧钟将与VS2010一起到来,它将在没有智力支持的情况下对C++/CLI进行航行。

和这里的其他人一样,我无法想象任何存在明显优势的一般情况,所以我的思维转向了情境优势——在特定场景中是否存在优势?

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

让我详细说明一下…

我曾与科学家和(非软件)工程师共事过很多,他们都不是经过正式培训的程序员。这些人中的许多人使用C++来开发涉及高端物理/数学的特定模块。如果在快速原型方案中需要纯.NET模块,负责模块的科学家/工程师的技能集是C++,那么我将教给他们少量的附加语法。 public ref , ^ 和 % 和 gcnew 并让他们把他们的模块编程为一个100%管理的C++/CLI DLL。

我承认有一大堆可能的“是的,但是…”的响应,但是我认为利用C++技术团队的技术人员是C++的一个可能的优势。

我同意您所提到的,作为预处理器使用的一个例子,请指向: Boost Preprocessor library for generating a set of types based on a list of basic types e.g. PointI32, PointF32 etc. in C++/CLI

可以将枚举和委托作为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. 非Windows不能依赖Mono

在这种情况下,使用eg c for 1会在不重写的情况下妨碍2和3。因此,可以在C++/CLI中开发,适当地用宏和模板ShanaIGANS使其看起来尽可能像普通C++,以击中Reqt 1,然后命中Reqt 2,需要(a)重新实现所述宏和模板ShanaIGANS,以映射到PUKKA C++和(b)实现.NETFramework类。在PUKKA C++中使用。注意(a)和(b)一旦完成一次就可以在将来重用。

最明显的反对意见是:“那么为什么不在C++中做整个事情呢?”;好吧,也许在巨大的.net类库中有很多好东西,你想用它们尽快上市。

我承认这一切都有点牵强,所以我非常怀疑这件事是否真的做过,但尝试一下会很有趣!