C#:显式声明“unsafe”/编译器选项的好处

这里有一篇对C#创建者Anders Hejlsberg的采访,谈到了这个话题 here 基本上,正如@Marc Gravell所说:类型安全第一,明确声明不安全。

编辑:

澄清:我知道什么 “不安全”和“安全”代码是。这只是 为什么我们必须做所有这些 额外的工作(好吧,没有那么多额外的工作)

正如我链接的采访中提到的,这是一个明确的设计决定。C#本质上是Java的进化,在Java中,你根本没有指针。但设计师们希望允许指针;然而,由于C#通常会引入Java开发人员,他们认为最好是 默认

因此,“额外的工作”是故意强迫你在做之前思考你在做什么。通过明确,它迫使你至少考虑:“我为什么要做这个?我做了吗 真的 当引用类型足够时需要指针?"

这主要是关于可验证性。通过陈述 unsafe

这在部分信任(插件等)中更为明显,但在常规代码中仍然很有价值。

能 无论何时调用需要完全信任的代码,或者无论何时使用指针。

从相反的角度考虑:因为它没有标记为不安全,所以你可以推断出大多数代码默认情况下是“安全的”。那么,“安全”是什么意思呢?为了。网络代码,包括(但不限于):

• 垃圾收集器可以照常工作。
• 将 引用该类型的对象(或null)。
• 保证遵守规范。网络信任/安全要求。
• 该代码在数学上被证明不会直接触及其自身AppDomain之外的内存。这可能看起来微不足道,但想象一下,如果你在同一个应用程序中有多个AppDomain。程序员可以自信地将它们视为逻辑上独立的。

对我来说,这类似于C#中的许多语法要求:

• 无断路开关盒

这里有很多很棒的、信息丰富的答案——也许这更符合你的问题。

因此,很明显哪些代码在没有提升权限的情况下不会在web服务中运行,等等。

培养良好的习惯;安全。无论何时在程序集中使用不安全的块,都会要求堆栈提供NativeCode权限。当然,这可以隐式完成,但我们不能也完全删除private关键字吗?我认为强制开发人员在使用不安全代码之前明确要求它是件好事。

安全代码和不安全代码之间最显著的区别是,.net的垃圾收集器无法访问不安全代码。自动GC是.net语言的重要组成部分,当你超越它的界限时,你会改变很多关于代码的假设。