System.UStrClr訪問衝突

使用將舊桌面應用程序移植到RAD Studio 10.1 Berlin。應用程序最後是在C++ Builder 6中建立的（很多很多以前）。System.UStrClr訪問衝突

管理整理所有的組件和外部庫依賴項，但它似乎有一些與Unicode端口一直存在的問題。該應用過去主要依賴內置的String類型，現在對應於AnsiString。

源代碼構建，但二進制在執行任何應用程序代碼之前在某處引發了訪問衝突。錯誤堆棧跟蹤：

[email protected]@@UstrClr$qqrpv + 0x12 
largest_pos 
__linkproc__ Attributebitmaps::Initialize 0x18 
__init_exit_proc 
__wstartup

的largest_pos功能做了一些數字操作 - 沒有任何形式的字符串依賴。

Attributebitmaps是一個靜態類，沒有成員稱爲Initialize。在Delphi中，您可以在單元級別聲明Initialize和Finalize調用，但該構造不在C++ Builder中使用。

任何想法爲什麼在System.UStrClr會發生錯誤？你會去哪裏挖掘更多的洞察力？

來源

2016-06-13 Ryan

在用戶定義的入口點之前運行的代碼通常是靜態初始化程序，並且訪問衝突通常不是靜態對象初始化的未定義順序的結果。 Attributebitmaps類是否依賴於正在初始化的其他靜態對象？ – IInspectable

'Attributebitmaps'是否有'UnicodeString'成員？ 'UStrClr（）'是RTL爲'UnicodeString'變量釋放內存的函數。所以無論是'UnicodeString'變量在發佈之前都會被破壞，或者調用堆棧本身被破壞，並且偶然跳入'UStrClr（）'。無論哪種方式，沒有看到一些真正的代碼沒有辦法diagonose這個。 –

'Attributebitmaps'沒有任何'UnicodeString'成員。它依賴於'TCanvas'和一些相關的VCL類，但沒有任何類型的'String'成員。感謝您的提示。只需要繼續尋找。 – Ryan

相關的在如此衆多的其他職位提到的靜態初始化的慘敗，在這種情況下，罪魁禍首是以下模式：

.h文件：

class SomeClass { 
    static String SOME_STATIC_STRING; 
}; 

String SomeClass::SOME_STATIC_STRING("foo");

如果你選擇使用的這樣的初始化器，它應該被移動到.cpp文件。

來源

2016-06-22 17:42:26 Ryan

System.UStrClr訪問衝突

回答

相關問題