Различные значения _fileName в отладке Visual Studio

Question

std :: string filename;

В этом коде: osg::Image* image = osgDB::readImageFile(filename + ".dicom");

OSG :: Изображение переменная типа: изображение получает неправильно возвращаемые значения из файла для чтения. И отладки в строку выше, окно часов показывает следующее:

_fileName (станд :: строка типа) значение, указанное на первые и вторые линиях как «переварить», но в четвертой строке Значение _fileName оказалось «iiiiii \ x * 6» с емкостью равным 0.

По моему мнению, _fileName четвертой строки в окне просмотра должно указывать ту же переменную члена osg :: Image как _fileName на первой и второй строках. Таким образом, я думаю, что все _fileName в окне просмотра отладки должны иметь одинаковое значение. Но я не уверен, почему существуют такие различия.

Answer 1

MSVC++ реализация std::string использует различные стратегии хранения для коротких строк и для длинных. Короткие строки (16 байт или меньше) хранятся в буфере, встроенном непосредственно в объект std::string (вы увидите его как _Bx._Buf в Raw View). Длинные строки хранятся в отдельно выделенном блоке памяти, расположенном в другом месте (указывается _Bx._Ptr).

Если вы нарушите целостность объекта std::string, вы можете легко оказаться в ситуации, описанной вами. Объекты считают, что данные должны храниться во внешнем буфере, но на самом деле они хранятся во внутреннем и наоборот. Это может смутить и отладчик.

Предлагаю открыть исходный вид вашего объекта std::string и посмотреть, что он показывает в _Bx._Buf и _Bx._Ptr. Если текущее значение _Myres меньше или равно размеру внутреннего буфера, тогда данные [предполагается] будут храниться во внутреннем буфере. В противном случае он сохраняется во внешнем блоке памяти. Посмотрите, действительно ли этот инвариант. Если это не так, тогда есть ваша проблема. Тогда вам нужно будет найти, в какой момент он сломался.

Answer 2

По какой-то причине ваш аргумент имени файла не получает .dicom, прикрепленный к нему, когда он становится _filename («дайджест» должен стать «digest.dicom»). OSG решает, какой плагин использовать для загрузки файлов по расширению, поэтому он не знает, как загрузить текущий. И поэтому вторая ссылка на _filename не может быть проинсталлирована каким-либо плагином.

Кстати, я не думаю, что плагин dicom является частью стандартного пакета OSG - вам, возможно, придется самостоятельно собрать зависимости и построить плагин.