stl :: карта вопросов

Question

Это, должно быть, я делаю что-то глупое, но кто-нибудь видел такое поведение раньше:

У меня есть карта в классе, определенная так:

std::map <const std::string, int> m_fCurveMap;

все ведет себя хорошо вотладка, но все идет не так в режиме выпуска.карта инициализируется каким-то сумасшедшим числом: m_fCurveMap [14757395258967641292]()

Любой член, который у меня есть после карты, будет полностью поврежден, то есть, если я добавлю int после строки карты следующим образом:

std::map <const std::string, int> m_fCurveMap;
int m_myIntThing;

и в моих конструкторах установите для m_myIntThing значение 0, после вызова конструктора m_myIntThing - это какое-то безумное число.Если я переместу m_myIntThing в строку над картой, все для m_myIntThing в порядке.Это приводит к большим проблемам для меня в дальнейшем.Нужно ли что-то делать с картой в моем конструкторе?Я не в данный момент.

Я использую Visual Studio, это прекрасно работает с GCC.Я вижу только проблему в выпуске.Этот проект - длл.

Если вы уже видели подобное безумие, пожалуйста, помогите ему свести меня с ума.: -)

Большое спасибо, Марк

Answer 1

Это случалось со мной много раз. Хотя это трудно сказать в вашем случае, очень вероятная причина в том, что у вас есть разные версии библиотеки времени выполнения C между разными проектами. Проверьте вкладку «Генерация кода» в настройках компилятора для разных проектов и убедитесь, что они совпадают.

Фактически происходит то, что разные версии библиотек времени выполнения C по-разному реализуют контейнеры STL. Затем, когда разные проекты пытаются общаться друг с другом, значение того, что такое, например, std :: map, изменилось и перестало быть двоично-совместимым.

Странное поведение, скорее всего, какое-то повреждение кучи, или, если оно передается в качестве параметра функции, повреждение стека.

Answer 2

Если вы получаете информацию от отладчика VS, я бы не стал доверять тому, что он говорит вам о Release DLL. Отладчику действительно можно доверять только с помощью DLL отладки.

Если вывод программы говорит вам об этом, значит, это не так - в этом случае вы не предоставляете достаточно информации.

Answer 3

Проблема в некотором повреждении памяти.

Ошибка, которую я часто видел в проектах C ++, заключается в использовании объекта после его удаления.

Другая возможность - переполнение буфера.,Это может быть любой объект в том же стеке или рядом в куче.

Довольно хороший способ поймать виновника - установить точку останова отладчика, которая запускается при изменении памяти.Пока объект все еще в порядке, установите точку останова.Затем подождите, пока какой-нибудь код не записывает в эту область памяти.Это должно раскрыть вашу ошибку.

Answer 4

Просто приведу конкретный пример повреждения памяти:

typedef std::map<int, int> mymap_t;

static mymap_t static_init() { return mymap_t(); }

class foo {
   foo(): mymap(static_init()) {}

   //!> d'oh, don't reference!
   const mymap_t &mymap;
};

Случайно я определил ref для переменной-члена, а не для самой переменной-члена. Он инициализируется нормально, но как только область действия static_init () будет оставлена, карта будет уничтожена, и ссылка будет просто отображаться в отладке как "std :: map с 140737305218461 элементами" (довольно печатными) или подобными ей. указывает на нераспределенную память (или хуже).

Остерегайтесь случайных ссылок!

Answer 5

У меня была точно такая же проблема на g ++, я решил ее, удалив прагмы из параграфа прагмы перед этим.Несмотря на то, что код верный, мне интересно, если это ошибка компилятора на платформе, которая появляется при использовании stl :: map в некоторых ситуациях.

#pragma pack(push,1)
xxxx
#pragma(pop)

Answer 6

Вы смешиваете релизную DLL с отладочным приложением?

В противном случае это звучит как повреждение памяти, хотя я не могу сказать наверняка.

• Что-то еще топает память
• Вы обращаетесь к удаленной памяти
• Вы возвращаете временный указатель или ссылку
• и т.д.

В некоторых случаях может показаться, что любое из них работает нормально, поскольку они неопределяемого поведения, и только в режиме выпуска они взрываются.