Visual Studio調試手錶中的不同_fileName值

std :: string filename;Visual Studio調試手錶中的不同_fileName值

在此代碼：osg::Image* image = osgDB::readImageFile(filename + ".dicom");

OSG ::圖片類型變量：圖像獲取錯誤從讀取文件的返回值。並通過調試上述線，手錶窗口顯示如下： enter image description here

的_filename（的std :: string型）在第一線和第二線都被「消化」指示值，但在第四行的_fileName的值原來是「iiiiii \ x * 6」，容量等於0.

根據我的理解，監視窗口中第四行的_fileName應該表明同一個成員變量osg :: Image作爲第一行和第二行上的_fileName。因此，我認爲調試監視窗口中的所有_fileName應具有相同的值。但是，我不確定爲什麼會有這種差異。

2014-12-04 lightrek

它看起來像兩個不同的類中有兩個名爲_fileName的成員。 – 2014-12-04 06:21:01

如果'filename'（作爲函數'readImageFile'的參數）是'char *'，那麼你試圖添加兩個指針（'filename'和'「.dicom」'），如果是，結果可能是undefined – borisbn 2014-12-04 06:54:27

文件名和_fileName都是std :: string類型 – lightrek 2014-12-04 13:43:16

std::string的MSVC++實現對短字符串和長字符串使用不同的存儲策略。短字符串（16字節或更少）存儲在直接嵌入std::string對象內的緩衝區中（您將在原始視圖中將其視爲_Bx._Buf）。長字符串存儲在位於別處的獨立分配的內存塊中（由_Bx._Ptr指出）。

如果您違反std::string對象的完整性，您可能很容易就以您描述的情況出現。對象認爲數據應該存儲在外部緩衝區中，但實際上它存儲在內部緩衝區中，反之亦然。這可能很容易混淆調試器。

我建議您打開std::string對象的原始視圖，並檢查它在_Bx._Buf和_Bx._Ptr中顯示的內容。如果當前的_Myres值小於或等於內部緩衝區大小，則數據[應該]存儲在內部緩衝區中。否則，它被存儲在外部存儲器塊中。看看這個不變量是否真的成立。如果沒有，那麼你的問題。然後，你只需要找到它在哪一點被打破。

來源

2014-12-11 18:52:06 AnT

由於某些原因，當文件名參數變爲_filename（「摘要」應該變爲「digest.dicom」）時，它的附加文件名參數不會被附加到它。 OSG根據擴展名決定使用哪個插件來加載文件，因此它不知道如何加載當前插件。因此，對_filename的第二次引用不會被任何插件初始化。

順便說一下，我不認爲dicom插件是標準OSG預構建軟件包的一部分 - 您可能必須自己收集依賴關係並構建插件。

來源

2014-12-11 18:39:23

Visual Studio調試手錶中的不同_fileName值

回答

相關問題