Бесконечный цикл двусвязного списка?

Если с учетом указателя mNext узлы образуют цикл, то тогда уничтожение любого из узлов действительно вероятно сформирует бесконечный рекурсивный цикл, который завершит программу, взорвав стек.

То, что, вероятно, произойдет,

1. Выдается первый "внешний" delete node;.
2. При входе в деструктор узла еще ничего не делается, так как деструктор кода является «первой» вещью, выполняемой в процессе уничтожения (сам процесс уничтожения весьма сложен и включает в себя код деструктора, изменение класса, уничтожение члена, уничтожение базы в следующем порядке: см. этот ответ для более подробного объяснения ).
3. Первая инструкция заполнения деструктора выполняет delete mNext;, тем самым запуская тот же процесс на следующем узле в цикле.
4. Поскольку узлы образуют петлю, эта цепочка снова достигнет node «сзади», что сделает самый первый вызов рекурсией, которая никогда не закончится.
5. Тем не менее каждый вызов будет выделять место в стеке для записи активации, поэтому через некоторое время вся память, разрешенная для использования для стека, будет исчерпана, и ОС уничтожит процесс. Вызов удаления не является «хвостовым вызовом», потому что после завершения кода деструктора память должна быть освобождена, поэтому эту рекурсию нельзя легко оптимизировать... в то время как delete mNext; является последним оператором в деструкторе, все же есть операции, которые должны быть выполнены после оператор delete завершает работу.

Однако обратите внимание, что, по моему опыту, переполнение стека, если вы не используете специальные параметры компилятора, не будет проверяться, и поэтому завершение программы будет довольно «ненормальным». Также обратите внимание, что в Windows есть какой-то ужасный код, который в некоторых случаях скрывает ошибки segfault, если они происходят при завершении программы, поэтому вполне возможно, что программа Windows может просто изящно завершаться в этой операции, выполняемой после выхода из цикла событий.

Учтите, что переполнение стека обычно не рассматривается, на самом деле возможно любое поведение, включая очевидный «бесконечный цикл» (обратите внимание, что этот бесконечный цикл может быть не одним из рекурсивных деструкторов, а где-то внутри системы выполнения, которая сходит с ума из-за переполнения стека) .

Почему я использовал слово вероятно? Причина в том, что стандарт C++ говорит, что многократное уничтожение объекта является неопределенным поведением. Если вы добавите это к тому факту, что в C++ нет способа выйти из деструктора без завершения уничтожения, вы поймете, что компилятору теоретически разрешено помечать объект как «уничтожаемый» и заставлять демона вылетать из вашего nosrils, если дважды ввести деструктор одного и того же объекта. Однако проверка этой ошибки не является обязательной, и составители компиляторов часто ленивы (это НЕ оскорбление для программиста), и поэтому маловероятно, что эта проверка будет присутствовать (за исключением случаев, когда включена какая-то специальная дополнительная опция отладки).

Подводя итог: может ли это зацикливаться вечно? да. Может ли это рухнуть? Конечно. Может ли он перестать говорить мне, что объект уничтожается дважды? конечно. Может ли он просто красиво завершить программу (т.е. без установки кода ошибки)? да, это тоже.

Все может случиться. И Мерфи говорит, что произойдет то, что нанесет вам наибольший ущерб... например, программа будет завершаться каждый раз, пока вы ее разрабатываете... перед тысячей потенциальных клиентов.

Только не делай этого :-)

У него нет способа узнать, когда остановиться, поэтому он, вероятно, будет работать бесконечно.
Возможно, вам следует написать класс List, который имеет указатель на (или фактический) Node. d'tor Node должен заботиться только о своих собственных полях, в данном случае mContact. Д'тор List должен перебирать все узлы в списке (запоминая, когда нужно остановиться) и удалять каждый из них (ровно один раз).

Предполагая, что вы инициализируете mNext значением null, он не будет работать бесконечно. Удалить ничего не сделает, когда встретит нулевой указатель. Таким образом, это закончится именно тогда, когда вы этого ожидаете.

Я не уверен, что вы делаете с параметрами «если раньше». Это не сработает. Либо это будет действительный узел и, следовательно, будет иметь предыдущий узел, либо он не будет действительным узлом, и проверка предыдущего приведет к неопределенным результатам. Придерживайтесь простого ответа:

class Node 
{ 
Node(  mNext = NULL; ); 

~Node(  ) 
{ 
   delete mNext; //deallocs next node 
} 

Contact mContact; 
Node* mPrevious; 
Node* mNext; 
};  

Уточнение: это решение работает, но только при соблюдении двух условий: 1) Нет узлов, появляющихся в списке дважды. 2) Список не круговой. Если вы можете гарантировать эти условия, это ваш самый простой ответ. Если вы не можете, вам нужно сделать что-то более сложное.

Лично я считаю немного странным, что деструктор Node должен иметь какое-то отношение к другим узлам.

Если бы дизайн зависел от меня, я бы создал класс List, содержащий указатель на Node объекты (first и last). Деструктор класса List позаботится об итерации по всем узлам в списке и их уничтожении.

Это на самом деле просто. Предположения 1) Это список с двойными ссылками, а не круговой 2) Нет циклов в списке ссылок: это список с двойными ссылками 3) Класс реализации имеет только один экземпляр Node Вероятно, называется HeadNode или LinkList;) и это узел, который явно уничтожается

Пример: LinkList состоит из 1->2->3->4->5->6->NULL. Вызов диструктора для HeadNode(ссылка на 3-е предположение) вызовет рекурсивный вызов следующим образом: delete(1)->delete(2 )->delete(3)->delete(4)->delete(5)->delete(6)->NULL Итак, пожалуйста, проверьте, если (mNext!= NULL) удалите mNext, и это работает :)

Но: если вы хотите удалить узел конкретно: скажем, мы хотим удалить только 4 в приведенном выше примере, все узлы будут удалены до NULL, поэтому перед удалением убедитесь, что вы установили Mnext в NULL.

Лучшей практикой было бы использовать библиотеку STL или иным образом использовать класс автоуказателя для части уничтожения проблемы.