C＃：明確聲明“不安全”/編譯器選項的好處

Question

我理解指針，並且很少需要在C＃代碼中使用它們。 我的問題是：在一段代碼中明確說明“不安全”的原因是什么。 另外，為什么必須更改編譯器選項以允許“不安全”代碼？

結論： CLR（或語言規范）中的內容使得我們不能隨時使用指針（很像C和C ++）而不必鍵入“unsafe”並更改編譯器選項？

澄清一下：我知道“不安全”和“安全”的代碼是什么。 這只是一個問題，為什么我們必須做所有額外的工作（好吧，不是那么多）只是為了能夠使用這些功能。

Answer 1

還有用C＃創建者安德斯·海爾斯伯格，關於該主題觸及的采訪這里 。 基本上，正是@Marc Gravell所說的：首先是類型安全，通過明確聲明不安全。

所以回答你的問題：CLR中沒有任何東西阻止它; 它是一種語言習語，旨在讓您在處理類型時使用安全手套。 如果你想脫下手套，這是你的選擇，但你必須做出積極的選擇才能脫下手套。

編輯：

澄清一下：我知道“不安全”和“安全”的代碼是什么。 這只是一個問題，為什么我們必須做所有額外的工作（好吧，不是那么多）只是為了能夠使用這些功能。

正如我所接受的采訪中提到的那樣，這是一個明確的設計決定。 C＃本質上是Java的演變，在Java中，你根本就沒有指針。 但設計師想要指點; 但是因為C＃通常會引入Java開發人員，他們認為如果默認行為與Java類似，即沒有指針，同時仍允許通過顯式聲明使用指針，那將是最好的。

所以“額外的工作”是故意強迫你在做之前考慮你在做什么。 通過明確，它迫使你至少考慮：“為什么我這樣做？當引用類型足夠時，我真的需要一個指針嗎？”

Answer 2

它主要是關於可驗證的。 通過聲明unsafe ，手套關閉 - 系統無法再保證您的代碼不會失控。 在大多數情況下，非常希望留在安全區。

部分信任（插件等）會更加明顯，但在常規代碼中仍然很有用。

Answer 3

實際上CLR對於/ unsafe開關或關鍵字沒有任何要求。 事實上，C ++ / CLI（在CLR下運行的C ++語言）沒有這樣/不安全的開關，並且指針可以在CLR上自由使用。

所以我將你的問題改為“為什么C＃在使用指針之前需要使用/ unsafe？” 這個問題的答案如此處給出的其他答案中所述：幫助用戶有意識地決定失去在CLR上以低於完全信任模式運行的能力。 C ++實際上總是需要CLR上的完全信任，並且無論何時調用需要完全信任的代碼，或者無論何時使用指針，C＃ 都可以 。

Answer 4

當您使用不安全的塊時，它會使代碼無法驗證。 這需要執行某些權限，您可能不希望在輸出中允許它（特別是如果您在共享源環境中），因此編譯器中有一個禁止它的開關。

Answer 5

從相反的角度考慮它：因為它沒有標記為不安全，你可以推斷大多數代碼默認是“安全的”。 那么“安全”是什么意思呢？ 對於.Net代碼，這包括（但可能不限於）：

• 垃圾收集器可以照常開展業務。
• 對特定類型的引用將引用該類型的對象（或null）。
• 代碼保證符合.Net信任/安全要求。
• 從數學上證明代碼不會直接觸及它自己的AppDomain之外的內存。 這看起來似乎微不足道，但想象一下，如果您在同一個應用程序中有多個AppDomain。 程序員可以自信地將它們視為邏輯上獨立的。

無論何時使用指針，您都有機會破壞任何這些保證。 因此將代碼標記為不安全會放棄這些保護。

Answer 6

簡而言之，.NET希望您說明您的意圖。

當然，編譯器可以推斷出對“不安全”標志的需求。 但設計師希望它是一個刻意的決定。

對我而言，它類似於C＃中的一些語法要求：

• 沒有休息的開關箱
• 沒有訪問級別的“部分”（例如C ++中的“public：”標記）
• 沒有使用“var”的類字段

模式是你不應該移動或改變一件事而無意中影響另一件事。 在合理的范圍內，他們希望阻止你“射擊自己的腳”。

這里有很多很好的，信息豐富的答案 - 也許這更適合你的問題。

Answer 7

因此，很明顯，如果沒有提升權限等，哪些代碼將無法在Web服務中運行。

Answer 8

培養良好的習慣和安全。 每當在程序集中使用不安全的塊時，都會從堆棧中請求NativeCode權限。 這當然可以隱式完成，但我們不能完全刪除private關鍵字嗎？ 我認為強迫開發人員在使用之前特別要求不安全的代碼是件好事。

Answer 9

安全和不安全代碼之間最顯着的區別是.net的垃圾收集器無法訪問不安全的代碼。 自動GC是.net白話的一個重要組成部分，當你超越它的界限時，你會改變很多可以假設的代碼。

特別是指針允許在堆上創建沒有GC引用的對象。 這導致另一個很好的理由要求將代碼標記為“不安全”。 當您意識到存在內存泄漏時，可以輕松縮小內存泄漏的范圍。