/RTC
(執行時間錯誤檢查)
用來啟用和停用執行時間錯誤檢查功能,並搭配 runtime_checks pragma。
語法
/RTC1
/RTCc
/RTCs
/RTCu
引數
/RTC1
相當於 /RTCsu
。
/RTCc
將值指派給較小的資料類型,並導致資料遺失時報告。 例如,它會報告 的型別值 0x0101
是否 short
指派給 類型的 char
變數。
此選項可以報告您想要截斷的情況。 例如,當您想要傳回的前 8 位 int
做為 char
時。 因為 /RTCc
如果指派造成任何資訊遺失,則會導致執行階段錯誤,因此請先遮罩您需要避免執行階段錯誤的資訊。 例如:
#include <crtdbg.h>
char get8bits(unsigned value, int position) {
_ASSERT(position < 32);
return (char)(value >> position);
// Try the following line instead:
// return (char)((value >> position) & 0xff);
}
int main() {
get8bits(12341235,3);
}
因為 /RTCc
會拒絕符合標準的程式碼,所以 C++ 標準程式庫不支援此程式碼。 使用 /RTCc
和 C++ 標準程式庫的程式碼可能會導致編譯器錯誤 C1189 。 您可以定義 _ALLOW_RTCc_IN_STL
讓警告無聲,並使用 /RTCc
選項。
/RTCs
啟用堆疊框架執行時間錯誤檢查,如下所示:
將區域變數初始化為非零值。 此選項可協助識別在偵錯模式中執行時未出現的 Bug。 相較于發行組建,堆疊變數在偵錯組建中仍有零值的可能性更大。 這是因為發行組建中堆疊變數的編譯器優化。 一旦程式使用其堆疊的區域,編譯器永遠不會重設為 0。 這表示任何稍後使用相同堆疊區域的未初始化堆疊變數,都可以傳回先前使用此堆疊記憶體所留下的值。
偵測滿溢和區域變數的不足,例如陣列。
/RTCs
存取結構內編譯器填補所產生的記憶體時,不會偵測滿溢。 使用align
、/Zp
(結構成員對齊)或pack
, 或 如果您以要求編譯器新增填補的方式排序結構元素,可能會發生填補。堆疊指標驗證,可偵測堆疊指標損毀。 堆疊指標損毀可能是因為呼叫慣例不符所造成。 例如,使用函式指標時,您會在匯出為
__stdcall
的 DLL 中呼叫函式,但您會將函式的指標宣告為__cdecl
。
/RTCu
在未初始化的情況下使用變數時報告。 例如,產生警告 C4701 的指令也可能在 下 /RTCu
產生執行階段錯誤。 任何產生 編譯器警告 (層級 1 和層級 4) C4700 的指令,都會在 下 /RTCu
產生執行階段錯誤。
不過,請考慮下列程式碼片段:
int a, *b, c;
if ( 1 )
b = &a;
c = a; // No run-time error with /RTCu
如果變數可能已經初始化,則不會在執行時間報告 /RTCu
。 例如,在變數透過指標進行別名之後,編譯器不會追蹤變數並報告未初始化的用法。 實際上,您可以藉由取得變數的位址來初始化變數。 在此情況下,運算子 &
的運作方式就像指派運算子。
備註
執行時間錯誤檢查是您在執行中程式碼中找出問題的一種方式;如需詳細資訊,請參閱 如何:使用原生執行時間檢查 。
您可以在命令列上指定多個 /RTC
選項。 選項引數可以合併;例如, /RTCcu
與 /RTCc /RTCu
相同。
如果您使用任何 /RTC
編譯器選項在命令列編譯器,則程式碼中的任何 pragma optimize
指令會以無訊息方式失敗。 這是因為執行時間錯誤檢查在發行 (優化) 組建中無效。
用於 /RTC
開發組建;請勿 /RTC
用於發行組建。 /RTC
無法與編譯器優化搭配使用(選項( /O
優化程式碼)。 使用 /RTC
建置的程式映射稍微大一點,而且比建 /Od
置的映射稍微慢一點(最多比 /Od
建置慢 5%) 。
當您 __MSVC_RUNTIME_CHECKS
使用任何 /RTC
選項或 /GZ
時,將會定義預處理器指示詞。
在 Visual Studio 開發環境中設定這個編譯器選項
開啟專案的 [屬性頁] 對話方塊。 如需詳細資料,請參閱在 Visual Studio 中設定 C ++ 編譯器和組建屬性。
選取 [ 組態屬性 > C/C++ > 程式碼產生 ] 屬性頁。
修改下列其中一個或兩個屬性: 基本執行時間檢查 或 較小的類型檢查 。
若要以程式方式設定這個編譯器選項
- 請參閱 BasicRuntimeChecks 和 SmallerTypeCheck 屬性。
另請參閱
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應