У меня создаётся массив итераторов списка на 50000 элементов, примерно так:

Дальше, в цикле, заполняется список и массив из файла (вместе со списком заполняются map`ы, деревья и ещё много чего) --- всё это занимает примерно 5 секунд. 

Затем массив удаляется (сам список из 50000 элементов, на который ведут итераторы по прежнему существует):

Я запускал это на Visual Studio и выполнялось это неимоверно долго --- я так и не дождался завершения. Посмотрев код Microsoft, я увидел странный цикл для разрыва связей, вызывающийся и деструктора итератора.

Я заменил удаление на:

И после этого медленно стал работать цикл. За 20 секунд сбросилось всего 300 итераторов.

Вопрос: неужели, STL действительно требует линейного времени на удаление итераторов и зачем? Как избежать в моём случае? Как дело обстоит с другими компиляторами, или может, можно даже в VS задать какой-нибудь #define, чтобы избежать этой ненужной траты? 

что за элементы в списке, покажи код


вообще delete[] вызывает деструктор каждого объекта

Что за элементы неважно, удаляются всё равно только итераторы. Я понимаю, что delete вызывает деструктор (думаю, иначе он работал бы моментально, new[50000] во всяком случае работает моментально). И видимо деструктор итератора требует линейного времени по размеру списка.

Но если код всё же нужен приведу, правда не уверен, что кто-то будет разбираться:


record_it это list<record>::iterator. 

а это зачем делать?   
если обнулять итератор, то не этим - record_it(); 
а вот этим значением records.end();

а вообще можно просто удалить - 


Добавлено @ 14:33
еще один баг нашел,
- будет работать вечно, потому-что в начале цикла sz = 0, так как перед этим отработал цикл а sz - беззнаковое значение, то есть в первой итерации цикла, в котором ты удаляешь произойдет переполнение и ты получишь очень большое число   
[update]
пардон не заметил что переменные разные.. sz и szz..   


Это сообщение отредактировал(а) Lazin - 18.4.2008, 14:48

Согласен, это одно и то же. Я сделал так, чтобы 
1) понять, из-за чего реально тратиться время (вдруг, delete[] тратит его на возвращение блоков памяти?) и 
2) чтобы можно было реально проследить, сколько итераторов обработано. 
В любом случае, эти два варианта работают одинаково медленно, но так я узанал, что время тратится именно на то, чтобы отвязать итератор от списка.

вообще так циклы лучше не писать, читаемость хуже плюс такие побочные эффекты  

Добавлено через 3 минуты и 16 секунд
итератор нельзя отвязать от списка, даже когда итератор не указывает на элемент списка, он содержит list.end() списка которому он принадлежит
в некоторых версиях stl можно запросто получить assert  сравнивая(присваивая ....) итераторы(не значения а именно сами итераторы) из разных списков(векторов, деков)

Побочные эффекты не от цикла. Как я писал, они остаются, если поручить это операции delete;

Итератор я отвязываю так: records_tab[i++]=list<T>::iterator();, неужели, так можно получить assert (конструктор по-умолчанию же у него есть, зачем такую диагностику)?
Это долгая операция. Требует, видимо порядка n действий, где n размер списка. В этом и проблема. Если этого не делать явно, то то же происходит при вызове delete.

Я сделал #define HAS_ITERATOR_DEBUGGING 0 и это стало работать быстро!

Выходит, STL от MIcrosoft не настолько идиотская, насколько могло показаться. 

d06osipov, 
щас ты будешь смеяться: авторство STL, поставляемой с компилятором, не принадлежит MS

Кто же ещё мог так наизвращаться? Впрочем, про Microsoft известно, что это скорее контора "купи-продай", так что ничего удивительного нету.

меня просто добивает тупость людей...
причем тут Майкрософт, STL не имеет никакого отношения к MS!!! Он его не покупает, не продает и ничего с ним не делает

да, они только лицензируют одну из реализаций стандартной библиотеки и продают в составе VS своим клиентам   

эта часть VS поставляется бесплатно ;)

STL имеет такое отношение к MS, что одна из его реализаций входит в состав Visual Studio (а по вашим словам ещё и в бесплатный набор Visual C++ Toolkit), а документация по данной реализации входит в состав MSDN.

А то, что Microsoft эту реализацию не покупает, это не факт.