Очень долгое освобождение динамически выделенной памяти

[Rangok]

Спасибо, это я уже понял. Но моя проблема не в этом и она по-прежнему остается.

[pproger]

2Rangok
я тебя попросил выложить минимальный, самодостаточный код, на котором проявляется проблема. ты же чего то тупишь.

Проблема проявляется при удалении элементов, а код вот:

ну так и приведи кусок рабочего года (чтобы я смог у себя скомпилировать и посмотреть). толку от твоих вырванных кусков нет.

[pproger]

Сообщение от _Bers

Есть даже такой термин: pure virtual function call

Твой чисто виртуальный диструктор - это детище корпорации Зла.
Только студийные компиляторы пропускают такое мимо ушей.
Писать чисто виртуальные диструкторы - не по стандарту, и соответственно твой код будет не портируемым.


На языке с++ у каждого класса без исключений существует конструктор, и диструктор.

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

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

А поскольку у него нет туловища - ошибка компиляции/компоновки.

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

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

При уничтожении объектов, запускаются диструкторы всех классов

возможно я сейчас потроллю, но такими фразами разбрасываться опасно. я могу привести код, который будет компилироваться без ошибок (но возможно с варнингом), в котором при выполнении "delete obj" деструктор obj вызван не будет (но память, отведенная для объекта очистится). естественно, не прибегая к перегрузке delete.

[Rangok]

Сообщение от pproger

2Rangok
я тебя попросил выложить минимальный, самодостаточный код, на котором проявляется проблема. ты же чего то тупишь.
ну так и приведи кусок рабочего года (чтобы я смог у себя скомпилировать и посмотреть). толку от твоих вырванных кусков нет.

Да я не могу привести "минимальный кусок кода", где проблема проявляется, потому что не знаю где она проявляется (если не считать того, что она проявляется при удалении). А построение этого контейнера, удаление которого происходит так долго является основной задачей программы. Если хотите могу всю программу выложить.

[pproger]

2Rangok
пройдись отладчиком, посмотри, какие функции вызываются, на каких задерживается

[Rangok]

При удалении элемента отладчик постоянно прыгает на каких-то функциях их xutility
в функции operator*() const прыгает на строчке

	reference operator*() const
		{	// return designated value
		_RanIt _Tmp = current;
		return (*--_Tmp);

и в функции _Adopt(const container base 12*) на строчке

 #if _ITERATOR_DEBUG_LEVEL == 2
			if (_Myproxy != _Parent_proxy)
				{	// change parentage
				_Lockit _Lock(_LOCK_DEBUG);
				_Orphan_me();
				_Mynextiter = _Parent_proxy->_Myfirstiter;
				_Parent_proxy->_Myfirstiter = this;
				_Myproxy = _Parent_proxy;
				}
		}

Профайлер говорит:
Функции с максимальной индивидуальной работой
Имя Эксклюзивное время %
__RTC_CheckEsp 15,88
std::char_traits<char>::compare(cha r const *,char const *,unsigned int) 8,75

[waleri]

У вас Debug версия, соотвественно лишние проверки. Запустите Release и будет вам счастье. Вам кстати уже об этом говорили выше.

[_Bers]

Сообщение от pproger

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

virtual ~Node()=0; //автор считает, что туловище диструктору не нужно.

Сообщение от pproger

возможно я сейчас потроллю, но такими фразами разбрасываться опасно. я могу привести код, который будет компилироваться без ошибок (но возможно с варнингом), в котором при выполнении "delete obj" деструктор obj вызван не будет (но память, отведенная для объекта очистится). естественно, не прибегая к перегрузке delete.

Проблема удаления объектов неполных типов ортогональна к отсутствию диструктора у интерфейса.

Даже у абстрактного класса должен быть диструктор.
А ты вот попробуй написать портируемый код: класс без диструктора.

А я посмотрю, как он у тебя будет взлетать.
И как ты заставишь его работать? Каждый раз искусственно создавать ситуацию удаления не полных типов?

[_Bers]

Сообщение от pproger

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

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

http://ideone.com/EOH6I

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

Как видишь, гцц сказал: у чисто виртуальных методов не должно быть реализации.

А вот диструктор должен быть у каждого класса. Канитель получается, ага.

То, что студийные компиляторы позволяют писать реализацию для чисто виртуальных функций - это специфик Корпорации Зла, и не является решением по стандарту. Это нужно понимать.

Мораль: никогда не нужно делать чисто-виртуальных диструкторов, и будет вам счастье.

[pproger]

2_Bers
я тебе еще раз говорю, очки протри! автор ОПРЕДЕЛИЛ ТЕЛО ДЕСТРУКТОРА!
http://programmersforum.ru/showpost....2&postcount=16

В классе Node данных не содержится, поэтому я объявил чистый виртуальный деструктор, чтобы он не вызывался просто так.
Код:


public:
virtual ~Node()=0;

и
Код:

Node::~Node()
{}