constexpr在 C 20中，只要在背景關系中釋放記憶體，我們就可以在背景關系中分配記憶體——即這是有效的：
constexpr int* g(){
int* p = new int(100);
return p;
}
constexpr int f(){
int* ret = g();
int i = *ret;
delete ret;
return i;
}
static_assert(f() == 100);
而這不會編譯：
constexpr int* g(){
int* p = new int(100);
return p;
}
constexpr int f(){
int* ret = g();
int i = *ret;
return i;
}
static_assert(f() == 100);
出現錯誤：
error: '(f() == 100)' is not a constant expression because allocated storage has not been deallocated
現在這顯然意味著編譯器能夠跟蹤分配和釋放——至少在constexpr背景關系中是這樣。
我可以看到在編譯時控制分配的編譯器如何更好地跟蹤記憶體泄漏，當然，這并沒有說明越界訪問、釋放后使用、雙重釋放等，但是，允許編譯時泄漏檢測的功能肯定constexpr也可以擴展到某種程度的一般編譯時泄漏檢測嗎？
因此我的問題是：是否存在一些基本限制阻止編譯器constexpr在編譯時在非背景關系中執行泄漏檢測，或者該功能被認為是不必要的？
uj5u.com熱心網友回復：
當然，允許編譯時 constexpr 泄漏檢測的功能也可以擴展到某種程度的一般編譯時泄漏檢測？
不，它不能。
編譯時代碼執行意味著編譯器正在執行代碼。那就是“允許編譯時 constexpr 泄漏檢測的功能”：編譯器正在這樣做的事實。
非編譯時執行由編譯器生成的機器代碼控制。到代碼執行時，編譯器早就不在了。為了進行泄漏檢測，編譯器必須在該機器代碼中生成一堆額外的代碼來進行檢查。這會很慢。
此外，編譯時代碼必然受到限制。大多數使這變得困難的技巧都是明確禁止的。僅卡盤reinterpret_cast和它的等價物就消除了問題的整個復雜層。您也不能拋出例外，因此這是您不必考慮的另一個泄漏檢測困難的來源。大多數使泄漏檢測變得困難的事情根本無法在constexpr代碼中完成。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/511328.html
標籤：C 内存泄漏c 20
上一篇：Call使用外部權重圖提升dijkstra最短路徑演算法
下一篇：在編譯時生成一系列空值，后跟一個