тут недавно обнаружил такую ситуацию:

в результате имеем мемори лик (проверял FastMM4) - этот самый стринг '123'. если же написать

то всё ok. в общем-то вполне ожидаемое поведение  но пока меня FastMM в него носом не ткнул я про него не знал. и появилась такая проблема: в проекте куча вот таких вот record'ов с полями string, указатели на котрые (на record'ы) храняцца в процессе работы в TList и в конце особождаюцца вот таким кодом:

но получаецца что он неправилен. можно конечно написать для каждого типа record'a свою процедуру, но как-то это нерационально. может можно как-то передать в процедуру ссылку на тип (ну вроде class of только для типа) чтобы сделать приведение указателя к нему?

Это сообщение отредактировал(а) Seldon - 12.11.2006, 03:55

Я вижу три варинта:
1. Сделать вместо string везде string[255], но это ограничит размер строки
2. объявить все записи как class
3. Сделать в каждой записи первым поле, в которое будешь помещать код типа. Тогда просто пишешь вместо New и Dispose свои процедуры. New будет заполнять эти первые байты, а Dispose, анализировать их же и соответственно накладывать тип, чтобы корректно высводобить строки

Всегда нас в университете учили в records писать стринги инициализированные. так что лучше писать:

1. не катит 
2. вот к этому я уже сам пришёл, по почему-то не нравицца мне это решение
3. интересно, спасибо за интересную идею

а вот кстати, почему в этом случае нет лика? как я понимаю в случае string, компилятор не знает о ней и освобождает только 4 байта, занимаемые указателем на строку, а количество ссылок на строку не уменьшаецца? так? а как в случае с string[255]?

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

В этом случае строка представлена как в паскале. Т.е. не ссылкой, а как есть. Какова длина строки, настолько (плюс один байт) у тебя увеличивается структура. 
При распределении нужно только длину в ноль установить. Хотя, если ты сразу забиваешьш значения, то не нужно

Это сообщение отредактировал(а) digs - 12.11.2006, 14:39

код в моём первом посте, созданная строка больше нигде не используецца.

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

такой вопрос: в nt-based os каждое приложение имеет собственное адресное пространство и os после закрытия приложения всё равно вернёт себе всю занимавшуюся им память? т.е. лики просто увеличивают используемую во время работы приложения память? а после его завершения os всё себе вернёт?

может есть ссылки на материалы по этому?

Я тут еще вспомнил про Object.
Можно его использовать, а не record.
Скорее всего для него информация о строках сохраняется, и Dispose для него будет скорее всего кореектно отрабатываться. 

а че вместо своей структуры , не заюзать TStringList

да, можно, но
1. мне это не нравицца по религиозным убуждениям.
2. хочу таки разобрацца с этим вопросом.

потому что не все поля записи - string. например вот такая структура:

её можно легко сделать классом, и проблема исчезнет, но public поля класса вида Port:Integer; мне будут резать глаза и я сделаю

а это много лишнего кода, который затрудняет чтение и понимание.

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 13:22

мне кажецца, ты неправ. простой тест показывает, что, например, с Integer нет никаких проблем и они освобождаюцца нормально даже при передаче в Dispose нетипизированного указателя. проблемы только со String и, видимо, со всеми другими типами с управляемым временем жизни. кстати, какие, кроме String существуют ещё?

и по сути вопроса: какие предложения по поводу разрешения моей ситуации? (см. вторую половину первого поста). кроме замены record на class. пока что одно предложение: