Core Foundation爲每次調用CFSTR創建一個內存泄漏（）

Question

我通常使用CFSTR（）宏從標準C字符串創建一個CFString對象，直到經過多次測試並更好地檢查文檔後，我意識到每次調用這個函數會自動創建一個內存泄漏，直到程序終止。即使在應用程序關閉後，可視檢漏儀仍會將內存報告爲未釋放。 對CFRetain，CFRelease的任何調用都不會影響內存。 由於我進行了大量調用，我想知道是否應該使用CFStringCreateWithCString，與CFSTR不同，內存在調用CFRelease（也從內存泄漏檢測工具報告）完全釋放之後。

感謝

更新（在回覆評論）： 我在Windows，我直接使用官方的CoreFoundation庫從我的C++應用程序。爲了識別內存泄漏，我使用OpenCfLite，因爲源代碼是相同的，但允許我也包含Visual Leak Detector頭，或者也可以只使用內置的Visual Studio泄漏檢測程序。當我關閉應用程序時，我會得到一份完整的報告，我可以清楚地看到內存地址及其內容。我可以從報告中看到傳遞給CFSTR（= __ CFStringMakeConstantString）的字符串仍然位於內存地址處。 這似乎並非是一個錯誤或東西我做錯了，但只是正常的行爲，因爲蘋果指出：「從CFSTR返回的值不被CFString字符串釋放，保障他們在程序終止之前是有效的。」

樣品電話： CFSTR（ 「這個字符串已經從__CFStringMakeConstantString函數創建」）

---------------這是微軟轉儲內置泄漏檢測器：-------------------

檢測到內存泄漏！

傾銷對象 - >

C：\項目\ cftest \ cftest \ cfbase.c（277）：{61}在0x00A01648正常塊，96個字節長。

數據：< GThis ST> 00 00 00 00 8C 07 00 00 47 54 68 69 73 20 73 74

對象轉儲完成。

---------------這是從VLD工具轉儲：---------------

---------- 1座在0x04AD2FE8：4096個字節----------

調用堆棧：

0x77D89950 (File and line number not available): ntdll.dll!RtlQueryEnvironmentVariable + 0x241 bytes 
0x77D8D8C9 (File and line number not available): ntdll.dll!LdrResSearchResource + 0xB4D bytes 
0x77D8D78C (File and line number not available): ntdll.dll!LdrResSearchResource + 0xA10 bytes 
0x77D8C4D5 (File and line number not available): ntdll.dll!LdrLoadDll + 0x7B bytes 
0x772A2288 (File and line number not available): KERNELBASE.dll!LoadLibraryExW + 0x1F1 bytes 
0x6FA4DF32 (File and line number not available): clr.dll!GetCLRFunction + 0x895F bytes 
0x6FA4DFAD (File and line number not available): clr.dll!GetCLRFunction + 0x89DA bytes 
0x6FC4ECF0 (File and line number not available): clr.dll!CorLaunchApplication + 0x17DB0 bytes 
0x6F9F421B (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x524C bytes 
0x6F9F42E2 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5313 bytes 
0x6F9F3FE4 (File and line number not available): clr.dll!StrongNameSignatureVerification + 0x5015 bytes 
0x6F9AD323 (File and line number not available): clr.dll!LogHelp_NoGuiOnAssert + 0x17457 bytes 
0x6FA57D55 (File and line number not available): clr.dll!GetCLRFunction + 0x12782 bytes 
0x6F9C52D5 (File and line number not available): clr.dll!LogHelp_TerminateOnAssert + 0x16F1D bytes 
0x023D0882 (File and line number not available): (Module name unavailable)!(Function name unavailable) 
0x00370AF3 (File and line number not available): (Module name unavailable)!(Function name unavailable) 
0x6CC8CEA3 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3A4D34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C397BBB (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3979B8 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3A3B37 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C399828 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3A285A (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3A3A60 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C3A26D9 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C399513 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C399491 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x6C8F9B34 (File and line number not available): System.Windows.Forms.ni.dll!(Function name unavailable) 
0x023D0E7B (File and line number not available): (Module name unavailable)!(Function name unavailable) 
0x767262FA (File and line number not available): USER32.dll!gapfnScSendMessage + 0x332 bytes 
0x76726D3A (File and line number not available): USER32.dll!GetThreadDesktop + 0xD7 bytes 
0x76726DE8 (File and line number not available): USER32.dll!GetThreadDesktop + 0x185 bytes 

........ GThis.st

72 69 6E 67 20 68 61 73 20 62 65個65 6E 20 63 72 ring.has .been.cr

65 61 74 65 64 20 66 72 6F 6D 20 5F 5F 43 46 53 eated。 fr。__CFS

74 72 69 6E 67 61 4D 65 6B 43 6F 6E 73 74 61 6E tringMak eConstan

74 53 74 72 69 6E 67 20 66 75 6E 63 74 69 6F 6E tString。功能

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

現在，我可以很容易地避免所有的上面的問題通過用CFStringCreateWithCString替換對CFSTR的調用，我確信沒有內存泄漏（至少只要我記得調用CFRelease），但我想知道爲什麼很多代碼示例顯示大量使用如果對該函數的每次調用都將該字符串存儲在內存中，則只有在程序終止時纔可以釋放該內存。

感謝

Answer 1

你的問題也回答here我想。 如果您要創建大量的唯一字符串，則應該使用CFStringCreateWithCString和CFRelease。另一方面，如果唯一字符串的數量很少（比如100），那麼使用CFSTR就沒有問題。