2013-04-08 3 views
2

Похоже, что мой объект изменяется после того, как я нажму push_back в std :: list.Почему мой объект изменяется после списка :: push_back()

Это объект перед push_back: object before push_back

Посмотрите, как после некоторого действительного m_parent_reference указателя он в конечном итоге становится nullptr таким образом завершая цепь.

Это как мой объект выглядит после push_back() object after push_back

Теперь нет nullptr больше. Вместо этого один parent_reference ссылается на свой дочерний элемент, создавая бесконечный цикл.

  1. m_InterchangeList имеет тип std::list<CKerEDIInterchange>
  2. m_parent_reference имеет тип CKerEDIReference
  3. CKerEDIInterchange наследует от CKerEDIReference
  4. Ни CKerEDIInterchange, ни CKerEDIReference есть пользовательский конструктор копирования
  5. Я испытал это поведение с помощью Visual Studio 2010 SP1 и Visual Studio 2012 Обновление 2
  6. Переменная m_parent_reference может быть установлена ​​только через конструктор
      CKerEDIReference(const CKerEDIReference* const parent_reference = NULL) 
         : m_parent_reference(parent_reference) {}; 
    

С пользовательскими конструкторами копирования и назначить оператор я мог наблюдать следующее:

  1. Присвоить Операторы никогда не называется
  2. Ссылки дается ` CKerEDIReference :: CKerEDIReference (const CKerEDIReference &) уже сломан, так как в нем уже есть этот бесконечный цикл.

редактировать Больше информации:

  1. Вызова {CKerEDIInterchange tmp(nInterchange);} делает не приводит к поврежденным объектам.
  2. Нарезка не участвует. m_InterchangeList имеет type std::list<CKerEDIInterchange> и nInterchange если типа CKerEDIInterchange

Я действительно хотел бы знать, если кто-то может дать мне подсказку, где искать дальше.

Спасибо заранее, Ник Papagiorgio

+3

Вы не должны публиковать код, который * не * помог воспроизвести проблему. Вы должны опубликовать код, который показывает проблему. Как мы должны выяснить, что в противном случае? –

+0

Ваши родительские ссылки, указывающие на элементы в 'm_InterchangeList', случайно? Поскольку, когда список внутренне изменен, указатели становятся недействительными. – riv

+1

Нет конструкторов копирования, но у ваших классов есть деструкторы? – john

ответ

0

Я нашел причину Fo такого поведения. По-видимому, один из тех объектов CKerEDIReference был удален. Добавив новый объект в список, новый список был записан в память этого удаленного объекта. Я думаю, это было просто чистое совпадение, это не сбой.

Смежные вопросы