> Пост был про другое. Про классы гарбидж коллекшн. Классом > __gc как раз и является форма. Delete тута не прокатит ;)) > Тут у них автоматика, блин ;))) Я боюсь, что дело даже не в классе __gc, а в самой архитектуре Windows.Forms. Собственно, мое "во-вторых" в предыдущем посте как раз об этом. В сущности, способ выделения и очистки памяти под GUI - это не так уж важно. Хуже, что на это могут быть завязаны и другие ресурсы.
> Но вот приколитесь над автоматизмом ж)) Положим у меня мало > ресурсов. И я хочу по-честному подчищаться, освобождая > ресурсы для объектов __gc по ходу дела. Так нет же! Эта > зараза - не даёт.;)))) Фраймворк всё равно эту работу > откладывает "на потом" для себя, для __gc классов. ;))) Во, а про это я "в-третьих" там же написал. Проблема бывает даже не при недостатке ресурсов, а при необходимости их запланированного освобождения по окончании использования.
Как правлильно в конкретном примере, что ниже? MSDN читал. Не бейте.
На форме frm1 : public System::Windows::Forms::Form две кнопочки - "Exit" и "Show frm2".
Когда нажимешь на кнопоку для формы frm1:
Код:
private: System::Void btnExit_Click(System::Object * sender, System::EventArgs * e)
{
Close();
}
Здесь по Close() нет вопросов. Вопрос дальше....
Когда нажимаешь на кнопочку формы frm1 Show frm2", показываем вторую модальную форму frm2 : public System::Windows::Forms::Form:
Код:
private: System::Void btnShow_Click(System::Object * sender, System::EventArgs * e)
{
Arms::frm2 *frm = new frm2;
frm->ShowDialog();
frm->Close();
//frm->_Dispose();
}
_Dispose только вызывает протектед метод Dispose(true); формы frm2.
Как правлильно frm->Close(); или frm->_Dispose();???
Прикол (для unmanaged programmer-а) в том, что для вызова frm->Close() фактически вызов Dispose этой формы происходит только при завершении работы всего приложения. Другими словами, 100 раз "запускаем" модальную форму, но Dispose этой формы не будет вызвана ни разу. Только при завершении работы всего приложения Dispose будет вызвана 100 раз.
Если делать frm->_Dispose();, то Dispose модальной формы будет вызвана 200 раз:
- 100 раз после создания и закрытия формы:
Код:
private: System::Void btnShow_Click(System::Object * sender, System::EventArgs * e)
{
Arms::frmLS2 *frm = new frmLS2;
frm->ShowDialog();
frm->_Dispose();
}
- 100 раз, как и в случае frm->Close();
Такое осчусчение, что фраймворк всё равно хранит дескрипторы всех окон, и пытается очистить память в конце работы всего приложения.
Нашел интересную статейку: ".NET Framework глазами программиста на C++" (link inside)19.08.04 18:34 Автор: Den <Денис Т.> Статус: The Elderman
М-да... Не хотелось ругаться на .NET, но блин, можно десять бритв Оккама затупить.20.08.04 01:19 Автор: Ktirf <Æ Rusakov> Статус: Elderman Отредактировано 20.08.04 01:20 Количество правок: 1
Ввели сборку мусора. Чтобы дочищать ресурсы, сделали Finalize. Пока все нормально. Поскольку есть ресурсы, которые требуют ASAP-освобождения, сделали в некоторых классах метод Close() (вроде еще не совсем избыточность, но первые признаки). Поскольку Close все, естественно, будут забывать вызывать (дальше Оккам интенсивно крутится в гробу), придумали еще один(!) cleanup-метод Dispose(), интерфейс IDisposable для тех, кто его предоставляет (это мне, написав Dispose(), надо не забыть написать, что я реализовал его), а чтобы все-таки сделать автоматизацию, добавили в язык(!!!) отдельную конструкцию using (кстати говоря, саму по себе весьма элегантную, но сыроватую), причем можно обойтись без нее, поэтому поверх IDisposable предлагается (впрочем, уже автором статьи) еще сделать класс автоуказателя! При этом все это дополнительное безобразие можно выразить только на C#, а на VB никакая автоматизация так и не появилась.
А началось всего-навсего с того, что ввели обязательную сборку мусора.
Спасибо, Den. Статья неплохая.20.08.04 01:04 Автор: void <Grebnev Valery> Статус: Elderman
Спасибо, Den. Статья неплохая.
Кстати, там, внутри той статьи, ещё ссылки на неплохие РДСН-носвкие статьи.
Никуда не деться. Хош-нехош - надо изучать матчасть.
Ок! Парни. Спасибо за реакцию.
Прочитал все посты. Чтобы не флудить - отвечаю в корень всем.
Ясно мне потихоньку становится, что из нормального языка (С/C++) мелкософт сделал - жалкое подобие жабы. Блин. Всё автоматически - блин ...ихнюю мать. Т.е. теперь нужнодругое_мышление_иметь!!!
Во как - за девелопера всё сделает фраймворк, ибо форма наследует от GC ( переводится "муссорный" класс). Вот уж действительно мусор - так мусор. ;)))))
Кстати, многие программеры-гуисты манаджет С++ приложений жалуются на неустойчивость приложений. Валят всё на недоработанность фраймворка. А вот со стороны шарповиков, таких жалоб не наблюдается. Думаю, что связано это может быть и со стериотипом мышления девелопера C++, который "пересел" на манаджет. Типа выделил память - надоб и прибраться за собой, забывая, что для гарбидж классов это и не надоть.
Ещё раз спасибо всем за реакцию.
На самом деле не совсем так (updated3).14.08.04 04:56 Автор: Ktirf <Æ Rusakov> Статус: Elderman Отредактировано 14.08.04 05:22 Количество правок: 6
Если писать именно на managed C++, то (если я ничего не путаю) можно (должно быть, по крайней мере) продолжать пользоваться delete. Но если у тебя повиснет ссылка, память все-таки не утечет. И это хорошо.
Беда в другом. Во-первых, C++ и .NET очень плохо уживаются друг с другом. Я ценю героические усилия товарища Саттера, который в Microsoft теперь за главного по C++, но примирить идеологию managed кода и C++ очень тяжело. Сказывается диапазон доступных программистам на C++ средств и высокая сложность реализации оных в компиляторе. Поэтому managed C++ - это дело по крайней мере следующего года, а пока - слишком ненадежно.
Во-вторых, с управлением памятью в GUI-библиотеках на C++ всегда было не слава Богу. И не только у MS. Это всеобщая проблема - я не видел ни одной библиотеки на C++, в которой вопрос очистки памяти, когда-то занятой под элементы интерфейса, был бы решен мало-мальски достойно.
В-третьих, (это уже просто в воздух) меня раздражает наивная идея разработчиков Java и .NET, будто чистить за собой нужно только память, а памяти много, поэтому можно спокойно дожидаться сборки мусора. Из-за этого виртуальная машина в браузере может до опупения держать соединение с сервером, к которому когда-то подключался какой-то апплет, которого уже и на экране нету давно. Что в таких случаях делать кроме принудительной сборки мусора, я, кстати, так и не знаю. А когда собирать, непонятно. И самое противное, что утечку памяти, как совершенно случайно обнаруживается, можно сделать и в Java. И в .NET, скорее всего, тоже, особенно из C++.
Возвращаясь к вопросу - судя по подчерку в имени, у меня стойкое ощущение, что _Dispose трогать не надо никогда. Бо общее соглашение: на подчерк начинаются специальные вызовы, не рассчитанные на непосредственное использование клиентом.
Да и нет на updated3 ;)).14.08.04 05:31 Автор: void <Grebnev Valery> Статус: Elderman
> Во-вторых, с управлением памятью в GUI-библиотеках на C++ > всегда было не слава Богу. И не только у MS. Это всеобщая > проблема - я не видел ни одной библиотеки на C++, в которой > вопрос очистки памяти, когда-то занятой под элементы > интерфейса, был бы решен мало-мальски достойно.
Продвинутая публика забугром пишет только на АПИ. В крайнем случае АТЛ.
> В-третьих, (это уже просто в воздух) меня раздражает > наивная идея разработчиков Java и .NET, будто чистить за > собой нужно только память, а памяти много, поэтому можно > спокойно дожидаться сборки мусора. Из-за этого виртуальная > машина в браузере может до опупения держать соединение с > сервером, к которому когда-то подключался какой-то апплет, > которого уже и на экране нету давно. Что в таких случаях > делать кроме принудительной сборки мусора, я, кстати, так и > не знаю. А когда собирать, непонятно. Тем более, что утечку > памяти, как совершенно случайно обнаруживается, можно > сделать и в Java. И в .NET, скорее всего, тоже, особенно из > C++.
Согласен. Об этом я пропостил в предыдущем НЕТ ;)))
Кстати да, проблема известна давно ещё, начиная с лиспа.
> Возвращаясь к вопросу - судя по подчерку в имени, у меня > стойкое ощущение, что _Dispose трогать не надо никогда. Бо > общее соглашение: на подчерк начинаются специальные вызовы, > не рассчитанные на непосредственное использование клиентом.
Dispose вызвать непосредственно "из другого класса" невозможно. Ибо она протектед. Прошу прощения, что ввёл Вас с подчёркиванием немного в заблуждение - паблик _Dispose у меня вызывает внутри у себя "родной" протектед метод Dispose.
Согласен. С чёрточкой в имени я погорячился. Писал на коленках.;))))
А, так это твой _Dispose :)14.08.04 05:36 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> Dispose вызвать непосредственно "из другого класса" > невозможно. Ибо она протектед. Ну блин, тогда можно было и черточку ставить, все равно хак. Уж наверное Dispose неспроста protected сделан. Такое решение равносильно прямому вызову деструктора (не из delete) - ничего хорошего ожидать не приходится, хотя формально сделать это можно.
Дык в MSDN - что мол Dispose надо вызывать, ихнюю мать ;))))...14.08.04 05:48 Автор: void <Grebnev Valery> Статус: Elderman
> > Dispose вызвать непосредственно "из другого класса" > > невозможно. Ибо она протектед. > Ну блин, тогда можно было и черточку ставить, все равно > хак. Уж наверное Dispose неспроста protected сделан. Такое > решение равносильно прямому вызову деструктора (не из > delete) - ничего хорошего ожидать не приходится, хотя > формально сделать это можно.
Дык в MSDN - что мол Dispose надо вызывать, ихнюю мать ;)))) Ну точно говорю ;)))
Раз они написали, чтоНАПРЯМУЮDispose нужно вызывать, так я и попробовал.
Но только увидел, что вызов Dispose никак не освобождает ресурсы. Ибо сам фреймворк вызывает её "для гарантии" ;)))) по завершинии всего приложения.
Короче, косяк-то в чём, из-за чего и пост мой был в самом начале:
ВЫЗЫВАЙ DISPOSE аль НЕ ВЫЗЫВАЙ DISPOSE - фраймворк всё равно его вызовет ;)))
Угу, то же самое что Finalize в Java. Только там даже нет гарантии, что он вообще будет вызван.14.08.04 17:21 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> Если писать именно на managed C++, то (если я ничего не > путаю) можно (должно быть, по крайней мере) продолжать > пользоваться delete.
Да, нет конечно же ;))
Никто delete не отменял. Более того, если Вы сделали даже в манаджед коде new, то, конечно, выОБЯЗАНЫсделать delete. Ибо никакой манаджет вместе с фраймворком и Саттером по прежнему не спасут ;))
Пост был про другое. Про классы гарбидж коллекшн. Классом __gc как раз и является форма. Delete тута не прокатит ;)) Тут у них автоматика, блин ;)))
Но вот приколитесь над автоматизмом ж)) Положим у меня мало ресурсов. И я хочу по-честному подчищаться, освобождая ресурсы для объектов __gc по ходу дела. Так нет же! Эта зараза - не даёт.;)))) Фраймворк всё равно эту работу откладывает "на потом" для себя, для __gc классов. ;)))
>Но если у тебя повиснет ссылка, память
> все-таки не утечет. И это хорошо. > Беда в другом. C++ и .NET очень плохо уживаются друг с > другом. Я ценю героические усилия товарища Саттера, который > в Microsoft теперь за главного по C++, но примирить > идеологию managed кода и C++ очень тяжело. Сказывается > низкоуровневость C++, и даже в большей степени, я думаю,- > его жуткая грамматика, которую на нормальный язык не > переведешь. Поэтому managed C++ - это дело по крайней мере > следующего года, а пока - ждем-с.
Согласен.
Отклонились от темы, ну да ладно.14.08.04 05:32 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> Никто delete не отменял. Более того, если Вы сделали даже > в манаджед коде new, то, конечно, выОБЯЗАНЫсделать > delete. Ибо никакой манаджет вместе с фраймворком и > Саттером по прежнему не спасут ;)) Спасут. В принципе возможно сделать компилятор C++, по возможности контролирующий память, выделяемую операторами new. При условии отсутствия кульбитов с указателями, конечно. Но это - серьезный оверхед на производительность, поэтому такие компиляторы носят экспериментальный характер.
Издержки сырой реализации (я надеюсь)14.08.04 05:28 Автор: Ktirf <Æ Rusakov> Статус: Elderman Отредактировано 14.08.04 05:29 Количество правок: 1
> Пост был про другое. Про классы гарбидж коллекшн. Классом > __gc как раз и является форма. Delete тута не прокатит ;)) > Тут у них автоматика, блин ;))) Я боюсь, что дело даже не в классе __gc, а в самой архитектуре Windows.Forms. Собственно, мое "во-вторых" в предыдущем посте как раз об этом. В сущности, способ выделения и очистки памяти под GUI - это не так уж важно. Хуже, что на это могут быть завязаны и другие ресурсы.
> Но вот приколитесь над автоматизмом ж)) Положим у меня мало > ресурсов. И я хочу по-честному подчищаться, освобождая > ресурсы для объектов __gc по ходу дела. Так нет же! Эта > зараза - не даёт.;)))) Фраймворк всё равно эту работу > откладывает "на потом" для себя, для __gc классов. ;))) Во, а про это я "в-третьих" там же написал. Проблема бывает даже не при недостатке ресурсов, а при необходимости их запланированного освобождения по окончании использования.
респект по всем пунктам ;))14.08.04 05:33 Автор: void <Grebnev Valery> Статус: Elderman
Ну дык, поидее правильно, GC почистит все ресурсы когда ихмало становится или же при закрыти проги ;)
Это наверное потому, что ты создаешь объект класса (new), но ни разу его не удаляешь (delete).13.08.04 14:07 Автор: Den <Денис Т.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
