您应该在C#中使用指针(不安全代码)吗?

问题描述 投票:43回答:11

您应该在C#代码中使用指针吗?有什么好处?微软推荐吗?

c# .net pointers coding-style unsafe
11个回答
37
投票

来自“男人”本人:

在C#中很少需要使用指针,但是在某些情况下需要使用它们。例如,在以下情况下,可以使用不安全的上下文来允许指针:

  • 处理磁盘上的现有结构
  • 涉及包含指针的结构的高级COM或平台调用方案
  • 关键性能代码

不建议在其他情况下使用不安全的上下文。

特别是,不安全的上下文不应用于尝试用C#编写C代码。

注意:

使用不安全的上下文编写的代码不能被验证为安全的,因此只有在完全信任代码的情况下才会执行该代码。换句话说,不安全的代码不能在不受信任的环境中执行。例如,您不能直接从Internet运行不安全的代码。

Reference


1
投票

1
投票
“随便注意拐角处的警察。” WSM

22
投票

如果需要。

假设您需要对大型灰度图像(例如2000x2000像素)进行假彩色处理。首先使用GetPixel()SetPixel()编写“安全”版本。如果可行,那就继续吧。如果证明速度太慢,则可能需要了解构成图像的实际位(为方便起见,请忽略颜色矩阵)。使用不安全的代码没有什么“坏”之处,但是它增加了项目的复杂性,因此仅在必要时使用。


13
投票

我不记得要这么做了-但是我没有做太多的互操作。我相信,这是最常见的应用程序:调用本机代码。在极少数情况下,使用指针可以使您优化某些代码,但是根据我的经验,这很少见。

[如果有任何指导,我认为自己在C#方面很有经验,但是如果我必须执行任何不安全的代码,则必须查阅spec / books / MSDN来指导我。当然,会有很多人对不安全的代码感到满意,但对(例如)查询表达式不那么了解...


6
投票

我会说主要问题是:-

  • 不安全的代码无法验证。这意味着用户可以在完全信任的上下文中运行代码[[only,因此,如果您需要用户从比完全不信任的地方运行代码(例如,网络共享未配置为这样) , 你完蛋了。
  • 缺乏可验证性(不确定这是否是一个单词)也意味着您可以
  • 潜在地
  • 弄乱程序中的内存。您正在[[潜在地将整个错误类别带回到您的应用程序中-缓冲区溢出,悬空指针,yada yada yuck yuck。更不用说可能会破坏内存中的数据结构而不会意识到指针何时变得怪异。[如果您希望不安全的代码访问托管对象,则需要对其进行“固定”。这意味着不允许GC在内存中移动对象,因此托管堆可能变得碎片化。这会影响性能。因此,确定此问题是否不会抵消任何潜在的性能提升总是很重要的。对于不习惯非托管方法的程序员,您的代码将变得更难以理解。这样一来,他们可能更容易因不安全的“自由”代码给他们的脚而感到震惊。
  • 您将能够编写非类型安全的代码;这确实消除了一种很好的温暖模糊管理语言的许多优势。现在,您将遇到可怕的类型安全问题。为什么向后退一步?
  • 它使您的代码
  • uglier
  • 我确定还有更多可以添加到列表中;就像其他人所说的那样-除非有必要,否则请避免。通过p / invoke调用非托管方法,这需要一些特殊的指针操作。即使那样,封送员也会在很大程度上阻止对它的需要。'男人'基本上也说避免,除非必要。

    哦,关于固定here on MSDN的不错的文章。


  • 3
    投票
    话虽如此,我认为

    大多数这里的人们会说“不做”。绝大多数.NET开发人员在正常活动中不会遇到只能通过使用不安全代码解决的情况。


    3
    投票

    2
    投票
    Microsoft推荐他们是C#的设计师,因此他们决定增加在其中编写unsafe代码的功能。从关键字的选择以及使用关键字描述在其中编写方法/类的要求中可以看出,它并不是实际的实现选择。

    2
    投票
    在结构上使用一些有用的,有充分根据的c或C ++惯用函数,您需要将它们视为已知长度的字节*,这对散列也是最有用的。

    [坦率地说,对存储结构中的(非常特定的)极其快速的二进制序列化(通过对它们的数组进行处理),尽管说实话,最好只使用C ++ / CLI。

    必须说,在许多情况下,可以通过在C ++ / CLI中完成处理指针的任务,然后将其作为dll导入到c#项目中来更好地解决。它不会改变代码是否“安全”,但是它使使用基于指针的结构的大量有用函数更易于访问。如果您确实愿意,它还可以使您迷惑通用类型或枚举。

    大多数开发人员需要这样做的可能性确实很小。不过,当您需要时很有用...


    1
    投票
    © www.soinside.com 2019 - 2024. All rights reserved.