Тогда и мы вряд ли чем поможем 

а обязательно использовать эти ненадёжные new[]/delete[]'ы? 
контейнеры и smart pointerы не пойдут?


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

Это сообщение отредактировал(а) Mayk - 1.5.2007, 23:17

Mayk, 

Функция одна. она же главная. Я не стал заводить множество функций под каждую операцию в проекте, хоть и признаю, что самым лучшим тоном было бы создать одну функцию, которую бы вызывал с разными параметрами. Ну да не будем переходить к специфике проекта самого.  
И... Как узнаю и научусь пользоваться контейнерами и smart pointerами  то обязательно сравню чем лучше. На данный момент, это для меня неизвестные термины. Все ещё впереди.

Xenon, 
Уже помогли. Причем достаточно сильно. Спасибо.

А где в стандарте описывается вероятность, с которой должен "ненадёжный" delete[] должен освобожать память выделенную "ненадёжным" new[]   
И чем, простите, пользуются Ваши волшебные "контейнеры и smart pointerы", что бы  избежать этой ненадежности      ?

Пожалуй слово "ненадежный" надо употреблять к программеру.

Я так понял суть вопроса была в нехватке памяти. Где-то с год назад в другом формуе была похожая проблема. Весь вопрос был в том, что в процессе работы выделялось огромное количество небольших кусочков, потом освобождалось, потом снова выделялось. Я написал небольшой тест (сейчас найти его не смог). Программа только и делала, что выделяла и освобождала небольшие участки памяти. Стабильный вылет по нехватке памяти примерно через 10 минут работы. Естественно все корректно освобождалось - там ошибиться было негде.

Тогда все на форуме пришли к дружному мнению, что менеджер памяти в Борланде оказался не готов к таким вещам. Но чтобы это достичь, понадобилось действительно очень много раз выделять и освобождать много кусочков. А вот куда тестовый код дел - Бог его знает, видимо затер...

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

Ненадежность пары new/delete заключается в том, что их надо писать руками. А если не напишешь --- то получишь memory leak. 

Контейнеры и смарт поинтеры умеют пытаются чистить память самостоятельно.  Зачастую довольно успешно.
Или я что-то пропустил и теперь без  явного my_vector.clear() память контейнеры уже не освобождают? 


А Вы видели код автора темы? Откуда такая уверенность что на каждый new[] имеется delete[]?

Это сообщение отредактировал(а) Mayk - 2.5.2007, 18:35

Если память выделяется и освобождается внутри одной функции и еще размер массивов не очень большой то можете выделить ее в стеке. Это работает очень быстро и автоматом очищается. Например:


Оператор new и delete не очень легкие операции. При частом использовании в некоторых случаях может провести к фрагментации адресного пространства процесса. Но этого (многократного создания и удаления) можно избежать, например таким образом:

А не ищете ли вы в темной комнате черную кошку которой там нет Откуда уверенность, что есть утечки? Менеджер процессов показывает только возрастание? Так он за такими мелочами, как отдельные кусочки в хипе не следит, хотя бы потому, что управление хипом может по разному происходить в разных программах. Кроме утечек есть ведь такая вещь, как фрагментация памяти... Т.е. выделенный объем хипа большой, а память в нем нарезана мелкими дольками: и свободной вроде много, и непрерывный кусок не найти...

Ничего страшного, я Вас извиняю. Но продолжим дальше. А чем пользуются деструкторы, что осободить память? delete[] не предлагать в виду его "ненадежности" 


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



"Зачастую довольно успешно." Как ? И они тоже проявляют ненадежность?


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

я ж уже написал что

Забыть вызвать деструкторы весьма проблематично. 
Забыть вызвать delete[]/free()/fclose/pthread_mutex_unlock/etc достаточно легко. Особенно в громоздкой ф-ции.


В неудобстве использования. 
Или Вы в самом деле считаете, что явный вызов delete[]  является  верхом удобства? 


Поиск по ключевым словам "циклическая зависимость"(это о не абсолютной надежности смарт поинтеров)  и 
обдумывание vector<int*> mv(1, new int[100]); return; (это о не абсолютной надежности при использовании контейнеров)


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


К сожалению других данных у нас нет. Но лишний прогон через детекторы memory leak'ов хуже не сделает. 


Это сообщение отредактировал(а) Mayk - 2.5.2007, 20:49

Судя по


возможно автар создал нечто вроде 



хотя как оно было на самом деле мы уже вряд ли узнаем))

это проблемы программиста, он не должен забывать. 

Вы знаете, Я в полной растеренности. Вы действительно уверены, что  vector предназначен для  только для того, чтобы уберечь неокрепшие души  начинающих программистов от написание ужасного delete? 
Потому как в этом коде, 

я вижу , как создается вектор указателей на инт размером 1  и тут же инициализируется адресом на массив, выделенный оператором new[]. Насколько я понимаю, здесь мы имеем возможность наблюдать  ту же кривизну рук. Почему Вы  это отнесли этот код к " не абсолютной надежности при использовании контейнеров" для меня загадка

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



Предоставьте ссылку на пост где я писал что он предназначен только для этого. 
 

По определению

Наличие memory leak'ов свидетельствует о том, что код не является соврешенным, 
следовательно он не является абсолютно надёжным в плане памяти несмотря  несмотря на использование контейнера.
Напомню что это было к реплике

Вот подобный пример как раз показывает когда stl'овские контейнеры проявляют ненадежность.

Для примера --- QPtrCollection из QT(это базовый тип для коллекций указателей) имеет свойство autoDelete, при установке которого элементы данного контейнера будут delete'нуты. (знаю-знаю, delete отличается от delete[] --- суть не в этом, суть в том что иногда контейнер вполне успешно может контролировать жить элементам, или нет).

Mayk, 
Vyacheslav,
я как-то упустила нить вашей дискуссии... Да и не только я, полагаю... 
Вы оба правы: хорошему программисту STL контейнеры, RAII и прочая, конечно, не помешают, но плохому - не помогут...
Стоит только посмотреть (да хотя бы по этому форуму), ЧТО народ пытается в контейнеры засунуть...    
Кривые руки одним использованием STL не выпрямляются... Даже наоборот, появляется искусс и дальше ничего не понимать... Пороть надо, наверное...