Ещё раз всех приветствую.

На этапе тестирования софта заметил утечку памяти. 
И судя по всему проблема в том, что у меня используются длинные строки string(больше 255 символов).

Решил переписать всё, оставив только Pchar, но столкнулся с проблемой, обычные функции, котрыми я выполняю поиск подстроки в строке не раотают с типом Pchar

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

Cпасибо

Добавлено @ 07:23
Или может быть проще избавиться от утечки памяти при длинных строках string? Хотя думаю правильнее отказаться от string

Это сообщение отредактировал(а) lollollollol - 3.4.2013, 07:23

string без указания количества символов - это либо UnicodeString, либо AnsiString (в зависимости от версии среды). Никаких утечек памяти при использовании этого типа быть не может.

Для замены подстроки в строке обычно используют StringReplace. Да, там используются string. Если тебе уж так очень надо писать без string, то наваяй свою функцию, это же не запрещено.

Я постоянно пользуюсь string и утечек по этому поводу не наблюдаю. Не знаю откуда у тебя сложилось такое ошибочное мнение, что из-за string происходят утечки.

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

Это сообщение отредактировал(а) lollollollol - 3.4.2013, 09:08

fastmm подключать пробовали?

нет, дже не слшал про это

Подключите, увидите, есть ли утечки, а также поможет найти места, где они появляются. Я бы без fastmm не грешил на string, ни разу не видел чтобы он куда-то утекал.
http://sourceforge.net/projects/fastmm/ 

Скачал, подключил, на удивление софт стал в нескоько раз быстрее выполнять основной рабочий код.
Но стабильно кидает Access Violation в модуле FastMM4 на строке

или


Добавлено через 8 минут и 21 секунду
А как с его помощью определить место утечки?
Прога не должна больше 2-х метров весить, через 5 минут работы уже 50 мегов

Это сообщение отредактировал(а) lollollollol - 3.4.2013, 09:40

Показания диспетчера не значат абсолютно ничего. Утечек и AV с PChar словишь в миллион раз больше, чем со String для которого все выделение и освобождение памяти производится автоматически. А еще если у тебя часто приходится получать длину строки.   Не вижу никаких оснований использовать эту мерзость, кроме как для преобразования типов при вызове API-функций.
http://www.gunsmoker.ru/2010/02/redux.html

Добавлено через 4 минуты и 12 секунд


Так для релиза дебажные настройки выруби, у меня вот сейчас выходной экзешник из XE3 с подключенным для full debug FastMM4 весит 21.5 Мб.  Релизный вариант меньше 3 (Юникодовые версии компактностью экзешек не отличаются).

И какая версия FastMM? Может надо последнюю качнуть?

Скачал отсюда
http://sourceforge.net/projects/fastmm/

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

И обратно не уменьшается

http://forum.vingrad.ru/forum/topic-353769.html


В D2007 FastMM уже встроен

Добавлено через 1 минуту и 45 секунд
В dpr файле можно добавить строку:


http://delphist.ru/utechki-pamyati-v-delphi/

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

Я использую делфи7.

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

Спасибо!

Добавлено через 2 минуты и 59 секунд
[Error] hidden.dpr(809): Undeclared identifier: 'ReportMemoryLeaksOnShutdown'

Это откуда?

Всё же я бы использовал eurekalog или madExcept

Хотелось бы выяснить границы видимости переменной buff. Не удивлюсь, если увеличение памяти происходит из-за неочистки этих переменный после отработки.

buff это просто string, как уже говорилось ранее.
Переменная формируется примерно таким образом:




Это сообщение отредактировал(а) lollollollol - 3.4.2013, 17:00

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