AnsiString a = "a";
AnsiString b = "b";
while( true )
{
AnsiString c = true ? AnsiString( a + b ) : AnsiString( "" ) ;
}
Утечки памяти в AnsiString
На Builder 6 обнаружены утечки памяти при работе с AnsiString.
Вот код:
По ходу дела возникает, когда формируется временный объект AnsiString на базе другого временного объекта AnsiString.
Вот код:
Код:
По ходу дела возникает, когда формируется временный объект AnsiString на базе другого временного объекта AnsiString.
Это не утечка памяти. Объекты должны быть разрушены при выходе из области видимости - а у тебя этого не произойдет никогда.
Хотя в принципе ты прав - утечки памяти имеют место, это я ошибся.
Цитата: kot_
Объекты должны быть разрушены при выходе из области видимости - а у тебя этого не произойдет никогда.
Каждая итерация цикла обеспечивает выход из области видимости и как следствие - вызов деструктора.
Цитата: Absolut
Каждая итерация цикла обеспечивает выход из области видимости и как следствие - вызов деструктора.
С каких пор у массива появился деструктор, и с какого кипариса массив - объект? В случае строк (массивов), очищать память - забота программиста. Посему автор тоже не прав: это не ошибка Инпрайза. Это - наша беда.
Объект мы нарушаем при помощи FreeAndNil(TObject); А вовсе не так, кстати, как этому учат в некоторых ВУЗ'ах TObject -> Free. Если объект оконный (TWinControl) и находится внутри такого же оконного контрола, то о его деструкции не нужно заботиться. А вот если он является иным наследышем от TPersistent (не TWinControl), или он тупо массив, либо структура/record, то его убивать нужно что называется вручную. Об этом нужно помнить, и в этом плане частенько лень проявляется, когда программа написана, и ресурсы начинает жрать всё больше и больше, по мере времени работы.
mfender, где тут массив то увидел? =)
Цитата: aks
mfender, где тут массив то увидел? =)
А у нас строка - не массив-ли уже теперь? Тем более AnsiString.
Цитата: mfender
А у нас строка - не массив-ли уже теперь? Тем более AnsiString.
Это контейнер - полноценный класс с конструктором и деструктором.
Цитата: mfender
А у нас строка - не массив-ли уже теперь? Тем более AnsiString.
нет. не массив. AnsiString - это объект.
ТС полностью прав - за что и получил заслуженный "+" в репутацию.
Цитата: mfender
А у нас строка - не массив-ли уже теперь? Тем более AnsiString.
Строка строке рознь в C++. Массив char-ов или wchar_t с завершающим нулем - да строка в C стиле. std::string - стандартный класс строковый, и массивом никак не являющийся. AnsiString - тоже класс строковый, борландовский велосипед. С конструкторами, деструкторами, методами и т.п.
А как он там внутри устроен - массивом, или еще как - не должно программиста волновать. =)
Цитата: kot_
нет. не массив. AnsiString - это объект.
ТС полностью прав - за что и получил заслуженный "+" в репутацию.
ТС полностью прав - за что и получил заслуженный "+" в репутацию.
Нет, ну я понимаю, что я на два года выпал из жизни, но не могло же всё настолько измениться, чтобы строки перестали быть массивами символов? Это же аксиома, и она действительна ещё с самого начала времён. Нет, понятно, что для руления этим массивом имеется класс, и что AnsiString - лишь расширение String, но от этого строка не перестаёт быть физически массивом символов!
Цитата: aks
AnsiString - тоже класс строковый, борландовский велосипед. С конструкторами, деструкторами, методами и т.п.
А как он там внутри устроен - массивом, или еще как - не должно программиста волновать. =)
А как он там внутри устроен - массивом, или еще как - не должно программиста волновать. =)
Здрасьте! :D А кого это должно волновать, когда делаешь всё по мануалу, а тебе Access Violation вываливается? Звонить support'у в Inprise? :D
mfender, не смотря на почтенный стаж на форуме - говорите сейчас глупости откровенные. )
Какие еще аксиомы, какие расширения? Это просто объект класса, написанного борландовскими программистами. Внутренняя реализация класса естественно скрыта от программиста (само собой скорее всего там внутри организовано все на массиве). И пока вы коректно используете интерфейс класса, вас не должно волновать его внутреннее устройство. Вот это как раз аксиома. =)
Какие еще аксиомы, какие расширения? Это просто объект класса, написанного борландовскими программистами. Внутренняя реализация класса естественно скрыта от программиста (само собой скорее всего там внутри организовано все на массиве). И пока вы коректно используете интерфейс класса, вас не должно волновать его внутреннее устройство. Вот это как раз аксиома. =)
Цитата: mfender
Нет, ну я понимаю, что я на два года выпал из жизни, но не могло же всё настолько измениться, чтобы строки перестали быть массивами символов? Это же аксиома, и она действительна ещё с самого начала времён. Нет, понятно, что для руления этим массивом имеется класс, и что AnsiString - лишь расширение String, но от этого строка не перестаёт быть физически массивом символов!
концепция строк в борланде/шарпе/джаве != char[].
Поэтому работать с этими объектами как с массивами - это нарываться на неприятности.
Цитата: aks
mfender, не смотря на почтенный стаж на форуме - говорите сейчас глупости откровенные. )
Какие еще аксиомы, какие расширения? Это просто объект класса, написанного борландовскими программистами. Внутренняя реализация класса естественно скрыта от программиста (само собой скорее всего там внутри организовано все на массиве). И пока вы коректно используете интерфейс класса, вас не должно волновать его внутреннее устройство. Вот это как раз аксиома. =)
Какие еще аксиомы, какие расширения? Это просто объект класса, написанного борландовскими программистами. Внутренняя реализация класса естественно скрыта от программиста (само собой скорее всего там внутри организовано все на массиве). И пока вы коректно используете интерфейс класса, вас не должно волновать его внутреннее устройство. Вот это как раз аксиома. =)
Вот оно! Таки вернёмся к старттопикку! Товарищ утверждает, что эта беда жрёть память.
А теперь убеждайте меня в обратном, а вовсе не в том, что написано в мануалах Борланды, и в чём вы меня пытаетесь убедить.
Блин, я выше пейсал про конструкцию-деструкцию. Но я сам в ней всегда сомневаюсь. Если делаю компонент, то всегда нарываюсь на то, что уничтожая любой объект внутри него, нарываюсь на ещё что-то, что не уничтожается само-собой. Например, TFont. Его кто-нибудь уничтожает? У него есть деструктор, но он не уничтожается по-уничтожении окна, соответственно - жрёт память.
UPD. Самое страшное, когда наследуешь от чего-то, что не имеет исходников. Пишешь inherited, а на выхлопе получаешь что-то типа "дурень, ты перекрываешь метод родителя", а сделать ничего не можешь, потому что исходы скрыты правообладателем.
Цитата: mfender
Например, TFont. Его кто-нибудь уничтожает? У него есть деструктор, но он не уничтожается по-уничтожении окна, соответственно - жрёт память.
Надо исходники читать. Не верю, что не уничтожается.
Цитата: kot_
концепция строк в борланде/шарпе/джаве != char[].
Поэтому работать с этими объектами как с массивами - это нарываться на неприятности.
Поэтому работать с этими объектами как с массивами - это нарываться на неприятности.
ну почему же?
Код:
AnsiString str = "Hello World";
str[6] = '_';
char a = str[1];
str[6] = '_';
char a = str[1];
где здесь неприятности?
Цитата: oxotnik333
ну почему же?
где здесь неприятности?
Код:
AnsiString str = "Hello World";
str[6] = '_';
char a = str[1];
str[6] = '_';
char a = str[1];
где здесь неприятности?
Ну, operator[], понятно перегружен. А если указателем пробежаться? :rolleyes: После серии конкатенаций?
Вроде как, массив гарантирует, что данные находятся в непрерывном участке памяти. AnsiString это обещает? Видимо, частично из этого и утверждение об опасности работы с такими объектами - как с массивом.
Дальнейшие изыскания привели к созданию своего класса с динамической памятью:
Клиентский код аналогичный тому, что был в начале:
В каждой итерации не вызывается деструктор одного из временных объектов.
Как следствие, проблемы не с AnsiString, а в компиляторе.
Код:
class U
{
public:
U( const U& u ) { p_ = new int; *p_ = *u.p_; printf("copy ctor\n"); ++ctorCnt; }
explicit U( int v = 0 ) { p_ = new int; *p_ = v; printf("ctor\n"); ++ctorCnt; }
U operator+( const U& u ) { return U( *this->p_ + *u.p_ ); }
~U() { delete p_; printf("dtor\n"); ++dtorCnt; }
static int ctorCnt;
static int dtorCnt;
private:
int* p_;
};
int U::ctorCnt = 0;
int U::dtorCnt = 0;
{
public:
U( const U& u ) { p_ = new int; *p_ = *u.p_; printf("copy ctor\n"); ++ctorCnt; }
explicit U( int v = 0 ) { p_ = new int; *p_ = v; printf("ctor\n"); ++ctorCnt; }
U operator+( const U& u ) { return U( *this->p_ + *u.p_ ); }
~U() { delete p_; printf("dtor\n"); ++dtorCnt; }
static int ctorCnt;
static int dtorCnt;
private:
int* p_;
};
int U::ctorCnt = 0;
int U::dtorCnt = 0;
Клиентский код аналогичный тому, что был в начале:
Код:
U a(5);
U b(7);
while( true )
{
U c = true ? U( a + b ) : U( );
}
U b(7);
while( true )
{
U c = true ? U( a + b ) : U( );
}
В каждой итерации не вызывается деструктор одного из временных объектов.
Как следствие, проблемы не с AnsiString, а в компиляторе.
Цитата: Lerkin
Ну, operator[], понятно перегружен. А если указателем пробежаться? :rolleyes: После серии конкатенаций?
Вроде как, массив гарантирует, что данные находятся в непрерывном участке памяти. AnsiString это обещает? Видимо, частично из этого и утверждение об опасности работы с такими объектами - как с массивом.
Вроде как, массив гарантирует, что данные находятся в непрерывном участке памяти. AnsiString это обещает? Видимо, частично из этого и утверждение об опасности работы с такими объектами - как с массивом.
ну как бы я бы сказал даже не частично а целиком - приведенные тобой примеры как раз таки хорошо это иллюстрируют.
Кстати, на mingw подобных проблем нет. Код
Код:
QString a = "1";
QString b = "2";
int i = 0;
while(true){
QString c = true?QString(a+b):QString("");
}
QString b = "2";
int i = 0;
while(true){
QString c = true?QString(a+b):QString("");
}
не отжирает всю память в системе. Так что ТС вероятно прав - это проблема компилятора.
Цитата: GIZMO
Да. Если память не подводит, то это менеджер ресурсов...
Мой плющевый дрюк, попробуй это самолично, а потом рассказывай за некий "менеджер ресурсов", которого, как известно в Windows нет. Он есть, но это не совсем то, об чём речь. И то что есть в Win - не уничтожает ниразу пресловутый TFont. Могу даже на досуге накидать небольшой тестик.
Цитата: GIZMO
не жрет ее никто, объекты GDI кэшируются VCL
Опять же: учите теорию и матчасть. ОС не думает вместо программистов. Искусственного разума так ещё и не придумали.
Проверил код на Builder2006 и Builder2010, там утечек памяти не наблюдается. Очевидно проблема конкретно в версии 6.
Цитата: mfender
Нет, понятно, что для руления этим массивом имеется класс, и что AnsiString - лишь расширение String, но от этого строка не перестаёт быть физически массивом символов!
В Builder6 String это просто псевдоним AnsiString.
Цитата: mfender
Вот оно! Таки вернёмся к старттопикку! Товарищ утверждает, что эта беда жрёть память.
Если ты считаешь, что проблема в том, что надо уничтожать объект, то почему тогда такой код не жрет память?
Код:
while (true)
{
AnsiString c = "Привет!";
}
{
AnsiString c = "Привет!";
}
Цитата: mfender
Мой плющевый дрюк, попробуй это самолично, а потом рассказывай за некий "менеджер ресурсов", которого, как известно в Windows нет. Он есть, но это не совсем то, об чём речь.
гы-гы, а странный пацан4ег аднака:)
А хто тебе рассказывает про некий "менеджер ресурсов" Windows? Раз спросил про TFont, то речь идет об объектах GDI VCL. И некий "менеджер ресурсов" имеется ввиду TResourceManager из graphics.pas.
Цитата: mfender
И то что есть в Win - не уничтожает ниразу пресловутый TFont. Могу даже на досуге накидать небольшой тестик.
Это ты своему дрюку, который у тебя в штанишках можешь объяснять:) Нифкурю одного - с чего ты взял, што я так считаю?
и если воспользуешься своим мудрым советом сам
Цитата: mfender
Опять же: учите теорию и матчасть. ОС не думает вместо программистов. Искусственного разума так ещё и не придумали.
то как заметил один товарищ - "перестанешь говорить глупости откровенные"
У меня возникло ощущение, что у mfender'а сперли аккаунт. Извините.
ну не обязательно.
Мож mfender занял должность девелопера? В С++Билдере? По знакомству. Это же нормально для вашей страны? Чего удивлятся то? У вашего центрального канала приходит понимание что мер мАсквы не такой после команды сверху. До того он же был супер? Да он вообще был клевым чуваком - пока с Кремля не сказали - фас.
Мож mfender занял должность девелопера? В С++Билдере? По знакомству. Это же нормально для вашей страны? Чего удивлятся то? У вашего центрального канала приходит понимание что мер мАсквы не такой после команды сверху. До того он же был супер? Да он вообще был клевым чуваком - пока с Кремля не сказали - фас.
Казалось бы, при чем здесь Лужков? :)
Казалось бы - нах в разделе Борланда что Lerkin, что mfender - но как оказалось пасс скопи*пиздили у обоих.
Такая тяжолая судьба.
По теме есть что сказать? Или закрываем?
Такая тяжолая судьба.
По теме есть что сказать? Или закрываем?
Жорж получает очередной минус за стремление отвечать в тамах, в которых ничего не понимает.
Слуш-те, мужики, так все-таки есть утечки памяти или нет?
Ато 31 мессэйдж ваших флеймов листать ну крайне тяжело!
Ато 31 мессэйдж ваших флеймов листать ну крайне тяжело!
Цитата: hardcase
Слуш-те, мужики, так все-таки есть утечки памяти или нет?
Ато 31 мессэйдж ваших флеймов листать ну крайне тяжело!
Ато 31 мессэйдж ваших флеймов листать ну крайне тяжело!
в билдере 6 (bcc 5.6.4.0)- есть. Во всех прочих компиляторах вы с этой проблемой вероятно не столкнетесь.
Отметил на сайте - http://varkon.biz/?q=content/utechki_pamyati_memory_leak
а как и чем мерились утечки?
Цитата: oxotnik333
а как и чем мерились утечки?
Банально Task Manager'ом.
Цитата: oxotnik333
а как и чем мерились утечки?
а это принципиально?