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

std::string имя файла;

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

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

Значение _fileName (тип std::string), указанное в первой и второй строках, равно "digest", но в четвертой строке значение _fileName оказалось "iiiiii\x*6" с емкостью, равной 0.

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


c++ visual-studio debugging openscenegraph
person lightrek    schedule 04.12.2014    source источник
comment
Похоже, что есть два члена с именем _fileName в двух разных классах.   -  person n. 1.8e9-where's-my-share m.    schedule 04.12.2014
comment
если filename (в качестве параметра функции readImageFile) равно char *, то вы пытаетесь добавить два указателя (filename и ".dicom"), и если это так, результат может быть неопределенным   -  person borisbn    schedule 04.12.2014
comment
имя файла и _fileName имеют тип std::string   -  person lightrek    schedule 04.12.2014
comment
Можете ли вы загрузить и визуализировать изображение? Это неправильный образ?   -  person Adri C.S.    schedule 10.12.2014
comment
Что показывает Raw view?   -  person AnT    schedule 11.12.2014

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person AnT    schedule 11.12.2014

arrow_upward
1
arrow_downward

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

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

person Ruan Caiman    schedule 11.12.2014